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/