| Issue |
127491
|
| Summary |
[SPIR-V] Incorrect pointer type is deduced for OpAtomic* instructions when a pointer argument is created by an `inttoptr .. to` instruction
|
| Labels |
new issue
|
| Assignees |
VyacheslavLevytskyy
|
| Reporter |
VyacheslavLevytskyy
|
A GPUToLLVMSPV user of the SPIR-V backend reports about a case when incorrect pointer type is deduced for OpAtomic* instructions. The reproducer is
```
define dso_local spir_func void @test4(i64 noundef %arg, float %val) local_unnamed_addr {
entry:
%ptr1 = inttoptr i64 %arg to ptr addrspace(1)
%v1 = atomicrmw fadd ptr addrspace(1) %ptr1, float %val seq_cst, align 4
ret void
}
```
while triaging shows that the problem may be also reproduced for a wider set of instructions and SPIR-V op-codes, for example:
```
define dso_local spir_func void @test4(i64 noundef %arg, float %val) local_unnamed_addr {
entry:
%ptr1 = inttoptr i64 %arg to ptr addrspace(1)
%v1 = atomicrmw fadd ptr addrspace(1) %ptr1, float %val seq_cst, align 4
%ptr2 = inttoptr i64 %arg to float addrspace(1)*
%v2 = atomicrmw fsub ptr addrspace(1) %ptr2, float %val seq_cst, align 4
%ptr3 = inttoptr i64 %arg to float addrspace(1)*
%v3 = tail call spir_func float @_Z21__spirv_AtomicFAddEXT(ptr addrspace(1) %ptr3, i32 1, i32 16, float %val)
%ptr4 = inttoptr i64 %arg to float addrspace(1)*
%v4 = tail call spir_func float @_Z25atomic_fetch_add_explicitPU3AS1VU7_Atomicff12memory_order(ptr addrspace(1) %ptr4, float %val, i32 0)
%ptr5 = inttoptr i64 %arg to float addrspace(1)*
%v5 = tail call spir_func float @_Z25atomic_fetch_sub_explicitPU3AS1VU7_Atomicff12memory_order(ptr addrspace(1) %ptr5, float %val, i32 0)
ret void
}
declare dso_local spir_func float @_Z21__spirv_AtomicFAddEXT(ptr addrspace(1), i32, i32, float)
declare spir_func float @_Z25atomic_fetch_add_explicitPU3AS1VU7_Atomicff12memory_order(ptr addrspace(1), float, i32)
declare spir_func float @_Z25atomic_fetch_sub_explicitPU3AS1VU7_Atomicff12memory_order(ptr addrspace(1), float, i32)
```
and also for OpAtomicLoad/OpAtomicStore:
```
define spir_func void @test_types1(ptr addrspace(1) %ptr, float %val) {
entry:
%r = call spir_func float @atomic_load(ptr addrspace(1) %ptr)
ret void
}
define spir_func void @test_types2(ptr addrspace(1) %ptr, float %val) {
entry:
call spir_func void @atomic_store(ptr addrspace(1) %ptr, float %val)
ret void
}
define spir_func void @test_types3(i64 noundef %arg, float %val) {
entry:
%ptr1 = inttoptr i64 %arg to float addrspace(1)*
%r = call spir_func float @atomic_load(ptr addrspace(1) %ptr1)
ret void
}
define spir_func void @test_types4(i64 noundef %arg, float %val) {
entry:
%ptr2 = inttoptr i64 %arg to float addrspace(1)*
call spir_func void @atomic_store(ptr addrspace(1) %ptr2, float %val)
ret void
}
declare spir_func float @atomic_load(ptr addrspace(1))
declare spir_func void @atomic_store(ptr addrspace(1), float)
```
Incorrect pointer type is deduced for OpAtomic* instructions when a pointer argument is created by an `inttoptr .. to` instruction, with a root cause is that information about pointee type is ignored unless this argument is a pointer as well. A solution could be to account for a pointee type using the Value argument type of the corresponding LLVM IR instruction/SPIR-V op-code, depending on the context of the case.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
