-
Notifications
You must be signed in to change notification settings - Fork 91
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
Bitcast lost due to llvm's opaque pointer #1352
Comments
There is obviously something wrong in the compiler here as it should emit valid SPIR-V. But it also feels to me that this source is not correct. The compiler has no way to know that A workaround for this bug would be to either:
|
In fact
Which seems to be well compiled by It leads to this kind of pattern in the SPIR-V:
And then it's up to the Vulkan SPIR-V compiler to know whether or not the hardware supports unaligned loads and can coalesce those loads into one I guess. |
The point that the casting may cause run-time alignment issue is well taken. But not sure if similar invalid spirv (phi with inconsistent types) will show up with a different kind of cast. We'll do the workaround in the source code. Thanks. |
I agree, there is a bug to fix here.
|
This is the cut-down test case:
The cast at this line:
global uint4* histAddr4 = (global uint4*)(hist+grid);
was dropped in the llvm ir due to opaque pointers. and the resulting llvm instruction is:
%add.ptr = getelementptr inbounds i32, ptr addrspace(1) %7, i32 %8
If the cast was not dropped, it should have been:
%add.ptr = getelementptr inbounds <4 x i32>, ptr addrspace(1) %7, i32 %8
The generated spv fails spirv validation because the OpPhi for histAddr4, whose first operand is defined by this getelementptr, has inconsistent types:
We need to recover the dropped cast type for the getelementptr instruction. I see there are type inferencing code in Types.cpp to recover lost type information. In this example, the type in the OpPhi was actually returned by InferUsersType(). If we apply type inferencing to the getelementptr, there would be a circular dependency.
Any suggestion on how to recover the lost typecast for the above getelementptr?
The text was updated successfully, but these errors were encountered: