Translator produces malformed SPIR-V for HIP + --offload-arch=amdgcnspirv after upstream clang PR #197745 ("remove innocuous addrspacecasts")

[lamb-j]

Summary

Since ROCm/llvm-project amd-staging picked up upstream LLVM commit 2825dfa027e6 ("[clang] remove lots of "innocuous" addrspacecasts (#197745)", landed May 15, 2026), translating HIP code with clang -x hip --offload-arch=amdgcnspirv ... produces SPIR-V that fails translator validation. With LLVM_ENABLE_ASSERTIONS=ON the translator aborts; with assertions off it silently writes a malformed .spv.

Symptom

With assertions ON:

amd-llvm-spirv: lib/SPIRV/libSPIRV/SPIRVInstruction.h:653:
  virtual void SPIRV::SPIRVStore::validate() const:
  Assertion `(getValueType(PtrId)->getPointerElementType()->isTypeUntypedPointerKHR() ||
             (getValueType(PtrId)->getPointerElementType()->isTypePointer() &&
              getValueType(ValId)->isTypeUntypedPointerKHR()) ||
             getValueType(PtrId)->getPointerElementType() == getValueType(ValId)) &&
             \"Inconsistent operand types\"' failed.
PLEASE submit a bug report ...
Stack dump:
  0. Program arguments: amd-llvm-spirv --spirv-max-version=1.6 --spirv-ext=+all,-SPV_KHR_untyped_pointers --spirv-allow-unknown-intrinsics --spirv-lower-const-expr --spirv-preserve-auxdata --spirv-debug-info-version=nonsemantic-shader-200 <input>.bc -o <output>.spv
  1. Running pass \"SPIRV::LLVMToSPIRVPass\"

With assertions OFF, no crash, but the produced SPIR-V is invalid per spirv-val:

error: line 150: ID '73[%_Z11clean_valuePf]' has not been defined
  %76 = OpExtInst %void %2 1 %_Z11clean_valuePf %75

Reproducer

Any of the amd/comgr/test-lit/spirv-tests/*.hip tests in ROCm/llvm-project triggers it. Smallest is spirv-translator.hip:

clang -x hip --offload-arch=amdgcnspirv \
  -nogpulib -nogpuinc --no-gpu-bundle-output --offload-device-only -O3 \
  amd/comgr/test-lit/spirv-tests/spirv-translator.hip -o out.spv

Equivalent cl tests (e.g. spirv-translator.cl) PASS — the regression is HIP-path specific.

Bisect

llvm-project clang SHA	SPIRV translator	Result
97ce93a054d9 (parent of suspect)	merge containing upstream 78ee81dd	✅ produces valid SPIR-V
2825dfa027e6 … a5de13684b (current amd-staging tip)	resolve-may-15 (old translator)	❌ assert / invalid SPIR-V
2825dfa027e6 … a5de13684b (current amd-staging tip)	merge containing upstream 78ee81dd	❌ assert / invalid SPIR-V

So the regression is bisected to upstream LLVM commit:

2825dfa027e6 clang: remove lots of "innocuous" addrspacecasts (#197745) — Jameson Nash, 2026-05-15

That PR's own message notes "This PR does not yet fix all calls, but the main ones that might have been missed are in matrix/vector extensions ..." — i.e. it was landed partially. The HIP-via-amdgcnspirv path appears to be one of the unfinished cases: the translator now sees a Store whose pointer-element type and value type no longer match, because clang no longer inserts the bridging addrspacecast.

Why CI didn't catch this on amd-staging

The new SPIRV-CI workflow (in this repo, on amd-staging) builds the translator with LLVM_ENABLE_ASSERTIONS=ON and explicitly runs check-comgr against an in-tree build — that's how it surfaced. Compiler-team PSDB / regular amd-staging Comgr builds are typically Release without assertions, so the assert is a no-op and the malformed SPIR-V goes downstream without obvious error.

Suggested next steps

• File / link an upstream issue against KhronosGroup/SPIRV-LLVM-Translator (the broken Store-emission path is upstream code at lib/SPIRV/SPIRVWriter.cpp), and/or against upstream clang to round out the PR #197745 fix.
• Short term: either revert 2825dfa027e6 on amd-staging until upstream lands the follow-up, or hold all SPIRV-translator merges that need green CI until then.

Refs

• Failing CI run: https://github.com/ROCm/SPIRV-LLVM-Translator/actions/runs/26046857758 (PR Upstream merge 2026-05-18 09:27 PDT (manual; ancestry fix) #205 — the PR itself is an ancestry-fix and is innocent)
• Suspect commit: llvm/llvm-project@2825dfa027e6

[AlexVlx]

I believe llvm/llvm-project#198428 should address it. There is probably merit in addressing it in upstream / fixing the typed ptr path, but IMHO we should not be blocked to it (and it would appear that the untyped ptr path is the preferred one going forward).