-
Notifications
You must be signed in to change notification settings - Fork 709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect SPIR-V generated when firstbithigh
is used on a uint64_t
#4702
Comments
|
Becuase the underlying GLSL.std.450 instructions FindSMsb, FindUMsb and FindILsB are currently limited to 32-bit width components, we should emit an explicit error messages when these instructions would be generated incorrectly in the SPIR-V backend. Closes microsoft#4702
The SPIR-V backend was incorrectly choosing to emit either FindSMsb or FindUMsb based on whether the result type of the call expression was signed or unsigned. Since the AST result type was always unsigned (and wrapped in a cast if necessary), this meant FindSMsb was never generated. FindSMsB should however be generated when the argument type is signed. This is indicated by the HLSL intrinsic op code (firstbithigh for signed and ufirstbithigh for unsigned). The SPIR-V generated now matches the DXIL generated. This bug was discovered while investigating microsoft#4702, so at the same time some error checking is added to make unimplemented cases explicit. Because the underlying GLSL.std.450 instructions FindSMsb, FindUMsb and FindILsB are currently limited to 32-bit width components, we now emit an error messages when this would otherwise result in invalid SPIR-V.
The SPIR-V backend was incorrectly choosing to emit either FindSMsb or FindUMsb based on whether the result type of the call expression was signed or unsigned. Since the AST result type was always unsigned (and wrapped in a cast if necessary), this meant FindSMsb was never generated. FindSMsB should however be generated when the argument type is signed. This is indicated by the HLSL intrinsic op code (firstbithigh for signed and ufirstbithigh for unsigned). The SPIR-V generated now matches the DXIL generated. This bug was discovered while investigating #4702, so at the same time some error checking is added to make unimplemented cases explicit. Because the underlying GLSL.std.450 instructions FindSMsb, FindUMsb and FindILsB are currently limited to 32-bit width components, we now emit an error messages when this would otherwise result in invalid SPIR-V.
The SPIR-V backend was incorrectly choosing to emit either FindSMsb or FindUMsb based on whether the result type of the call expression was signed or unsigned. Since the AST result type was always unsigned (and wrapped in a cast if necessary), this meant FindSMsb was never generated. FindSMsB should however be generated when the argument type is signed. This is indicated by the HLSL intrinsic op code (firstbithigh for signed and ufirstbithigh for unsigned). The SPIR-V generated now matches the DXIL generated. This bug was discovered while investigating microsoft#4702, so at the same time some error checking is added to make unimplemented cases explicit. Because the underlying GLSL.std.450 instructions FindSMsb, FindUMsb and FindILsB are currently limited to 32-bit width components, we now emit an error messages when this would otherwise result in invalid SPIR-V.
DXC now emits an appropriate error message when
|
The fix b7a50ba introduced a new issue at astContext.getTypeSize(argType) == 64 when used on // -T vs_6_0 -E VSMain -spirv
int2 Foo;
void VSMain() {
firstbithigh(Foo);
} |
Thanks for catching that @LukasBanana! Submitting a fix now. |
The code gen for firstbithigh and -low was incorrectly checking the size of the full (possibly composite) type rather than the element size. This is now fixed, and I've also switch the check from checking whether the element type is == 64-bit to != 32-bit, so that it matches the current limitations of the GLSL extended instructions. https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html#:~:text=%3Cid%3E%0AValue-,FindSMsb,-Signed%2Dinteger%20most Related to microsoft#4702
The code gen for firstbithigh and -low was incorrectly checking the size of the full (possibly composite) type rather than the element size. This is now fixed, and I've also switch the check from checking whether the element type is == 64-bit to != 32-bit, so that it matches the current limitations of the GLSL extended instructions. https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html#:~:text=%3Cid%3E%0AValue-,FindSMsb,-Signed%2Dinteger%20most Related to microsoft#4702
The code gen for firstbithigh and -low was incorrectly checking the size of the full (possibly composite) type rather than the element size. This is now fixed, and I've also switch the error check from whether the element type is == 64-bit to != 32-bit, so that it matches the current limitations of the GLSL extended instructions. https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html#:~:text=%3Cid%3E%0AValue-,FindSMsb,-Signed%2Dinteger%20most Related to #4702
@s-perron - comments here seem to suggest this is already fixed? |
Just to clarify, the original issue in the bug is not yet fixed. I added some error messaging to make the failure more explicit, and in the process was accidentally overzealous and errored on some valid cases, so I fixed that, but the SPIR-V backend still doesn't support |
We will not be implementing the workaround in the compiler. We will reconsider in the clang implementation. #6864 is open to make sure the error messages are reasonable. |
Calling this function causes the error when targeting SPIR-V. It works fine when targeting DXIL.
It does work with the following workaround:
The text was updated successfully, but these errors were encountered: