> On Fri, Mar 15, 2024 at 01:54:38PM +1300, Thomas Munro wrote: > For me it seems that the LLVMRunPasses() call, new in > > commit 76200e5ee469e4a9db5f9514b9d0c6a31b496bff > Author: Thomas Munro <tmu...@postgresql.org> > Date: Wed Oct 18 22:15:54 2023 +1300 > > jit: Changes for LLVM 17. > > is reaching code that segfaults inside libLLVM, specifically in > llvm::InlineFunction(llvm::CallBase&, llvm::InlineFunctionInfo&, bool, > llvm::AAResults*, bool, llvm::Function*). First obvious question > would be: is that NULL argument still acceptable? Perhaps it wants > our LLVMTargetMachineRef there: > > err = LLVMRunPasses(module, passes, NULL, options); > > But then when we see what is does with that argument, it arrives at a > place that apparently accepts nullptr. > > https://github.com/llvm/llvm-project/blob/6b2bab2839c7a379556a10287034bd55906d7094/llvm/lib/Passes/PassBuilderBindings.cpp#L56 > https://github.com/llvm/llvm-project/blob/6b2bab2839c7a379556a10287034bd55906d7094/llvm/include/llvm/Passes/PassBuilder.h#L124 > > Hrmph. Might need an assertion build to learn more. I'll try to look > again next week or so.
Looks like I can reproduce this as well, libLLVM crashes when reaching AddReturnAttributes inside InlineFunction, when trying to access operands of the return instruction. I think, for whatever reason, the latest LLVM doesn't like (i.e. do not expect this when performing inlining pass) return instructions that do not have a return value, and this is what happens in the outblock of deform function we generate (slot_compile_deform). For verification, I've modified the deform.outblock to call LLVMBuildRet instead of LLVMBuildRetVoid and this seems to help -- inline and deform stages are still performed as before, but nothing crashes. But of course it doesn't sound right that inlining pass cannot process such code. Unfortunately I don't see any obvious change in the recent LLVM history that would justify this outcome, might be a genuine bug, will investigate further.