Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM 16 Support #289

Open
frantisekz opened this issue Apr 14, 2023 · 29 comments
Open

LLVM 16 Support #289

frantisekz opened this issue Apr 14, 2023 · 29 comments
Assignees

Comments

@frantisekz
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

Thanks for the info!

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

Thanks a lot!

@eero-t
Copy link

eero-t commented May 16, 2023

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

@ConiKost
Copy link
Contributor

Does anyone know the current status about LLVM 16 support?

@frantisekz
Copy link
Contributor Author

frantisekz commented Aug 16, 2023

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
Copy link
Contributor

@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
Copy link

eero-t commented Aug 18, 2023

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

@ConiKost
Copy link
Contributor

@AGindinson thanks for the update!

@AGindinson
Copy link
Contributor

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
Copy link
Contributor

Any news on LLVM16 support?

@tjaalton
Copy link

or llvm17 for that matter

@pszymich
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link

eero-t commented May 10, 2024

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
Copy link

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
Copy link

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
Copy link

eero-t commented Jun 27, 2024

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
Copy link

tuliom commented Jun 27, 2024

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
Copy link
Contributor

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
Copy link
Contributor

pszymich commented Jul 5, 2024

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
Copy link
Contributor

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

@ConiKost
Copy link
Contributor

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

@pszymich
Copy link
Contributor

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.

@pszymich pszymich pinned this issue Sep 24, 2024
@kloczek
Copy link

kloczek commented Sep 24, 2024

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

@pszymich
Copy link
Contributor

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

@frantisekz
Copy link
Contributor Author

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
Copy link
Contributor

@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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants