| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Minor LLVM cleanups |
| Date: | 2025-11-28 03:41:46 |
| Message-ID: | CA+hUKGJgB6gvrdDohgwLfCwzVQm=VMtb9m0vzQn=CwWn-kwG9w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
0001: These days we handle LLVM API evolution with LLVM_VERSION_MAJOR
guards. These GDB and Perf support probes escaped recent garbage
collection cycles by not being phrased like that. Function probes are
generally better for cross-platform variations and library build
options that are exposed by function visibility, but in this case all
supported versions have the functions, even when the relevant feature
isn't enabled in LLVM.
0002: On my FreeBSD box (and presumably any non-Linux system), if I
set jit_profiling_support=1 then LLVMCreatePerfJITEventListener() is a
dummy function that returns NULL and we crash. The attached just
silently skips in that case. If we raised an error instead I suppose
it would have to be FATAL given the call site in a callback invoked by
LLVM/C++. We could work harder and teach the GUC to probe LLVM when
you try to turn it on, but apparently no one tried to turn on perf on
a system without perf in all these years... Should the manual say
that it's only available on Linux? Would it be reasonable to
additionally assume that __linux__ implies LLVM_USE_PERF and disable
the GUC otherwise?
(There are more kinds of profiling support available, which I might
learn more about as part of the JITLink work.)
0003: While contemplating how close we are to an empty
llvmjit_wrap.cpp file, I considered whether the two wrappers added by
commit 37d5babb should be upstreamed, and then realised that this one
is not needed if you jump though one extra hoop.
0004: I *think* the second one is redundant too: all the functions in
question are either global or we have a template function of the same
type that is. From a spartan trail of bread crumbs[1][2] I realised
that we should be able to use LLVMGlobalGetValueType() instead. make
check with passes with TEMP_CONFIG set to define jit_above_cost=0
against bleeding-edge LLVM built with
-DLLVM_USE_SANITIZER="Address;Undefined" and
-DLLVM_ENABLE_ASSERTIONS=ON.
[1] https://github.com/llvm/llvm-project/blob/06c8ee61ab80305be88380e6aa2f1b2fe32f859d/llvm/include/llvm-c/Core.h#L2672
[2] https://github.com/llvm/llvm-project/blob/06c8ee61ab80305be88380e6aa2f1b2fe32f859d/llvm/include/llvm/IR/Function.h#L210
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-jit-Drop-redundant-LLVM-configure-checks.patch | text/x-patch | 5.3 KB |
| 0002-jit-Fix-jit_profiling_support-when-not-available.patch | text/x-patch | 1.2 KB |
| 0003-jit-Drop-LLVMGetFunctionReturnType-wrapper.patch | text/x-patch | 2.7 KB |
| 0004-jit-Drop-LLVMGetFunctionType-wrapper.patch | text/x-patch | 9.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2025-11-28 03:49:10 | Re: Simplify code building the LR conflict messages |
| Previous Message | Tom Lane | 2025-11-28 02:49:18 | Re: Simplify code building the LR conflict messages |