Expand definition of floating literals #175
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llvm-beanz
force-pushed
the
cbieneman/hlsl-floating-literal
branch
from
3ddac95
to
a1caec7
Compare
This adds a definition of floating literals that is consistent with existing HLSL documentation and other shader compilers. It is notably different from the implementations in DXC and FXC.
llvm-beanz
force-pushed
the
cbieneman/hlsl-floating-literal
branch
from
a1caec7
to
752b029
Compare
|
A few additional notes for this PR. This adds a definition for floating literals that is:
It is not consistent with DXC's behavior. DXC's implementation of literal types has been a significant source of bugs in the compiler(microsoft/DirectXShaderCompiler#6147, microsoft/DirectXShaderCompiler#3973, microsoft/DirectXShaderCompiler#4683, microsoft/DirectXShaderCompiler#5493, microsoft/DirectXShaderCompiler#6410, and probably more). It has also caused confusion for even highly technical users, and is probably inconsistent across DXIL and SPIR-V. |
This was referenced Mar 20, 2024
llvm-beanz
added a commit
to llvm-beanz/hlsl-specs
that referenced
this pull request
Mar 22, 2024
This proposal seeks to codfiy the behavior documented in the HLSL documentation https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-appendix-grammar#floating-point-numbers, and captured in microsoft#175 as the behavior for HLSL 202x.
llvm-beanz
added a commit
that referenced
this pull request
Mar 22, 2024
* [0017] Add proposal for conforming literals This proposal seeks to codfiy the behavior documented in the HLSL documentation https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-appendix-grammar#floating-point-numbers, and captured in #175 as the behavior for HLSL 202x.
|
As an experiment to attempt to gauge the disruption this change would cause. DXC has 40 tests which are fragile to this change (see: llvm-beanz/DirectXShaderCompiler@4c854da). Of those, several of them are fragile because they look for the I'm trying to run some additional testing against other shaders that I have available to further gauge the potential impact on existing code. |
llvm-beanz
added a commit
to llvm-beanz/llvm-project
that referenced
this pull request
Apr 1, 2024
This change implements the HLSL floating literal suffixes for half and double literals. The PR for the HLSL language specification for this behavior is microsoft/hlsl-specs#175. The TL;DR is that the `h` suffix on floating literals means `half`, and the `l` suffix means `double`. The expected behavior and diagnostics are different if native half is supported. When native half is not enabled half is 32-bit so implicit conversions to float do not lose precision and do not warn. In all cases `half` and `float` are distinct types. Resolves llvm#85712 ../clang/test/SemaHLSL/literal_suffixes_no_16bit.hlsl
damyanp
approved these changes
Apr 1, 2024
llvm-beanz
added a commit
to llvm-beanz/llvm-project
that referenced
this pull request
Apr 5, 2024
This change implements the HLSL floating literal suffixes for half and double literals. The PR for the HLSL language specification for this behavior is microsoft/hlsl-specs#175. The TL;DR is that the `h` suffix on floating literals means `half`, and the `l` suffix means `double`. The expected behavior and diagnostics are different if native half is supported. When native half is not enabled half is 32-bit so implicit conversions to float do not lose precision and do not warn. In all cases `half` and `float` are distinct types. Resolves llvm#85712 ../clang/test/SemaHLSL/literal_suffixes_no_16bit.hlsl
llvm-beanz
added a commit
to llvm/llvm-project
that referenced
this pull request
Apr 5, 2024
This change implements the HLSL floating literal suffixes for half and double literals. The PR for the HLSL language specification for this behavior is microsoft/hlsl-specs#175. The TL;DR is that the `h` suffix on floating literals means `half`, and the `l` suffix means `double`. The expected behavior and diagnostics are different if native half is supported. When native half is not enabled half is 32-bit so implicit conversions to float do not lose precision and do not warn. In all cases `half` and `float` are distinct types. Resolves #85712
bogner
approved these changes
Apr 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a definition of floating literals that is consistent with existing HLSL documentation and other shader compilers. It is notably different from the implementations in DXC and FXC.