> On Sun, Mar 17, 2024 at 09:02:08PM +0100, Dmitry Dolgov wrote: > > 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.
I think I found the change that got it all started [1], the commit has a set of tags like 18.1.0-rc1 and is relatively recent. The message doesn't say anything related to the crash that we see, so I assume it's indeed a bug. I've opened an issue to confirm this understanding [2] (wow, issues were indeed moved to github since the last time I was touching LLVM), let's see what would be the response. [1]: https://github.com/llvm/llvm-project/commit/2da4960f20f7e5d88a68ce25636a895284dc66d8 [2]: https://github.com/llvm/llvm-project/issues/86162
