LLVM 16 Support

[frantisekz]

I understand this isn't a priority, but I'll at least try to create a sort of tracking issue/help where I can (not much tbh).

Distributions are already migrating to LLVM 16 (upcoming Fedora 38 to be released in a few days uses that), and it'll be great if there was planned igc support for that.

Currently hit issues:

• Ton of opencl-clang problems (worked around, created PRs upstream, got it building)
• CCLANG_SONAME_VERSION check doesn't pass (hits <= 5.0.0 path) for opencl-clang built against llvm 16 - disabled that check to be able to progress
• llvm:None was deprecated (advisory to use std::nullopt_t, seems like a drop-in? I can go ahead and create a PR for that)
• error: cannot convert 'llvm::StringLiteral' to 'const char* const' in initialization (hit in IGC/Options/include/igc/Options/)
• probably many more...

I hope @AGindinson wouldn't mind for a ping here? I remember you've worked on fresh LLVM support for past few releases.

[AGindinson]

Hi @frantisekz, thanks for reporting this and listing out the initial issues! Although our current focus is on finalizing the LLVM 14 switch in terms of production quality, we've had an initial look into API compatibility with LLVM 16. Hopefully, we'll be able to make some real progress over the course of May.

[frantisekz]

Thanks for the info!

Please, ping here whenever there is something I can help test/provide feedback/etc.

Thanks a lot!

[eero-t]

vc-intrinsics v0.13.0 (tagged today) has some LLVM 16 support fix: intel/vc-intrinsics@v0.12.3...v0.13.0

[ConiKost]

Does anyone know the current status about LLVM 16 support?

[frantisekz]

Does anyone know the current status about LLVM 16 support?

Afaik, it's the same as what I'd reported when creating the ticket (minus Ton of opencl-clang problems and
CCLANG_SONAME_VERSION check doesn't pass which got resolved opencl-clang side).

Use LLVM 14 (preferably) or 15.

[AGindinson]

@ConiKost, now that LLVM 14 support has finally reached production quality (and stands as the recommended version, as noted by @frantisekz), we're slowly returning to pursue LLVM 16 compatibility. One of the key issues here is proper opaque pointers' support, which is being investigated in parallel.

[eero-t]

Could v16 be added to the LLVM status tracking page: https://github.com/intel/intel-graphics-compiler/projects/5 ?

[ConiKost]

@AGindinson thanks for the update!

[AGindinson]

Could v16 be added to the LLVM status tracking page: https://github.com/intel/intel-graphics-compiler/projects/5 ?

@eero-t Done, thanks for the suggestion!

[ConiKost]

Any news on LLVM16 support?

[tjaalton]

or llvm17 for that matter

[pszymich]

Hi, let me shed some light and transparency on the current LLVM situation. Our aim is to start working on LLVM 15 support this quarter with production switch later this year. We are still working on LLVM 14 support for our Windows driver which is the main reason for lack of progress on the open-source side of things.
LLVM updates after switching to 15 will require significant work on opaque pointers situation which is going to majorly affect the roadmap.

[frantisekz]

Thanks for the update/confirmation @pszymich .

For Fedora packaging (can't speak about RHEL), I'd switched the igc package to llvm15 which is going to work fine for Fedora for the foreseeable future (and it's still a far better situation compared to eg. intel cm-compiler which has the latest tagged release for llvm 8).

Just (you're probably aware) llvm 16 should work with typed pointers too ( https://llvm.org/docs/OpaquePointers.html#version-support ) if that best effort support works for you and should you need a newer target.

[pszymich]

While this is an option - "best effort" is not necessarily something we would be comfortable with in production environment, especially when talking about the foundation of the compiler.
Moving forwards we may consider running testing on such configuration, but any signs of LLVM issues would disqualify 16 integration before opaque pointers support.

[eero-t]

Just (you're probably aware) llvm 16 should work with typed pointers too ( https://llvm.org/docs/OpaquePointers.html#version-support ) if that best effort support works for you and should you need a newer target.

FOSDEM presentation about LLVM in IGC gives info on that: https://fosdem.org/2024/schedule/event/fosdem-2024-2501-challenges-of-supporting-multiple-versions-of-llvm-in-intel-graphics-compiler/

[tjaalton]

I wonder what the status is right now, as that presentation was 4mo ago and the latest release has commit dbe9942 that says 'opaque pointers', but that (alone) doesn't fix the build with >=16..

[tjaalton]

note that llvm-14 (and i-g-c etc) have been removed from Debian testing, so it won't be in the next release.

[eero-t]

While at it, also LLVM version status tracking (https://github.com/intel/intel-graphics-compiler/projects/5) should be moved to new GH projects as GH is phasing out the legacy projects by August.

[tuliom]

note that llvm-14 (and i-g-c etc) have been removed from Debian testing, so it won't be in the next release.

I've just started a discussion in Fedora in order to stop distributing llvm 14, 15 and 16 in Rawhide and Fedora 41.
Link to the discussion: https://lists.fedoraproject.org/archives/list/[email protected]/thread/TDSWXZU27YVCVEBV4UUX7Z7FE56ZFUL5/

[ConiKost]

Same applies for Gentoo. LLVM-14 already removed, LLVM-15 also waits for removing and only waits because of IGC. LLVM16 is planed also to be removed in future, since LLVM17 and LLVM18 is already in Gentoo tree.

[pszymich]

We are committed to bringing IGC to latest LLVM versions, and we are implementing a much more robust LLVM upgrade processes to accelerate new versions integration. Until new processes are in place, we are also working on LLVM 16 build compatibility in parallel.
We are expecting IGC to be LLVM 16 compatible mid-August, according to experience from previous versions. Also as in previous efforts, we will follow this with fixes to functional/performance quality of the compiler which should happen much faster given new processes.

[pszymich]

As mid-August approaches it is most likely we not going to meet the date. Current realistic estimate is mid-September.

[ConiKost]

@pszymich Could you please share an update of the status? Thanks!

[pszymich]

We've pushed a number of changes addressing LLVM 16 compatibility which resolved around 90% of the raw complier errors. In the next two weeks we should manage to be fully compatible with LLVM 16 APIs.
To build IGC however, we will need to resolve LIT testing errors afterwards, for which we cannot give any reasonable ETA until we see the number of failures.

[kloczek]

May I ask ticket owner to change subject to "Latest LLVM 19 Support"?

[pszymich]

Once compatible with LLVM 16, we will follow up with a separate ticket for LLVM 17.

[frantisekz]

Just a note, in case any of the commenters here (or in the closed issue) are Fedora users wanting to get rid of llvm15 - expect at least half year up to year wait (till F43) as compute-runtime dropped support for pre-Xe architectures, I'll be halting rebases of both igc and compute-runtime to give users on older platforms some support window for their compute workloads.

(Sorry for bit of tangent/off-topic here)

[ArchangeGabriel]

@frantisekz I haven’t looked in depth, but it seems you can still build legacy platforms support with NEO_LEGACY_PLATFORMS_SUPPORT=True. I will look into it when I have time (which is not anytime soon), but I guess at worst the idea will be to provide two packages, one being stuck at legacy platform last releases.

[tjaalton]

llvm-16 is slowly getting removed from Debian already, so I hope the jump to llvm-19 won't be as big as from 14 to 16..
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075944

[ConiKost]

@pszymich Any news?

[pszymich]

Since commit be3d472 scalar compiler can be compiled successfully. Vector compiler is still being worked on. Needed adjustments in VC are significant, eg. 96a6d67.

Today we are adding LLVM 16 build to the Github Action workflow in this repository.

[ConiKost]

@pszymich Thanks for the update. Any ETA for VC?