https://bugs.llvm.org/show_bug.cgi?id=50721
Bug ID: 50721
Summary: [Arm32] Atomic operations on 64-bit operations have
invalid bit-cast
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected]
As demonstrated by https://reviews.llvm.org/D104264, the ARM back-end generates
a pointer bit-cast from i64 value to an i8* (to a {i32, i32} struct) to call
the double-word atomic operations on, but if the pointer is in a different
address space, the bit-cast fails.
The back-end barfs with the code (generated by a third-party front-end):
define i64 @atomic_load_i64_other_address_space(i64 addrspace(1)* align 8 %ptr)
{
load_entry:
%val = load atomic i64, i64 addrspace(1)* %ptr acquire, align 8
ret i64 %val
}
define void @atomic_store_i64_other_address_space(i64 addrspace(1)* align 8
%ptr, i64 %value) {
store_entry:
store atomic i64 %value, i64 addrspace(1)* %ptr release, align 8
ret void
}
and command line:
$ llc < %s -mtriple=thumbv7-linux-gnueabihf
with error: "invalid bit-cast".
The problem is in ARMISelLowering.cpp::emitLoadLinked:
Addr = Builder.CreateBitCast(Addr, Type::getInt8PtrTy(M->getContext()));
where Addr is not in the default address space.
The questions are:
1. What is the semantics in this case?
2. Do we create the i8* on the same address space?
3. Do we even want to know about address spaces at that level?
If the answer to (3) is "yes", then (2) seems like a valid solution. But I may
be missing something obvious.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
