@haampie, @srekolam can one of you please take a look? It really helps with simplifying specs and environment configs at olcf

Please resolve conflicts for the four packages.

Very cool! I don't think there's anything special about the ROCm mathlibs (e.g., rocfft, rocblas, rocsolver) with respect to xnack. My understanding is that we specified xnack- on most of our default build architectures because there was a performance benefit for doing so and we didn't have users that needed xnack (except on gfx90a).

It might be nice to make all the options available to all packages with an amdgpu_target variant (not just the mathlibs). The list of possible amdgpu_target values with all possible combinations of target features becomes overwhelmingly long in spack info <package>, though.

@chuckatkins Please resolve the conflicts for this PR

It seems part of this PR overlaps with #33871 @cgmb @chuckatkins Can you have a look if anything is to be salvagead here, or if it is better to close the PR?

Can you have a look if anything is to be salvagead here, or if it is better to close the PR?

This change adds logic that allows Spack to reason about target features, which is something that is still notably missing from ROCmPackage on develop. The proposed change significantly improves the logic surrounding target features, but would only make them available for certain libraries. When compared to the status quo, that's one step forward and one step back.

There is a bunch of useful logic that could be salvaged from this PR, but I don't think it has quite the right model for the amdgpu_target. It's not just a matter of fixing the merge conflicts; there are design decisions to be made.

Closing, since there has been no activity in a while.