[HLSL] When loading a boolean from memory perform a comparison to zero instead of a truncation

[spall]

HLSL booleans are 32 bits when stored in memory to enable things like booleanv vector swizzles. Work was done to support this in clang and a truncation was used when going from i32 to i1.

See: #123977, #140627

the bug: https://godbolt.org/z/h9bdqPnxv

In one case the following valid optimization occurred during InstCombine, which led to a bug manifesting in the DirectX backend.

%0 = load <4 x i32>, ptr %call, align 16, !dbg !119
%1 = extractelement <4 x i32> %0, i32 3, !dbg !119
  %2 = trunc i32 %1 to i1, !dbg !119

to

%0 = load <128 x i1>, ptr %call, align 16, !dbg !119
 %1 = extractelement <128 x i1> %0, i64 96, !dbg !119

After a discussion it was decided that for correctness with DXC, where any non zero value should be considered true when converting to bool, and to avoid this optimization bug, instead of a truncation a comparison to zero should be done.

The work of this issue is to update all of the code which truncates from i32 to i1 to support HLSL booleans and boolean vectors. The checks which are performed on the bit size of the scalar element will need to be changed to just checks of 'isextvectorbool'.

[efriedma-quic]

See also #116732

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Sarah Spall (spall)

HLSL booleans are 32 bits when stored in memory to enable things like booleanv vector swizzles. Work was done to support this in clang and a truncation was used when going from i32 to i1.

See: #123977, #140627

the bug: https://godbolt.org/z/h9bdqPnxv

In one case the following valid optimization occurred during InstCombine, which led to a bug manifesting in the DirectX backend.

%0 = load <4 x i32>, ptr %call, align 16, !dbg !119
%1 = extractelement <4 x i32> %0, i32 3, !dbg !119
  %2 = trunc i32 %1 to i1, !dbg !119

to

%0 = load <128 x i1>, ptr %call, align 16, !dbg !119
 %1 = extractelement <128 x i1> %0, i64 96, !dbg !119

After a discussion it was decided that for correctness with DXC, where any non zero value should be considered true when converting to bool, and to avoid this optimization bug, instead of a truncation a comparison to zero should be done.

The work of this issue is to update all of the code which truncates from i32 to i1 to support HLSL booleans and boolean vectors. The checks which are performed on the bit size of the scalar element will need to be changed to just checks of 'isextvectorbool'.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Sarah Spall (spall)

HLSL booleans are 32 bits when stored in memory to enable things like booleanv vector swizzles. Work was done to support this in clang and a truncation was used when going from i32 to i1.

See: #123977, #140627

the bug: https://godbolt.org/z/h9bdqPnxv

In one case the following valid optimization occurred during InstCombine, which led to a bug manifesting in the DirectX backend.

%0 = load <4 x i32>, ptr %call, align 16, !dbg !119
%1 = extractelement <4 x i32> %0, i32 3, !dbg !119
  %2 = trunc i32 %1 to i1, !dbg !119

to

%0 = load <128 x i1>, ptr %call, align 16, !dbg !119
 %1 = extractelement <128 x i1> %0, i64 96, !dbg !119

After a discussion it was decided that for correctness with DXC, where any non zero value should be considered true when converting to bool, and to avoid this optimization bug, instead of a truncation a comparison to zero should be done.

The work of this issue is to update all of the code which truncates from i32 to i1 to support HLSL booleans and boolean vectors. The checks which are performed on the bit size of the scalar element will need to be changed to just checks of 'isextvectorbool'.

[damyanp]

We may also need to consider range metadata.