Re: WIP: expression evaluation improvements

Поиск
Список
Период
Сортировка
От Soumyadeep Chakraborty
Тема Re: WIP: expression evaluation improvements
Дата
Msg-id CADwEdoqvfFo9RfYvVcQhs3fsRxjei-BvR=OA9X8Y4q7QM_mzNA@mail.gmail.com
обсуждение исходный текст
Ответ на WIP: expression evaluation improvements  (Andres Freund <andres@anarazel.de>)
Ответы Re: WIP: expression evaluation improvements
Список pgsql-hackers
Hey Andres,

After looking at
v2-0006-jit-Reference-functions-by-name-in-IOCOERCE-steps.patch, I was wondering
about other places in the code where we have const pointers to functions outside
LLVM's purview: specially EEOP_FUNCEXPR* for any function call expressions,
EEOP_DISTINCT and EEOP_NULLIF which involve operator specific comparison
function call invocations, deserialization and trans functions for aggregates
etc. All of the above cases involve to some degree some server functions that
can be inlined/optimized.

If we do go down this road, the most immediate solution that comes to mind would
be to populate referenced_functions[] with these. Also, we can replace all
l_ptr_const() calls taking function addresses with calls to
llvm_function_reference() (this is safe as it falls back to a l_pt_const()
call). We could do the l_ptr_const() -> llvm_function_reference() even if we
don't go down this road.

One con with the approach above would be bloating of llvmjit_types.bc but we
would be introducing @declares instead of @defines in the IR...so I think that
is fine.

Let me know your thoughts. I would like to submit a patch here in this thread or
elsewhere.

--
Soumyadeep

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Victor Spirin
Дата:
Сообщение: Re: psql tab-complete
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Creating foreign key on partitioned table is too slow