Skip to content

Add support for llvm-amdgpu as compiler#268

Merged
msimberg merged 1 commit intoeth-cscs:mainfrom
msimberg:llvm-amdgpu-compiler
Nov 17, 2025
Merged

Add support for llvm-amdgpu as compiler#268
msimberg merged 1 commit intoeth-cscs:mainfrom
msimberg:llvm-amdgpu-compiler

Conversation

@msimberg
Copy link
Copy Markdown
Collaborator

This is useful to be able to build rccl-tests which wants to be built with llvm-amdgpu (cf. spack/spack-packages#2212).

The use of compilers.get('llvm-amdgpu') in the jinja templates is because compilers.llvm-amdgpu is interpreted as "access the llvm key of compilers.

@msimberg
Copy link
Copy Markdown
Collaborator Author

Any objections to merging this?

@msimberg
Copy link
Copy Markdown
Collaborator Author

I'll go ahead and self-merge this. Let me know if you notice anything off after it's been merged.

@msimberg msimberg merged commit 1ff83e6 into eth-cscs:main Nov 17, 2025
2 checks passed
@msimberg msimberg deleted the llvm-amdgpu-compiler branch November 17, 2025 11:32
msimberg added a commit that referenced this pull request Nov 17, 2025
I left out the template file for llvm-amdgpu in #268. This PR adds that
file.
msimberg added a commit that referenced this pull request Nov 20, 2025
Based on top of #268. It's easiest to only look at the unique commit for
this PR:
3ed904a.

This is the second change I need to be able to concretize `rccl-tests`
with `llvm-amdgpu` as the compiler. This adds a configuration option to
control the `concretizer:duplicates:strategy` configuration option. For
`rccl-tests` I need to set the option to `full`, instead of the default
`minimal`.

Unfortunately I can't really explain why this is required. The docs
explain a bit what the different options do:
https://spack.readthedocs.io/en/latest/build_settings.html.
```
  duplicates:
    # "none": allows a single node for any package in the DAG.
    # "minimal": allows the duplication of 'build-tools' nodes only
    # (e.g. py-setuptools, cmake etc.)
    # "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
```
I've asked for feedback on the spack slack:
https://spackpm.slack.com/archives/C059JUS9T38/p1761907568615009.

In the meantime I'm going to assume that this will be needed. I don't
quite like that this is another ad-hoc spack configuration option
exposed in the config. It'd be nice to just have a `concretizer` section
exposed in `environments.yaml`, but that's a breaking change (`unify` is
not nested under `concretizer`). Alternatively, perhaps it should be
possible to supply a completely separate spack configuration that can be
used to override anything, without having to add support for every
single configuration option explicitly.

---------

Co-authored-by: Alberto Invernizzi <9337627+albestro@users.noreply.github.com>
msimberg added a commit to eth-cscs/alps-uenv that referenced this pull request Nov 24, 2025
Requires eth-cscs/stackinator#268 and
eth-cscs/stackinator#269.

With the `full` concretizer strategy, unfortunately some packages are by
default concretized with `llvm-amdgpu` as compiler. I've forced them to
use `gcc` as the compiler.

`rccl-tests` and `aws-ofi-rccl` are unversioned, so I'm pinning them to
recent commits just for reproduciblity. I need to try
https://github.com/HewlettPackard/open-ofi-xccl eventually in place of
`aws-ofi-rccl` as `open-ofi-xccl` should be the preferred long term
solution as far as I understand, but for now `aws-ofi-rccl` seems to
work and gives decent performance.
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

Successfully merging this pull request may close these issues.

3 participants