Clang::CodeGenSPIRV test for attribute.domain.isoline.hlsl is failing on ARM64 Release on Windows

[hekota]

Description
Clang::CodeGenSPIRV test for attribute.domain.isoline.hlsl is failing on ARM64 Release on Windows

Steps to Reproduce
hctbuild -spirv -arm64 -Release
hcttest -spirv -arm64 on ARM64 machine such as Surface Pro.

Actual Behavior

FAIL: Clang :: CodeGenSPIRV/attribute.domain.isoline.hlsl (10 of 1986)
******************** TEST 'Clang :: CodeGenSPIRV/attribute.domain.isoline.hlsl' FAILED ********************
Script:
--
C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\dxc.EXE -T hs_6_0 -E SubDToBezierHS -fcgl  C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl -spirv | C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\FileCheck.EXE C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl
--
Exit Code: 2147500037

Command Output (stdout):
--
Command 0: "C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\dxc.EXE" "-T" "hs_6_0" "-E" "SubDToBezierHS" "-fcgl" "C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl" "-spirv"
Command 0 Result: 2147500037
Command 0 Output:


Command 0 Stderr:
fatal error: generated SPIR-V is invalid: ControlBarrier: Memory Semantics can have at most one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent

  OpControlBarrier %uint_2 %uint_4 %uint_0



note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible





Command 1: "C:\agent\_work\1\b\build\ARM64\DXC\Release/bin\FileCheck.EXE" "C:\agent\_work\1\s\DXC\tools\clang\test\CodeGenSPIRV\attribute.domain.isoline.hlsl"
Command 1 Result: 2
Command 1 Output:


Command 1 Stderr:
FileCheck error: '-' is empty.

Environment
DXC version: main as of 1/22/2024
Surface Pro, Windows 11 (26016.1001, arm64)

[s-perron]

This is odd. The instruction is correct. The memory semantics is %uint_0, which means none of the semantics are set. I looked at the code in the validator, and it looks correct as well. I'm wondering if there was a miscompilation somewhere.

We'll have to see if we can get access to a windows arm device. We generally do not have those immediately available to us.

[MarijnS95]

Heya, just quickly chiming in as we've started running into this and I'm beginning to debug this now: we used to be on quite an old self-compiled DXC from 74a3206. We didn't compile for aarch64 back then and there's no CI run available anymore with the binaries (and I haven't compiled this locally yet), so I picked the most recent March 2024 release after that (we were on that git hash because some of our issues were addressed prior).

On x64 Linux and Windows this works totally fine, but on aarch64 Windows some of our shaders fail to compile with the exact same Memory Semantics error:

Caused by:
    0: Failed to compile shader `C:\Users\marij\Code\breda\crates\breda-nn\assets/shaders\mae.cs.hlsl`
    1: fatal error: generated SPIR-V is invalid: ControlBarrier: Memory Semantics can have at most one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent
         OpControlBarrier %uint_2 %uint_2 %uint_264

       note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible

The exact same issue remains on the latest January 2025 release but there a separate regression appears, already reported & tracked at #7181 (and this appears on our shaders with Vulkan ValidationLayers release 304 and 309 too). Going back to the July 2024 release to back out of that, the above Memory Semantics error remains.

Then some of our other shaders also fail with a different error:

Caused by:
    0: Failed to compile shader `C:\Users\marij\Code\breda\crates\breda-gtao\assets/shaders\gtao-temporal.cs.hlsl`
    1: fatal error: generated SPIR-V is invalid: Number of image operand ids doesn't correspond to the bit mask
         %149 = OpImageSampleExplicitLod %v4float %148 %134 Lod %float_0

       note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible

And that one is already reported at #7174, also from ARM64.

---

I hope to follow up on this soon with better debugging info, just jotting down some notes on what I'm seeing for now!

[MarijnS95]

For both this ControlBarrier: Memory Semantics can have at most one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent and Number of image operand ids doesn't correspond to the bit mask from #7174, it must be a miscompile in SPIRV-Tools. I've followed this suggestion to disable validation with -Vd and the resulting spirv-dis output from x64 and arm64 Windows is identical bar the /Vd flag showing up in OpModuleProcessed as expected.

EDIT: To rule out a difference in spirv-dis, even a binary diff between the two files only shows the CLI parameter difference in OpModuleProcessed.

EDIT2: Using spirv-val from the latest SDK release with version SPIRV-Tools v2025.1 v2025.1.rc1-0-gf289d047 on these binaries shows no issues (and VVL doesn't complain either when loading these pipelines on a Qualcomm X Elite laptop), unless I need to expose this with special flags? Perhaps this has already been addressed upstream, and the recent update of SPIRV-Tools might transitively address this as well?

[MarijnS95]

It might be a problem specifically with the public (cross-compiled from x64?) releases (which I'm currently trying to replicate, combining Windows and CMake and cross-compilation seems to cubed (³) trouble...).

After checking out and compiling dxcompiler.dll natively on and before c9170e5 (the SPIRV-Tools update), and even on the v1.8.2407 tag whose release appears to be cross-compiled, I cannot reproduce this error (Release build with all {CLANG,HLSL,LLVM}_INCLUDE_TESTS turned OFF because of TAEF dependencies).

Later I also tested a recent commit 47e11af from yesterday, no issues either.

After setting up a cross-compile from Windows x64 (shout-out to #7000 (comment), which I later found in hctbuild.cmd) in GitHub actions, a dxcompiler.dll for ARM64 also does not suffer from any of these issues.

For completeness I finally cross-compiled the July 2024 release which I previously had problems with, and no issues either. This leads me to believe that the problem is with how the release dlls are compiled. Can anyone from Microsoft help shine a light on that?

---

On this note, has there been any progress towards providing per-commit build artifacts from the CI? This disappeared when AppVeyor got (understandably) deprecated but no alternative emerged since. It's "easy" to set up in GitHub actions and goes a long way towards testing fixes and regressions. Thanks for considering 🙏 (and holler if you welcome such a contribution).