@illuhad illuhad added this to the 25.02.0 milestone May 5, 2025

I think it would be less confusing to just call it 25.06 at this point :)

I haven't tried with ROCm LLVM, but with this change it's quite likely that ROCm LLVM will be refused by default, so you may have to update your build instructions to include -DACPP_EXPERIMENTAL_LLVM=ON.

Thanks for the heads up. Indeed, this breaks with ROCm 6.2+ (or so) which migrated to Clang 18.

But what's the reason to disallow intermediate versions? I understand preventing future versions (even there, a warning would perhaps be more appropriate, IMO; LLVM is not breaking things every release, do they?) People already struggle to install ACpp, why make configuring more complex on known working configurations?

I think more useful would be a check that prevents incompatible combinations of ROCm and mainline LLVM compilers, since that is pretty non-trivial to check (if one does not use ROCm LLVM, how does one know it's version to check against the LLVM used?)

Thanks for the heads up. Indeed, this breaks with ROCm 6.2+ (or so) which migrated to Clang 18.

For what I remember minor version being 0 on ROCM LLVM is quite frequent (if not all of them). So I don't know about that check

if(${LLVM_VERSION_MINOR} EQUAL 0)
         message(SEND_ERROR "This LLVM seems to be a development version; only LLVM releases are tested and supported. Use -DACPP_EXPERIMENTAL_LLVM=ON if you still wish to try your luck.")

Could it be feasible to have a specific code path if it is rocm/llvm since most concerns in this PR are in that case ?

I think it would be less confusing to just call it 25.06 at this point :)

That would mean delaying the release by another month... I guess it depends on what the number means :) Maybe it just denotes the start of the release development cycle, rather than the release point? :)

But what's the reason to disallow intermediate versions? I understand preventing future versions (even there, a warning would perhaps be more appropriate, IMO; LLVM is not breaking things every release, do they?)

I would say more often than not, things break in some way with a newer LLVM release. Things got worse post-14 with larger changes that the LLVM community is doing such as opaque pointers and the upcoming untyped getelementptr change.
Both 19 and 20 didn't work for a long time, and IIRC 18 too required some patches.

The rationale behind preventing intermediate versions is that LLVM is a moving target, and in between intermediate versions, we have no way of determining which APIs are available and which are not. It's only working for you with ROCm LLVM (which typically sits in between releases) because you disable most of the compiler-based functionality.

People already struggle to install ACpp, why make configuring more complex on known working configurations?

IMO this PR makes it easier, because it aligns cmake behavior with what we have in our documentation and what is actually tested.

• We already state quite clearly in the documentation that only official LLVM releases are supported
• We have never tested with non-release LLVM versions, and we don't have them in CI.

Accidentally building against development versions regularly occurs with users. For example, I strongly believe that this PR could have prevented the AdaptiveCpp issues that @masterleinad encountered and presented in his IWOCL talk.

It happens again and again that people just use some clone of intel/llvm or just git clone https://github.com/llvm/llvm-project (without checking out a release branch) and then experience AdaptiveCpp not compiling, compiler crashes, or other problems.
This PR prevents that.

I think more useful would be a check that prevents incompatible combinations of ROCm and mainline LLVM compilers, since that is pretty non-trivial to check (if one does not use ROCm LLVM, how does one know it's version to check against the LLVM used?)

We could special case the situation when ROCm LLVM is targeted and a minimum compiler configuration is requested?

For what I remember minor version being 0 on ROCM LLVM is quite frequent (if not all of them). So I don't know about that check

The check is working exactly as intended :) Starting from LLVM version 18, the minor version being 0 indicates that this is a pre-release, development version of LLVM.
ROCm LLVM branches off from mainline LLVM at random points, and is indeed typically based on a pre-release version of LLVM. Since LLVM is a moving target, this means that its LLVM API support is somewhere between two LLVM versions. In this situation, there's little we can do to figure out whether a specific API that we need and that has been added/removed/changed in LLVM is actually available because we are in an ill-defined intermediate state. Sometimes things still work and can be used for experiments, but we do not have such configurations in CI. As I said, our documentation is quite clear about this.

From experience, it has become clear that it's virtually impossible for an out-of-tree LLVM-based project to robustly support arbitrary development version of LLVM. This only works when you have a fork of LLVM that is always synchronized with LLVM trunk (and even then you're not supporting arbitrary LLVM versions, but only tip-of-tree like e.g. llvm-spirv translator does).

So, this PR refusing ROCm LLVM is a consequence of ROCm LLVM typically being in between LLVM releases, and thus potentially breaking many of the LLVM compiler functionality.

As I said it might be possible to special case ROCm LLVM so that such a configuration is accepted for builds with minimum compiler compoments enabled (no SSCP, no stdpar, ...) since the less LLVM functionality is used, the less risk of breakage. And if you know what you're doing and you really, really want to build against intermediate version LLVM you can always override the check using -DACPP_EXPERIMENTAL_LLVM=ON.

Note that even if we special case ROCm LLVM with minimum compiler profile, this does not change the fact that such configurations are still untested!
To me it makes sense to highlight the fact that the user is doing something that is untested and that may break rather than silently accepting them...

We could special case the situation when ROCm LLVM is targeted and a minimum compiler configuration is requested?

Thanks, that sounds reasonable.

I think more useful would be a check that prevents incompatible combinations of ROCm and mainline LLVM compilers, since that is pretty non-trivial to check (if one does not use ROCm LLVM, how does one know it's version to check against the LLVM used?)

Here, I was referring to a different issue, e.g., when one is using mainine LLVM 17 and ROCm 6.4 (based on LLVM 19), which, IIRC, is also not supported.

So, this PR refusing ROCm LLVM is a consequence of ROCm LLVM typically being in between LLVM releases, and thus potentially breaking many of the LLVM compiler functionality.

I'd like to point out that I totally blame AMD for not identifying their version properly in LLVM's CMake integration. But sadly in the end it's usability of ACpp that suffers.

At least among our users, there's more people who don't know how what a "compiler" is than people who have random LLVM builds lying around :)

Note that even if we special case ROCm LLVM with minimum compiler profile, this does not change the fact that such configurations are still untested!

FWIW, we do test them manually for pre-releases. And, unlike any random LLVM commit, checking that ROCm LLVM works is at least feasible to do.

Thanks, that sounds reasonable.

I've added code that should skip the test if we're in a minimal compiler configuration against ROCm LLVM. The cmake detection of ROCm LLVM is new (we've had some previous code to check ROCm version, but I found it unreliable. E.g. it doesn't work on Arch ROCm packages), so it would be great if you could test whether it works for all your use cases!

Here, I was referring to a different issue, e.g., when one is using mainine LLVM 17 and ROCm 6.4 (based on LLVM 19), which, IIRC, is also not supported.

Ah right, there are some additional constraints here.
For SSCP, AdaptiveCpp LLVM must be <= ROCm LLVM due to LLVM IR compatibility guarantees between LLVM versions. I've also added an additional cmake check to enforce this now, as this is also something that users routinely stumbled over.

For SMCP, unfortunately there is no simple rule that we could "just implement" :( AMD has routinely changed things that can break compatibility with ROCm LLVM and vanilla LLVM (directory layouts, bitcode libraries, code object model, ...). Usually AdaptiveCpp LLVM == ROCm LLVM works, but it really depends on when exactly the required patches from ROCm have landed in upstream LLVM. We'd need to test every single ROCm version against different LLVM versions on an individual basis to figure out what actually works :(
So from this point of view, I can understand your position that at least building against ROCm LLVM is reliable for SMCP (well, sort of - there can be other issues :) ).

At least among our users, there's more people who don't know how what a "compiler" is than people who have random LLVM builds lying around :)

Fair :)

From my point of view, this PR is the last one I'd like to get in before release. Once you @al42and give green light, we can release from my side :)

EDIT: Looks like CI has already successfully detected that we're trying to build an incompatible compiler (SSCP with LLVM 17 vs ROCm with LLVM 15) :D Although it's fine there because we can only do ROCm compiler testing (not JITting) in Github-hosted CI. Good to see that the detection seems to be doing its job.