Skip to content
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

Closed
manon-traverse opened this issue Oct 3, 2022 · 7 comments
Closed
Labels
spirv Work related to SPIR-V

Comments

@manon-traverse
Copy link

generated SPIR-V is invalid: GLSL.std.450 FindUMsb: expected all operands to have the same bit width as Result Type
  %137 = OpExtInst %uint %1 FindUMsb %136

note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible

Calling this function causes the error when targeting SPIR-V. It works fine when targeting DXIL.

uint clz64(uint64_t v) { return 63 - firstbithigh(v); }

It does work with the following workaround:

uint clz64(uint64_t v) {
    uint2 workaround = uint2(v, v >> 32);

    uint high = firstbithigh(workaround.y);
    if (high != -1) {
        return 31 - high;
    } else {
        return 63 - firstbithigh(workaround.x);
    }
}
@godlikepanos
Copy link
Contributor

FindUMsb and a few similar GLSL derived instructions do not support 64bit (see https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html). glslang has (or had) similar issues. I think Khronos should extend the instructions to support 64bit and in the meantime DXC should apply your workaround.

@pow2clk pow2clk added the spirv Work related to SPIR-V label Oct 3, 2022
sudonatalie added a commit to sudonatalie/DirectXShaderCompiler that referenced this issue Aug 10, 2023
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
sudonatalie added a commit to sudonatalie/DirectXShaderCompiler that referenced this issue Sep 6, 2023
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.
sudonatalie added a commit that referenced this issue Sep 8, 2023
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.
ShchchowAMD pushed a commit to ShchchowAMD/DirectXShaderCompiler that referenced this issue Sep 11, 2023
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.
@sudonatalie
Copy link
Collaborator

DXC now emits an appropriate error message when firstbithigh is used on a uint64_t. Eventually we should support this, but it's not currently a priority to implement so the workaround in HLSL should be used until then.

int firstbithigh64(uint64_t v) {
    int high = firstbithigh(uint(v >> 32));
    if (high != -1) {
      return high + 32;
    }

    return firstbithigh(uint(v));
}

@sudonatalie sudonatalie removed their assignment Sep 20, 2023
@LukasBanana
Copy link
Contributor

The fix b7a50ba introduced a new issue at astContext.getTypeSize(argType) == 64 when used on int2 types. This reproduces the issue (see godbolt.org):

// -T vs_6_0 -E VSMain -spirv
int2 Foo;
void VSMain() {
    firstbithigh(Foo);
}

@sudonatalie
Copy link
Collaborator

Thanks for catching that @LukasBanana! Submitting a fix now.

sudonatalie added a commit to sudonatalie/DirectXShaderCompiler that referenced this issue May 10, 2024
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
sudonatalie added a commit to sudonatalie/DirectXShaderCompiler that referenced this issue May 10, 2024
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
sudonatalie added a commit that referenced this issue May 14, 2024
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
@damyanp damyanp moved this to For Google in HLSL Triage Aug 14, 2024
@damyanp
Copy link
Member

damyanp commented Aug 14, 2024

@s-perron - comments here seem to suggest this is already fixed?

@sudonatalie
Copy link
Collaborator

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 firstbithigh on 64 bit ints.

@s-perron
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spirv Work related to SPIR-V
Projects
Archived in project
Development

No branches or pull requests

7 participants