Re: WIP: expression evaluation improvements - Mailing list pgsql-hackers

From Soumyadeep Chakraborty
Subject Re: WIP: expression evaluation improvements
Date
Msg-id CADwEdoqvfFo9RfYvVcQhs3fsRxjei-BvR=OA9X8Y4q7QM_mzNA@mail.gmail.com
Whole thread Raw
In response to WIP: expression evaluation improvements  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP: expression evaluation improvements
List 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 by date:

Previous
From: Victor Spirin
Date:
Subject: Re: psql tab-complete
Next
From: Tomas Vondra
Date:
Subject: Re: Creating foreign key on partitioned table is too slow