Apologies, I realize my understanding of symbol resolution and the referenced_functions mechanism wasn't correct. Thank you for your very helpful explanations.
> There's also a related edge-case where are unable to figure out a symbol > name in llvm_function_reference(), and then resort to creating a global > variable pointing to the function.
Indeed.
> If indeed the only case this is being hit is language PL handlers, it > might be better to instead work out the symbol name for that handler - > we should be able to get that via pg_language.lanplcallfoid.
I took a stab at this (on top of your patch set): v1-0001-Resolve-PL-handler-names-for-JITed-code-instead-o.patch
> Which cases are you talking about here? Because I don't think there's > any others where would know a symbol name to add to referenced_functions > in the first place?
I had misunderstood the intent of referenced_functions.
> I do want to benefit from getting accurate signatures for patch > [PATCH v2 26/32] WIP: expression eval: relative pointer suppport > I had a number of cases where I passed the wrong parameters, and llvm > couldn't tell me...
I took a stab: v1-0001-Rely-on-llvmjit_types-for-building-EvalFunc-calls.patch
On a separate note, I had submitted a patch earlier to optimize functions earlier in accordance to the code comment: /* * Do function level optimization. This could be moved to the point where * functions are emitted, to reduce memory usage a bit. */ LLVMInitializeFunctionPassManager(llvm_fpm); Refer: https://www.postgresql.org/message-id/flat/CAE-ML+_OE4-sHvn0AA_qakc5qkZvQvainxwb1ztuuT67SPMegw@mail.gmail.com I have rebased that patch on top of your patch set. Here it is: v2-0001-Optimize-generated-functions-earlier-to-lower-mem.patch
