Support LLVM 12.*

[esc]

Work items required:

• Prepare a patch to build llvmdev from LLVM 12.*
• Run all test suits on internal build farm
• Iterate until all issues resolved

[esc]

More info about release schedule here: https://lists.llvm.org/pipermail/llvm-dev/2021-January/147599.html

[advancedwebdeveloper]

I wonder if there is any demand on an interop scenario, against LLVM's IR. Something like Python->IR and Golang->IR compilation, which could be passed to specific back-end.

Duplicating my question: why nobody tried to build Ninja, using llvmlite?

[esc]

@advancedwebdeveloper thank you for your question. Please be aware that this issue is strictly for tracking progress of implementing LLVM 12.* support. To retain signal-to-noise ratio on the given task, I would kindly request you to open new discussions with your questions on the Numba discourse in the llvmlite category: https://numba.discourse.group/c/llvmlite/12 -- thank you for understanding!

[r-barnes]

I just wanted to check if there's a time estimate for the LLVM-12 release?

[esc]

I just wanted to check if there's a time estimate for the LLVM-12 release?

Not exactly, but it's in the cards 🂢🂱🃗 for 2022, would be my guess 🔮

[niyas-sait]

Sorry to add noise to the thread. Is there any update on suporting LLVM-12 or 13?

[esc]

Sorry to add noise to the thread. Is there any update on suporting LLVM-12 or 13?

nothing concrete at this time, no. The rough plan is to upgrade in Q2/Q3 2022, resources permitting.

[niyas-sait]

Sorry to add noise to the thread. Is there any update on suporting LLVM-12 or 13?

nothing concrete at this time, no. The rough plan is to upgrade in Q2/Q3 2022, resources permitting.

Thanks. Do we know of any specific challenges to support latest llvm based on known changes or past experiences?

[esc]

Sorry to add noise to the thread. Is there any update on suporting LLVM-12 or 13?

nothing concrete at this time, no. The rough plan is to upgrade in Q2/Q3 2022, resources permitting.

Thanks. Do we know of any specific challenges to support latest llvm based on known changes or past experiences?

Yes, it will be troublesome. Past experience has shown an LLVM upgrade is almost always associated with an unforeseeable number of unknown breaking changes for Numba. It usually takes a few weeks. In this case, we may upgrade from MCJIT to ORC-JIT so I expect an additional set of challenges for that one.

[seibert]

Historically, the biggest issue was changing C++ interfaces, but we've isolated ourselves pretty well from those, and LLVM has slowed down the churn on its public interfaces. These days, the most common issues are:

• Random, and unexpected code generation issues that only seem to appear with how we use the compiler (we're a JIT, we run passes in a specific way, etc, etc)
• Random, and unexpected code generation issues that only seem to appear with less popular platforms. We've struggled in the past with problems on ARM and PPC which have blocked releases, or forced us to split our LLVM support, using two different LLVM releases depending on which architecture.

Bigger picture: LLVM upgrades tend to offer few benefits these days and large risks, so we tend to space them out to avoid sinking a ton of time into chasing weird platform bugs. At this point, it would probably make sense to try jumping straight to LLVM 13 and only backtrack if things got hairy.

[esc]

Bigger picture: LLVM upgrades tend to offer few benefits these days and large risks, so we tend to space them out to avoid sinking a ton of time into chasing weird platform bugs. At this point, it would probably make sense to try jumping straight to LLVM 13 and only backtrack if things got hairy.

Yes, I think there are some issues related to ORC-Jit maturity, which will make a jump to 13 more favourable for us.

[niyas-sait]

Historically, the biggest issue was changing C++ interfaces, but we've isolated ourselves pretty well from those, and LLVM has slowed down the churn on its public interfaces. These days, the most common issues are:

• Random, and unexpected code generation issues that only seem to appear with how we use the compiler (we're a JIT, we run passes in a specific way, etc, etc)
• Random, and unexpected code generation issues that only seem to appear with less popular platforms. We've struggled in the past with problems on ARM and PPC which have blocked releases, or forced us to split our LLVM support, using two different LLVM releases depending on which architecture.

Bigger picture: LLVM upgrades tend to offer few benefits these days and large risks, so we tend to space them out to avoid sinking a ton of time into chasing weird platform bugs. At this point, it would probably make sense to try jumping straight to LLVM 13 and only backtrack if things got hairy.

Thanks. I was specifically looking for windows on arm64 support and I think we need LLVM 12+ for that.

I think it makes sense to make a jump to LLVM 13 directly if possible.

I played around a bit to see what changes are required for the latest LLVM support and seems like only minor changes are required

• TargetRegistry.h location is changed
• PrintMachineCode is removed from TargetOpt.

All of the unit tests except one are passing. it seems to be due to some argument attributes missing in the LLVM value object.

I haven't tried with numba so not sure if there are any other impacts.

[r-barnes]

#802 compiles with LLVM-12 on my machine and passes all tests triggered by ./runtests.py.

[esc]

#802 compiles with LLVM-12 on my machine and passes all tests triggered by ./runtests.py.

Thank you again for submitting this. FYI: I should also note that in order to test this 'properly' we will need:

a) Build LLVM on all supported architectures
b) Build & test llvmlite based on that across all architectures and Python versions
c) Build & test Numba based on all the above and test across the cross product of all architectures, Python versions and supported Numpy's

This process usually takes about week, most of it is compute time. Trying to emphasize here that "compiles on my machine" will not suffice to get this over the line, but I think we all knew that already, right? 😆

[r-barnes]

This, @esc, of course more extensive testing is needed, but working on 1 machine is much better than 0 machines.

I've also tested with LLVM 11 and ./runtests.py also passes cleanly with that version.

LLVM 9 does not appear to be supported by llvmlite any more: llvmlite would not compile when I tested with that.

I also compiled with LLVM 13 by enabling that (not included in the current PR) and ./runtests.py passes for that version as well.

[KOLANICH]

a) Build LLVM on all supported architectures

LLVM supplies prebuilt libs for some distros, and so do distros, and they should be used instead of own-built llvm

[surak]

Does this issue still make sense, since LLVM's stable version now is 13?

[esc]

Does this issue still make sense, since LLVM's stable version now is 13?

We haven't quite figured that one out yet. The discussion is a bit fragmented across issues. Most of it is now here:

#802

[r-barnes]

@surak: llvmlite's interface with LLVM seems to be identical between 12 and 13. Slower-moving groups like US DoE National Labs and non-agile tech might settle on LLVM-12, so it seems like having a bridge release would give you an easy place to point to if folks need that support.

[gmarkall]

Closing as we're on LLVM 14 now and have no plans to specifically support 12 or 13.