Expand double vector dot products to FMul/FMad instead of emitting invalid Dot2/3/4 intrinsics

[Copilot]

mul(double_vector, double_vector) and dot(double_vector, double_vector) emit dx.op.dot{2,3,4}.f64 which fails DXIL validation — Dot2/3/4 only support half and float (overload mask 0x3), not double.

Changes

• lib/HLSL/HLOperationLower.cpp: Early-out in TranslateFDot for double types, routing to ExpandDot with FMad (which supports f64) instead of the unsupported Dot intrinsics. This mirrors the existing integer path which already uses ExpandDot for the same reason.

• tools/clang/test/HLSLFileCheck/hlsl/intrinsics/mul/mul_double.hlsl: Test coverage for both mul and dot with double2, double3, and double4 (6 RUN configurations), asserting no dot*.f64 calls and verifying fmul + tertiary.f64 (FMad) expansion. Since %dxc runs the validator by default, the test implicitly verifies DXIL validity.

// Previously produced: call double @dx.op.dot4.f64 → validation error
// Now produces: fmul fast double + call double @dx.op.tertiary.f64(i32 46, ...) ; FMad
Out[0] = mul(In[0], In[1]); // where In is RWStructuredBuffer<double4>

Also fixes dot() with double vectors, since it shares the same TranslateFDot codepath.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[DirectX] Performing a mul between two double vectors produces invalid DXIL</issue_title>
<issue_description>Description
Performing a mul between two double vectors results in a DXIL validation error about the intrinsic call call double @dx.op.dot4.f64 being invalid.
Unlike the dot function which is expected to map directly to the dot DXIL op, the mul function should not be restricted to such a limitation.

Steps to Reproduce
https://hlsl.godbolt.org/z/asnerhMsd

Compile the following HLSL with -T cs_6_8

RWStructuredBuffer<double4> In;
RWStructuredBuffer<double> Out;

[numthreads(1, 1, 1)]
void main() {
    Out[0] = mul(In[0], In[1]);
}

Actual Behavior
Compiler output:

error: validation errors
<source>:6:14: error: DXIL intrinsic overload must be valid.
note: at '%14 = call double @dx.op.dot4.f64(i32 56, double %10, double %11, double %12, double %13, double %5, double %6, double %7, double %8)' in block '#0' of function 'main'.
Validation failed.


Compiler returned: 5

Environment

• DXC version 1.8.2505

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [DirectX] Performing a mul between two double vectors produces invalid DXIL microsoft/DirectXShaderCompiler#8208

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[damyanp]

Also fixes dot() and normalize() with double vectors, since they share the same TranslateFDot codepath.

Make sure that the tests you add actually cover all the things you think you've changed.

Please confirm for me that these tests fail without your changes, and that you have a test that exercises the actual reported problem. Reported issue was that validation failed, so we need a test that validation succeeds.

[Copilot]

Also fixes dot() and normalize() with double vectors, since they share the same TranslateFDot codepath.

Make sure that the tests you add actually cover all the things you think you've changed....

Updated the test in 45f72a9 to cover both mul and dot with double2/3/4 vectors (6 RUN configurations total), since both go through TranslateFDot.

I confirmed both functions fail validation without the fix:

error: validation errors
error: DXIL intrinsic overload must be valid.
Validation failed.

And all 6 configurations pass with the fix. The %dxc RUN lines implicitly verify DXIL validity since dxc runs the validator by default.

Regarding normalize: it doesn't actually hit the double dot path — the compiler truncates to float before the dot/rsqrt, so it's unaffected. I've removed that claim from the PR description.