Execution Tests: Add min precision test cases to the long vector test

[alsepkow]

This PR extends the SM 6.9 long vector execution tests to cover HLSL min precision types (min16float, min16int, min16uint). These types are always available — D3D12_SHADER_MIN_PRECISION_SUPPORT only reports whether hardware actually uses reduced precision, not whether the types compile — so no device capability check is needed and the tests live in the existing DxilConf_SM69_Vectorized_Core class alongside other types.

Note: I wasn't able to find any existing min precision HLK tests. Unclear if we have coverage.

Key design decisions

Full-precision buffer I/O: Min precision types have implementation-defined buffer storage width, so we use full-precision types (float/int/uint) for all Load/Store operations via the IO_TYPE/IO_OUT_TYPE shader defines, with explicit casts to/from the min precision compute type. This ensures deterministic data layout regardless of the device implementation.

Half-precision tolerances: Validation compares results in fp16 space using HLSLHalf_t ULP tolerances. Since min precision guarantees at least 16-bit, fp16 tolerances are a correct upper bound — devices computing at higher precision will produce more accurate results, not less.

Test coverage mirrors existing patterns:

• min16float mirrors HLSLHalf_t (float/trig/math/comparison/dot/cast/derivative/wave/quad/load-store)
• min16int mirrors int16_t (arithmetic/bitwise/comparison/reduction/cast/wave/quad/load-store)
• min16uint mirrors uint16_t (arithmetic/bitwise/comparison/cast/wave/quad/load-store)

Wave and quad op support: Wave ops (WaveActiveSum/Min/Max/Product/AllEqual, WaveReadLaneAt/First, WavePrefix*, WaveMultiPrefix*, WaveMatch) and quad ops (QuadReadLaneAt, QuadReadAcrossX/Y/Diagonal) are tested for all three min precision types, mirroring the ops supported by their 16-bit equivalents. The wave op shader helpers use #ifdef MIN_PRECISION guards to store results via IO_OUT_TYPE for deterministic buffer layout without changing DXIL for existing non-min-precision tests.

Excluded operations:

• Signed div/mod on min16int: HLSL does not support signed integer division on min precision types
• Bit shifting on min16int/min16uint: Not supported for min precision types
• FP specials (INF/NaN/denorm): min precision types do not support them

Resolves #7780

All tests require the rawBufferVectorLoad/Store fix from : #8274
The array accessor and wave/quad op tests for min precision require the optimizer fix from: #8269

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[github-actions]

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:

git-clang-format --diff f62b9b4be05f76adb41134e3abd9323be71e68f4 470302b8b01fa350eafe64215fb65e380ea14ab7 -- tools/clang/unittests/HLSLExec/LongVectorTestData.h tools/clang/unittests/HLSLExec/LongVectors.cpp

View the diff from clang-format here.

diff --git a/tools/clang/unittests/HLSLExec/LongVectorTestData.h b/tools/clang/unittests/HLSLExec/LongVectorTestData.h
index 2e8458b9..f77bab92 100644
--- a/tools/clang/unittests/HLSLExec/LongVectorTestData.h
+++ b/tools/clang/unittests/HLSLExec/LongVectorTestData.h
@@ -718,8 +718,8 @@ INPUT_SET(InputSet::Zero, 0);
 INPUT_SET(InputSet::BitShiftRhs, 1, 6, 3, 0, 9, 3, 8, 8, 8, 8);
 INPUT_SET(InputSet::SelectCond, 0, 1);
 INPUT_SET(InputSet::AllOnes, 1);
-INPUT_SET(InputSet::WaveMultiPrefixBitwise, 0x0, 0x1, 0x3, 0x4, 0x10, 0x12,
-          0xF, 0x7FFF);
+INPUT_SET(InputSet::WaveMultiPrefixBitwise, 0x0, 0x1, 0x3, 0x4, 0x10, 0x12, 0xF,
+          0x7FFF);
 END_INPUT_SETS()
 
 #undef BEGIN_INPUT_SETS

• Check this box to apply formatting changes to this branch.

[alsepkow]

Discussion: Shift operator semantics for min precision integer types

While working on these tests, I investigated how << and >> work on min16int/min16uint and found a potential semantic ambiguity worth discussing with the team.

How shifts are implemented

Shift operators aren't intrinsics — they're built-in binary operators handled through Clang's Sema/CodeGen layers:

• Sema validation: SemaHLSL.cpp classifies shifts as "bitwise" ops requiring integral types (BinaryOperatorKindIsBitwise → BinaryOperatorKindRequiresIntegrals → IsBasicKindIntegral). min16int and min16uint have BPROP_INTEGER set, so they pass validation. min16float is correctly rejected.

• Shift amount wrapping: HLSL wraps shift amounts like OpenCL — the RHS is masked by (bit_width - 1). This happens in CGExprScalar.cpp:EmitShl/EmitShr:

  if (CGF.getLangOpts().OpenCL || CGF.getLangOpts().HLSL)
      RHS = Builder.CreateAnd(RHS, GetWidthMinusOneValue(Ops.LHS, RHS), "shl.mask");

The ambiguity

min16int has AST Width = 16 (ASTContext.cpp:1683), producing LLVM IR type i16 (CodeGenTypes.cpp:437). So GetWidthMinusOneValue returns 15, and the shift amount is masked with & 15 (mod 16).

However, in min precision mode (UseMinPrecision=true), the hardware executes on 32-bit registers. The & 15 mask is baked into the IR before any min-precision-to-32-bit promotion. This means:

• The shift amount is clamped to [0, 15] based on the declared 16-bit type
• But the actual shift executes on a 32-bit value

For left shift, this is arguably fine — bits above 15 are "extra precision." For right shift, it's murkier — if the 32-bit register has bits set above bit 15 from prior operations, a right shift masked to [0, 15] won't clear them the way a true 16-bit right shift would.

Compare to int32_t where the mask is & 31 and execution width matches. For min precision, the wrapping width (16) doesn't necessarily match the execution width (potentially 32).

Test data is safe

The BitShiftRhs input set for int16_t/uint16_t (reused by Min16Int_t/Min16UInt_t) uses values {1, 6, 3, 0, 9, 3, 12, 13, 14, 15} — all within [0, 15], so we avoid the ambiguous boundary. This was intentional.

Existing test coverage

• Sema tests (scalar-operators.hlsl): verify type rules for min16 shifts ✅
• FileCheck tests for shift IR output on min precision: none ❌
• Execution tests for min precision shifts: this PR adds the first ones ✅

Questions for the team

1. Is the & 15 mask correct for min precision types, or should it be & 31 to match the actual execution width?
2. Should we add a boundary-probing test (e.g., shift by 16) to document/pin down the current behavior?
3. Is this a known design decision or a gap that should be tracked as a separate issue?

[tex3d]

LGTM!