From: | Holger Hoffstätte <holger(at)applied-asynchrony(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] jit: fix build with LLVM-21 |
Date: | 2025-09-12 07:47:23 |
Message-ID: | b3376d7f-93b1-765d-addf-2e09939d0f47@applied-asynchrony.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-09-12 08:36, Peter Eisentraut wrote:
> On 08.09.25 15:20, Holger Hoffstätte wrote:
>> I tried building against LLVM-21 and noticed that a function for symbol
>> lookup was renamed (without semantic changes), breaking the LLVM JIT.
>> The following patch fixes this by adding a version guard. It applies equally
>> to both master and 17.6. Passes the test suite and verified on 17.6 with the
>> jit example from the documentation.
>
> I can confirm that this change seems correct. See [0] for reference.
Excellent! Thanks for taking a look. This was my first post to pgsql-hackers
and I wasn't sure if I had done something wrong.
> [0]:
> https://github.com/llvm/llvm-project/commit/d3d856ad84698fa4ec66177d00558b2f5b438d3b
>
> As a small style request, I would flip the conditional around so
> that the new code appears first. I see that we don't do this very
> consistently in the existing code, but maybe we can start a new
> trend. ;-)
I knew this would come up since I pondered the same thing :D
As you said, the existing code is not consistent, but I can switch this
to let the new code appear first, if you prefer.
A new patch is attached.
> In my testing with LLVM 21, I'm getting an additional error:
>
> ../src/backend/jit/llvm/llvmjit_wrap.cpp:56:18: error: no matching constructor for initialization of 'llvm::orc::RTDyldObjectLinkingLayer'
> 56 | return wrap(new llvm::orc::RTDyldObjectLinkingLayer(
> | ^
> 57 | *unwrap(ES), [] { return std::make_unique<llvm::backport::SectionMemoryManager>(nullptr, true); }));
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:58:3: note: candidate constructor not viable: no known conversion from '(lambda at ../src/backend/jit/llvm/llvmjit_wrap.cpp:57:16)' to 'GetMemoryManagerFunction' (aka 'unique_function<std::unique_ptr<RuntimeDyld::MemoryManager> (const MemoryBuffer &)>') for 2nd argument
> 58 | RTDyldObjectLinkingLayer(ExecutionSession &ES,
> | ^
> 59 | GetMemoryManagerFunction GetMemoryManager);
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:37:16: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided
> 37 | class LLVM_ABI RTDyldObjectLinkingLayer
> | ^~~~~~~~~~~~~~~~~~~~~~~~
>
> I gather you're not seeing that?
I do not - I dropped the patch into my Gentoo package build for 17.6 and
it has been working fine when building with gcc-15.2 and the jit part
with clang-21.1.0. I also just rebuilt everything with clang-21.1.1 (no gcc)
and also do not see the problem. This is on amd64 Linux.
The following commit seems to be involved:
https://github.com/postgres/postgres/commit/9044fc1d45a0212fd123bd8f364eac058f60fed7
which is also in my 17.6 tree. I verified that the new
SectionMemoryManager.cpp is compiled without error.
Since you're using homebrew I guess this is triggered by the
__aarch64__ guard in src/include/jit/llvmjit_backport.h.
Unfortunately this is as far as I can help with this.
Please let me know if there is anything else I can do.
cheers
Holger
Attachment | Content-Type | Size |
---|---|---|
llvm-21-v2.patch | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-09-12 08:19:12 | let ALTER COLUMN SET DATA TYPE cope with POLICY dependency |
Previous Message | Ashutosh Sharma | 2025-09-12 07:37:46 | Re: How can end users know the cause of LR slot sync delays? |