HLSL: Add 'f' suffix to float literals in code generation

[mkeshavaNV]

Fixes #6078

Previously, Slang would emit HLSL float literals without a suffix (e.g.,"1.5"), which caused DXC to interpret them as 64-bit doubles by default unless the -HV 202x flag was used. This could cause validation errors when these literals were used with intrinsics that only accept 32-bit floats (like ddx, ddy).

This change modifies the HLSL emitter to explicitly add 'f' suffix to 32-bit float literals, ensuring they are correctly typed regardless of DXC's version or flags. For example:

• "1.5" becomes "1.5f"
• "(0.0 / 0.0)" becomes "(0.0f / 0.0f)" for NaN
• "float4(1.0, 2.0, 3.0, 4.0)" becomes "float4(1.0f, 2.0f, 3.0f, 4.0f)"

Added a test case to verify the behavior with various float literal scenarios including basic literals, intrinsic calls, and vector construction.

[mkeshavaNV]

Here is the output of the hlsl shader:

#pragma pack_matrix(column_major)
#ifdef SLANG_HLSL_ENABLE_NVAPI
#include "nvHLSLExtns.h"
#endif

#ifndef __DXC_VERSION_MAJOR
// warning X3557: loop doesn't seem to do anything, forcing loop to unroll
#pragma warning(disable : 3557)
#endif


#line 1 "slang-repro.slang"
float4 fragmentMain(float2 uv_0 : TEXCOORD) : SV_TARGET
{
    return float4(1.0f, ddx(1.5f), 0.0f, 1.0f);
}

1. Notice that this has the "f" suffix
2. Verified that this works OK with dxc.
3. @csyonghe - In issue Issues with HLSL floating point literals #6078 you mention: " I am not sure if that will break the fxc compiler.". How can I test this? Are there tests part of CIs?

[jkwak-work]

Were you able to reproduce the error form DXC?
I am about to upgrade DXC from 1.7 to 1.9 and I like to know if the issue is specific to a certain version of DXC or not.

[jkwak-work]

Before your change, it was "break" instead of "return".
Your PR is making a change to the behavior that is not described on the PR description.
Can you explain why this change is needed?

[csyonghe]

You need return here to avoid the fallback call to Super::emitSimpleValueImpl since we are overriding the behavior for ordinary float literals here.

[csyonghe]

as long as all tests are passing, we are fine.

[jkwak-work]

Please use the following test, instead of one in this PR,

//TEST:SIMPLE(filecheck=HLSL):-target hlsl -profile ps_6_6 -entry fragmentMain
//TEST:SIMPLE(filecheck=DXIL):-target dxil -profile ps_6_6 -entry fragmentMain

float4 fragmentMain(float2 uv : TEXCOORD) : SV_Target
{
    //HLSL:, ddx({{.*}}1.5f)
    //DXIL: = call float @dx.op.unary.f32(i32 {{.*}} ; DerivCoarseX(value)
    float val = 1.5;
    return float4(1.0, ddx(val), 0.0, 1.0);
}

[jkwak-work]

To answer my question, I was able to reproduce it with DXC 1.7.

[mkeshavaNV]

To answer my question, I was able to reproduce it with DXC 1.7.

@jkwak-work - Yes I was able to reproduce the issue with dxc. I used this version of dxc:

C:\WINDOWS\system32>dxc --version
dxcompiler.dll: 1.8 - 1.8.0.4775 (d39324e06)

Please use the following test, instead of one in this PR,

Ok, you want to add dxil coverage too, right?