Move llvmlite to LLVM 20

[yashssh]

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
  • StandardIntrumentations checks function analysis invalidation in module passes as well: https://reviews.llvm.org/D146160
  • TargetParser.getHostCPUFeatures() returns a StringMap: [llvm][TargetParser] Return StringMap from getHostCPUFeatures llvm/llvm-project#97824
  • CodeGenOpt::Level turned into an enum class: [NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes llvm/llvm-project#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)

[gmarkall]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[detrout]

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) 

[detrout]

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

[detrout]

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

[yashssh]

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.

[detrout]

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.

[yashssh]

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

[picca]

It seems that the minimum version available in Debian testing is llvm-18

[yashssh]

@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

[detrout]

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?

[yashssh]

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 numba/numba#9676 is the first hurdle before this can be merged.

[rj-jesus]

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! 😄

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.

[gmarkall]

@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]

@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 #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.

[detrout]

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.

[yashssh]

@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.

[detrout]

llvmlite build on x86_64 and on arm64 (under qemu) with the recommend numba patch numba/numba#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.

[yashssh]

I have rebased the changes on top of main since #1091 was merged.

[swap357]

• updated the GHA workflows and azure pipelines to use the new llvm20 channels.
• corrected tests to expect missing os linkages

All CI - azure and GHA are functional now.
The remaining failures point to formatting errors and RTD will work when llvmdev-20 conda packages are on numba/label/dev channel

[esc]

The llvmdev=20 packages are now available on numba/label/dev -- so the RTD build passed too!

[esc]

These changes are needed to simplify the build scripts.

[sklam]

👍 I've reviewed the C++ changes and the main merge to pick up CMake migration.

One minor issue is that this is missing OrcDebugging. So just this oneliner sklam@688a910

[swap357]

Conda packages and wheels produced by this PR have been tested against numba/numba using GitHub Actions (via numba#10146).
CI runs: https://github.com/numba/numba/actions?query=branch%3Apr-10146

Two Windows (win-64) jobs - the conda builder and the wheel builder are currently failing due to known gha issues. Fixes are proposed in numba#10193 and numba#10194, with passing validation runs.

[esc]

Based on the tests in numba/numba#10146 -- this is now ready to merge.

[esc]

all good now