aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
diff options
context:
space:
mode:
authorSteven Perron <stevenperron@google.com>2025-07-02 12:09:47 -0400
committerGitHub <noreply@github.com>2025-07-02 12:09:47 -0400
commit68173c80915955bae8cfc697a98d5d7888f09c67 (patch)
treef5df995faacc69a211daff2ac0c0413933a6d9a5 /llvm/lib/Transforms/Utils/SimplifyCFG.cpp
parent1c305f711f860246b9dd60211166afbf3b3d48cd (diff)
downloadllvm-68173c80915955bae8cfc697a98d5d7888f09c67.zip
llvm-68173c80915955bae8cfc697a98d5d7888f09c67.tar.gz
llvm-68173c80915955bae8cfc697a98d5d7888f09c67.tar.bz2
[HLSL][SPRIV] Handle signed RWBuffer correctly (#144774)
In Vulkan, the signedness of the accesses to images has to match the signedness of the backing image. See https://docs.vulkan.org/spec/latest/chapters/textures.html#textures-input, where it says the behaviour is undefined if > the signedness of any read or sample operation does not match the signedness of the image’s format. Users who define say an `RWBuffer<int>` will create a Vulkan image with a signed integer format. So the HLSL that is generated must match that expecation. The solution we use is to generate a `spirv.SignedImage` target type for signed integer instead of `spirv.Image`. The two types are otherwise the same. The backend will add the `signExtend` image operand to access to the image to ensure the image is access as a signed image. Fixes #144580
Diffstat (limited to 'llvm/lib/Transforms/Utils/SimplifyCFG.cpp')
0 files changed, 0 insertions, 0 deletions