numba
Move llvmlite to LLVM 20
~Depends and contains changes introduced with #1091~
List of changes in this MR
- Delete legacy pass manager code
- Delete typed pointer code
- Update APIs that needs updating for llvm19
- Pass registry and initialization APIs support dropped: https://reviews.llvm.org/D145043
-
StandardIntrumentationschecks function analysis invalidation in module passes as well: https://reviews.llvm.org/D146160 -
TargetParser.getHostCPUFeatures()returns aStringMap: https://github.com/llvm/llvm-project/pull/97824 -
CodeGenOpt::Levelturned into an enum class: https://github.com/llvm/llvm-project/pull/66295
- Update refprune pass and its tests
TODO:
- run with remarks feature ~and pass timer features~ have to be added
(edited by @gmarkall to link to relevant review for dropping initialization APIs)
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi,
I found time to try and work on getting llvmlite to build with a version of llvm that's in Debian.
I took this pull request and rebased it against 0.44.0, and then collapse the branch into a single diff to apply to the a Debian 0.44.0 version of the llvmlite package.
I pushed what I've manage to get done to https://github.com/detrout/llvmlite/tree/llvm19
I noticed there's a bunch of code removed this pull request in a migration from passmanager to newpassmanager, though the llvmlite HEAD branch currently has both passmanager and newpassmanager modules. I don't know if it's intended to remove passmanager or not?
The merged code almost works (at least on Debian unstable on a x86 cpu with python 3.13.2 and llvm-19.1.7) it's down to two test failures.
======================================================================
FAIL: test_object_file (llvmlite.tests.test_binding.TestObjectFile.test_object_file)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_llvmlite/build/llvmlite/tests/test_binding.py", line 2443, in test_object_file
self.assertTrue(s.size() > 0)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
AssertionError: False is not true
======================================================================
FAIL: test_lookup_current_process_symbol_fails (llvmlite.tests.test_binding.TestOrcLLJIT.test_lookup_current_process_symbol_fai
ls)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_llvmlite/build/llvmlite/tests/test_binding.py", line 1493, in test_lookup_curre
nt_process_symbol_fails
with self.assertRaisesRegex(RuntimeError, msg):
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
AssertionError: RuntimeError not raised
----------------------------------------------------------------------
Ran 379 tests in 7.699s
FAILED (failures=2, skipped=2)
I did try running the build under arm64 using qemu and funny story, all the tests passed.
Ran 379 tests in 171.947s
OK (skipped=19)
I'd also managed to run the two test failures in pdb, and for the llvmlite.tests.test_binding.TestObjectFile.test_object_file
I found a possibly useful thing that there was a .text segment that had no contents. Though there were other text segments like (I think) .ltext that had some contents
I am deep into places I don't understand and could use help. This is the test failure from test_binding.py::TestObjectFile.test_object_file() on an older x86_64 cpu
I figured out how to print the assembly code.
This is with llvm-19 and there's a .section section that the llvm-15 version doesn't use
.text
.file "asm_sum.c"
.section .ltext,"axl",@progbits
.globl sum
.p2align 4, 0x90
.type sum,@function
sum:
.cfi_startproc
leal (%rdi,%rsi), %eax
retq
.Lfunc_end0:
.size sum, .Lfunc_end0-sum
.cfi_endproc
.type glob,@object
.section .lbss,"awl",@nobits
.globl glob
.p2align 2, 0x0
glob:
.long 0
.size glob, 4
.type glob_b,@object
.globl glob_b
glob_b:
.byte 0
.size glob_b, 1
.type glob_f,@object
.section .ldata,"awl",@progbits
.globl glob_f
.p2align 2, 0x0
glob_f:
.long 0x3fc00000
.size glob_f, 4
.type glob_struct,@object
.section .lbss,"awl",@nobits
.globl glob_struct
.p2align 4, 0x0
glob_struct:
.zero 24
.size glob_struct, 24
.section ".note.GNU-stack","",@progbits
This is what was generated from llvm 15.0.7 from conda.
.text
.file "asm_sum.c"
.globl sum
.p2align 4, 0x90
.type sum,@function
sum:
.cfi_startproc
leal (%rdi,%rsi), %eax
retq
.Lfunc_end0:
.size sum, .Lfunc_end0-sum
.cfi_endproc
.type glob,@object
.bss
.globl glob
.p2align 2
glob:
.long 0
.size glob, 4
.type glob_b,@object
.globl glob_b
glob_b:
.byte 0
.size glob_b, 1
.type glob_f,@object
.data
.globl glob_f
.p2align 2
glob_f:
.long 0x3fc00000
.size glob_f, 4
.type glob_struct,@object
.bss
.globl glob_struct
.p2align 4
glob_struct:
.zero 24
.size glob_struct, 24
.section ".note.GNU-stack","",@progbits
Hi @detrout, thanks for looking into this! The pull request is due a rebase/merge of main for a long time now. The time I created this pull request all tests were passing which obviously isn't the case right now. May I know what are you trying to do with these changes? Meanwhile let me try running the tests again locally.
What's going on is Debian is coming close to a freeze and our release team dropped our llvm-15 for having too many unfixed bugs. which then removed llvmlite, and that removes numba, and that breaks a whole bunch of scientific python packages. We do have llvm-19 and I when I saw this pull request and thought I'd take a stab at merging it.
What I did was to take the original pull request and rebase it against the 0.44.0 release of llvmlite, to try and get something that might be reasonable for Debian to ship. So that's why I was aiming for the release version of llvmlite instead of HEAD.
At this point I made progress more out of stubbornness than any deep understanding of llvm. Though I'm learning bits as I try to figure out whats going on.
I pushed my updated debian package to https://salsa.debian.org/diane/llvmlite
Though unlike the github version that has a flattened version of the llvm-19 compatibility patch.
What's going on is Debian is coming close to a freeze and our release team dropped our llvm-15 for having too many unfixed bugs. which then removed llvmlite, and that removes numba, and that breaks a whole bunch of scientific python packages.
I'm not sure if this helps but llvmlite v0.44 do support LLVM 16 out of the box https://llvmlite.readthedocs.io/en/latest/release-notes.html
@detrout I looked the assembly assertion error and also reproduced it locally. It doesn't look like anything is wrong, just a slight update in the code layout I'm not exactly sure why. You can just update the test and move on
I added 2 commits to deal with the test failures with llvm-19 at https://github.com/detrout/llvmlite/commits/llvm19/
what would you like next? try to rebase that change set against HEAD?
what would you like next? try to rebase that change set against HEAD?
For this PR? I don't think a rebase is required, I did merge the main branch into it. We would have to wait for the reviews to move forward. Right now https://github.com/numba/numba/pull/9676 is the first hurdle before this can be merged.
What's going on is Debian is coming close to a freeze and our release team dropped our llvm-15 for having too many unfixed bugs. which then removed llvmlite, and that removes numba, and that breaks a whole bunch of scientific python packages. We do have llvm-19 and I when I saw this pull request and thought I'd take a stab at merging it.
I'm happy to hear Debian's planning to ship an updated llvmlite+llvm release! :smile:
What I did was to take the original pull request and rebase it against the 0.44.0 release of llvmlite, to try and get something that might be reasonable for Debian to ship. So that's why I was aiming for the release version of llvmlite instead of HEAD.
I think this should work in principle, but I'd suggest rebasing this against HEAD instead. This PR precedes a few others where we improved support for LLVM opaque pointers. Without them, some of the code paths in Numba may not work with LLVM 17+. Alternatively, you could cherry-pick these PRs onto the 0.44 release, which I believe should work as the changes are mostly self-contained. The relevant PRs are #1159, #1158 and #1160 (merged in this order). Please let me know if you'd like some help with this.
@yashssh Will numba/numba#9676 also be needed in Numba for it to work with LLVM >= 17? Would @detrout need to grab that and incorporate it into the Debian sources?
@yashssh Will numba/numba#9676 also be needed in Numba for it to work with LLVM >= 17? Would @detrout need to grab that and incorporate it into the Debian sources?
Yes that's correct.
@detrout if you are cherrypicking the changes on top of last release you will also need https://github.com/numba/llvmlite/pull/1163 in addition to what Ricardo mentioned (perhaps it's easier to rebase on top of main).
numba/numba#9676 introduces a switch to use either the Legacy or the New pass manager in Numba(defaulting to the new PM).
That merge request is supposed to be followed by another code cleanup change that drops support for the legacy pass manager entirely in Numba. Post those changes we can merge this change in llvmlite.
For simplifying things I have consolidated all required Numba changes in this draft pull request, which should allow you to move forward in Numba with a single patch.
My first stab at building debianianized numba 0.61.0 with this patched version of llvmlite 0.44 didn't work and I need to figure out why.
Thank you all for highlighting more pull requests that might be needed, hopefully I'll have some time soon to try and start plugging them together.
@detrout we have rebased the required llvmlite LLVM19 changes on top of last release (v0.44) #1182 combined with necessary numba changes numba/numba#10011 should allow you to build and test everything with LLVM19. You might still have to add workarounds for the x86 failures you saw.
llvmlite build on x86_64 and on arm64 (under qemu) with the recommend numba patch https://github.com/numba/numba/pull/10011 and https://github.com/numba/numba/commit/1e2fb1d1c81880a645345991eb48e39b578e119d.patch
I was able to get numba to build using llvmlite 0.44 with llvm-19. it built and ran it's tests under x86_64 but I got a timeout error for arm64 under qemu.... Though I know that numba tests take forever.
With this PR and the package built by #1226, I get:
$ gdb --args python runtests.py
(gdb) run
Starting program: /home/gmarkall/miniforge3/envs/test-llvmlite-20-py311/bin/python runtests.py
..s..
Program received signal SIGSEGV, Segmentation fault.
0x00007fffefe6635a in llvm::RegisterTargetMachine<llvm::X86TargetMachine>::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, std::optional<llvm::Reloc::Model>, std::optional<llvm::CodeModel::Model>, llvm::CodeGenOptLevel, bool) () from /home/gmarkall/numbadev/llvmlite/llvmlite/binding/libllvmlite.so
(gdb) bt
#0 0x00007fffefe6635a in llvm::RegisterTargetMachine<llvm::X86TargetMachine>::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, std::optional<llvm::Reloc::Model>, std::optional<llvm::CodeModel::Model>, llvm::CodeGenOptLevel, bool) () from /home/gmarkall/numbadev/llvmlite/llvmlite/binding/libllvmlite.so
#1 0x00007fffefd77dd6 in llvm::Target::createTargetMachine (this=0x7ffff6a87d20 <llvm::getTheX86_64Target()::TheX86_64Target>,
TT=..., CPU=..., Features=..., Options=..., RM=..., CM=..., OL=llvm::CodeGenOptLevel::Default, JIT=true)
at /home/gmarkall/miniforge3/envs/test-llvmlite-20-py311/include/llvm/MC/TargetRegistry.h:462
#2 0x00007fffefd78a6c in LLVMPY_CreateTargetMachine (T=0x7ffff6a87d20 <llvm::getTheX86_64Target()::TheX86_64Target>,
Triple=0x7ffff748af50 "x86_64-unknown-linux-gnu", CPU=0x555555aaa368 <_PyRuntime+9096> "",
Features=0x555555aaa368 <_PyRuntime+9096> "", OptLevel=2, RelocModel=0x7fffef57cf20 "default",
CodeModel=0x7fffef57ccb0 "jitdefault", PrintMC=0, JIT=1, ABIName=0x555555aaa368 <_PyRuntime+9096> "")
@yashssh Have you run on x86 as well? I presume you have not encountered segfaults in the test suite so far?
@yashssh question: we are going to be merging https://github.com/numba/llvmlite/pull/1252 very soon -- would you be able to rebase this PR onto main at short notice this week? I'm trying to push the next llvmlite release forward and would like to include this change.
(Not to add notification noise, but as a distro maintainer that has to deal with way too many unmaintained LLVM versions, thank you very much for working on this and I look forward to the release!)
@yashssh the PR @ https://github.com/numba/llvmlite/pull/1252 is now merged, I think you can merge main into this now and resolve the conflicts.
I saw these merge conflicts:
Unmerged paths:
both modified: ffi/CMakeLists.txt
deleted by us: ffi/Makefile.freebsd
deleted by us: ffi/Makefile.linux
deleted by us: ffi/Makefile.osx
both modified: ffi/build.py
both modified: ffi/custom_passes.cpp
both modified: ffi/newpassmanagers.cpp
Three removes, two clobbers and some cpp resolution?
The RTD jobs fail because of:
-- Found LLVM 15.0.7
--
| -- Using LLVMConfig.cmake in: /home/docs/checkouts/readthedocs.org/user_builds/llvmlite/conda/1092/lib/cmake/llvm
| CMake Error at CMakeLists.txt:41 (message):
| LLVM CMake export states LLVM version is 15, llvmlite only officially
| supports 20.
The RTD jobs fail because of:
-- Found LLVM 15.0.7 -- | -- Using LLVMConfig.cmake in: /home/docs/checkouts/readthedocs.org/user_builds/llvmlite/conda/1092/lib/cmake/llvm | CMake Error at CMakeLists.txt:41 (message): | LLVM CMake export states LLVM version is 15, llvmlite only officially | supports 20.
This is expected right?
The RTD jobs fail because of:
-- Found LLVM 15.0.7 -- | -- Using LLVMConfig.cmake in: /home/docs/checkouts/readthedocs.org/user_builds/llvmlite/conda/1092/lib/cmake/llvm | CMake Error at CMakeLists.txt:41 (message): | LLVM CMake export states LLVM version is 15, llvmlite only officially | supports 20.This is expected right?
I suppose so, the RTD setup was modified as part of the refactor to cmake. I suppose the expected best resolution would be the following patch:
diff --git i/docs/environment.yml w/docs/environment.yml
index 3d190ee6c5..7f8ca55e49 100644
--- i/docs/environment.yml
+++ w/docs/environment.yml
@@ -5,7 +5,7 @@ dependencies:
- python
# pip for installing llvmlite itself
- pip
- - llvmdev=15
+ - llvmdev=20
- cmake
- make
- docutils==0.16
however this will require the existence of an llvmdev package on the numba/label/dev channel from anaconda.org -- of which there is none yet:
So the resolution of the RTD build here is blocked until such a package appears (meaning: someone needs to go build it and upload it to anaconda.org).
@gmarkall @sklam and @swap357 are currently working on https://github.com/numba/llvmlite/pull/1226 -- once that passes, we can build some llvmdev packages suitable for this PR.