| Issue |
144580
|
| Summary |
[HLSL][SPIRV] Generate sign extended image instructions
|
| Labels |
HLSL,
backend:SPIR-V
|
| Assignees |
s-perron
|
| Reporter |
s-perron
|
In HLSL, a RWBuffer<int> is suppose to be loading value as if they are signed integers. This is important because if the format of the image is 8-bit, then the value on a load is implicitly sign extended. The problem in the current Clang implementation is that the signedness of the sampled type is lost because llvm-ir interpreted whether or not an integer is sign or not based on the instruction that is using it.
Without knowing the signedness of the sample type, SPIR-V generates all code assuming the integers are unsigned. This causes problems.
There are two possible solutions in the SPIR-V:
1. Pass information along so that the sampled type can be modified to be a signed integer.
2. Pass information along so that the `OpImage*` instructions can get the `signExtend` image operand when necessary.
The difficulty with 1 is that the sampled type of the image must match the Texel components of the `OpImage*` instructions. This means that the type information will have to propagate further.
Seems like 2 is the best solution. It is a more local change, making the code generation easier.
Now we still need to figure out how to pass the information from the FE to the BE. There are again a few options
1. Use a new target type that has a bit for `isSigned` as is done for DXIL.
2. Incorporate the sign into the type for the `spirv.Image` type.
3. Add a target attribute to the "gethandlefrombinding" call.
4. Add an annotation to the loads and stores.
Option 4 does not work. The annotation would have to be metadata, which the optimizer is allowed to drop.
Option 2 does not work well either. It would require special handling to make sure the sampled type matches other integers. Not a reasonable option.
To know if 1 will work, I'll have to see if the SPIR-V backend has easy access to the lllvm type when generating the load and stores. The SPIR-V type will have lost the signedness informations.
If that does not work, we will have to go with option 3. However, that has it own uglyness.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
