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

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 cb6175aa8b8258ce062fed1677f474b9f9e02a50 -- 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/LongVectors.cpp b/tools/clang/unittests/HLSLExec/LongVectors.cpp
index 28fba8d0..ed46e4b3 100644
--- a/tools/clang/unittests/HLSLExec/LongVectors.cpp
+++ b/tools/clang/unittests/HLSLExec/LongVectors.cpp
@@ -1889,7 +1889,8 @@ void dispatchMinPrecisionTest(ID3D12Device *D3DDevice, bool VerboseLogging,
   Op<OP, T, Operation.Arity> Op;
 
   // Min precision buffer storage width is implementation-defined, so we use
-  // full-precision types for Load/Store via BUFFER_TYPE/BUFFER_OUT_TYPE defines.
+  // full-precision types for Load/Store via BUFFER_TYPE/BUFFER_OUT_TYPE
+  // defines.
   for (size_t VectorSize : InputVectorSizes) {
     std::vector<std::vector<T>> Inputs =
         buildTestInputs<T>(VectorSize, Operation.InputSets, Operation.Arity);
@@ -1920,13 +1921,13 @@ void dispatchMinPrecisionWaveOpTest(ID3D12Device *D3DDevice,
   Op<OP, T, Operation.Arity> Op;
 
   // Min precision buffer storage width is implementation-defined, so we use
-  // full-precision types for Load/Store via BUFFER_TYPE/BUFFER_OUT_TYPE defines.
+  // full-precision types for Load/Store via BUFFER_TYPE/BUFFER_OUT_TYPE
+  // defines.
   for (size_t VectorSize : InputVectorSizes) {
     std::vector<std::vector<T>> Inputs =
         buildTestInputs<T>(VectorSize, Operation.InputSets, Operation.Arity);
 
-    auto Expected =
-        ExpectedBuilder<OP, T>::buildExpected(Op, Inputs, WaveSize);
+    auto Expected = ExpectedBuilder<OP, T>::buildExpected(Op, Inputs, WaveSize);
 
     using OutT = typename decltype(Expected)::value_type;
 
@@ -3020,7 +3021,6 @@ public:
   HLK_MIN_PRECISION_TEST(Or, HLSLMin16Int_t);
   HLK_MIN_PRECISION_TEST(Xor, HLSLMin16Int_t);
 
-
   // UnaryMath
   HLK_MIN_PRECISION_TEST(Abs, HLSLMin16Int_t);
   HLK_MIN_PRECISION_TEST(Sign, HLSLMin16Int_t);
@@ -3116,7 +3116,6 @@ public:
   HLK_MIN_PRECISION_TEST(Or, HLSLMin16Uint_t);
   HLK_MIN_PRECISION_TEST(Xor, HLSLMin16Uint_t);
 
-
   // UnaryMath
   HLK_MIN_PRECISION_TEST(Abs, HLSLMin16Uint_t);
   HLK_MIN_PRECISION_TEST(Sign, HLSLMin16Uint_t);

• 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?