Setup AMD GPU CI on Alps MI300

[luraess]

No description provided.

[luraess]

cscs-ci run

[luraess]

cscs-ci run

[luraess]

cscs-ci run

[wsmoses]

@luraess we shouldn't need to do that, we can just set flags that we pass to the bazel exe, like in https://github.com/EnzymeAD/ReactantBuilder/blob/f341d32d310c9d7c175f4e9bd13e8f44a42fae03/R/Reactant/build_tarballs.jl#L109

via build_local.jl we should (in principle) be able to pass them with https://github.com/EnzymeAD/Reactant.jl/blob/562863ddc7659c786d38b201317f6c7ce39b57f3/deps/build_local.jl#L112

[luraess]

Thanks for the pointer. Included it

[luraess]

@wsmoses I am close to getting things to compile on MI300 but ROCm build fails compiling xla/pjrt/triton_rocm.cc — mlir::PropertyRef not found in Triton-generated Ops.h.inc

CI log is available here https://gitlab.com/cscs-ci/ci-testing/webhook-ci/mirrors/8804541097822692/4070757937813711/-/jobs/15188043508#L3378

Summary

Building libReactantExtra.so with --config=rocm for AMD MI300 (gfx942) fails on a single target, @xla//xla/pjrt:triton_rocm. The build otherwise completes (69,959 / 69,961). Triton's TableGen-generated op-adaptor code uses mlir::PropertyRef, which the MLIR headers in scope don't provide — a Triton ↔ MLIR API skew that only surfaces on the ROCm Triton path.

Error

In file included from external/xla/xla/pjrt/triton_rocm.cc:65:
In file included from external/triton/include/triton/Dialect/Triton/IR/Dialect.h:22:
bazel-out/.../external/triton/include/triton/Dialect/Triton/IR/Ops.h.inc:581:69:
  error: no type named 'PropertyRef' in namespace 'mlir'; did you mean 'Properties'?

Followed by a cascade of unknown type name 'Properties' / no member named 'callee' in 'mlir::EmptyProperties' from the same generated adaptor (20+ errors).

Effective dependency pins

Reactant main only clones; the compiled XLA/Triton/LLVM come transitively from Enzyme-JAX's JAX_COMMIT (Enzyme-JAX → JAX → XLA → LLVM + Triton). CI rewrites Reactant's ENZYMEXLA_COMMIT to our Enzyme-JAX SHA.

Reactant.jl : 373f53f2fb46bff3a37c10fbac4e08c61e76fbfb (main)
Enzyme-JAX  : b61b8fcc181a077c2cf7837eaa2106ec74c84736  (ENZYMEXLA_COMMIT)
JAX         : d72694890a8dd1911435edc8f5732af0c58054f5
XLA         : b81e8a170eef4b4adce22afabc1639f928f0e82d
LLVM/MLIR   : 87d42c13cd6b119240781f31e5869981d500a186  (LLVM 23 dev)
Triton      : 886365ca82b03edef597b0d2c8c32be62ac2546b

Target: AMD MI300 / gfx942, --config=rocm, CSCS UENV toolchain (clang/LLVM 23).

[wsmoses]

@mofeing re rebase / triton stuff

[wsmoses]

@luraess also just to confirm can you rebase on main?

[luraess]

WRT Triton issue after rebase:

Rebased this branch onto current main and re-ran on the CSCS MI300 runner. The overlay/toolchain now builds essentially the whole tree — 69,941 / 70,015 — and fails on a single target, @xla//xla/pjrt:triton_rocm:

Ops.h.inc:581: error: no type named 'PropertyRef' in namespace 'mlir'; did you mean 'Properties'?

(followed by a cascade of unknown type name 'Properties' / no member named 'callee' in 'mlir::EmptyProperties' from Triton's generated Triton/IR/Ops.h.inc.)

This is a Triton↔MLIR API skew on the ROCm Triton path — triton_rocm.cc is the only Triton consumer built with the HIP toolchain. It is not CI-environment related: it reproduces on rebased main across two independent XLA revisions:

• earlier: JAX d7269489 → XLA b81e8a17 / LLVM 87d42c13 / Triton 886365ca
• current: JAX c97aeac4 → XLA a1f9965a / LLVM 2377f825 / Triton feb6c04a (Enzyme-JAX 602152cf, LLVM 23 dev)

Reaching this point required these ROCm-overlay fixes (all in this PR): HIP resource-dir funneling via HIP_CLANG_PATH; AMDGPU device-bitcode under both amdgcn/bitcode and lib/llvm/amdgcn/bitcode; keeping .rocm/amdgcn a real dir; and seeding rocm_smi/ from rocm-smi-lib (required by newer XLA's rocm_smi_util.cc).

[wsmoses]

build works, looks like you need to add rocm libs to ld_library_path?