[LLVMbugs] [Bug 15907] New: SROA pass introduces bitcast between different address spaces
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri May 3 11:48:15 PDT 2013
http://llvm.org/bugs/show_bug.cgi?id=15907
Bug ID: 15907
Summary: SROA pass introduces bitcast between different address
spaces
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: mpfergu at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Hi -
I'm having a problem with SROA removing important (to me) address space
information with a bitcast. Help is appreciated, thanks!
To reproduce, run the below small test case through opt -sroa -S ... you will
see in the output the bitcast is added; with 3.2 we get lines like:
%a.0.storeme.cast.cast = bitcast i8 addrspace(100)* %storeme.cast to i64*
or
%a.0.loadme.cast.cast = bitcast i8 addrspace(100)* %loadme.cast to i64*
These should be:
%a.0.storeme.cast.cast = bitcast i8 addrspace(100)* %storeme.cast to i64
addrspace(100)*
%a.0.loadme.cast.cast = bitcast i8 addrspace(100)* %loadme.cast to i64
addrspace(100)*
-----------------------------------------
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128-p100:64:64:64"
declare void @llvm.memcpy.p0i8.p100i8.i64(i8* nocapture, i8 addrspace(100)*
nocapture, i64, i32, i1)
declare void @llvm.memcpy.p100i8.p0i8.i64(i8 addrspace(100)* nocapture, i8*
nocapture, i64, i32, i1)
define void @teststore(i64 addrspace(100)* %storeme) {
entry:
%a = alloca i64
store i64 7, i64 * %a
%storeme.cast = bitcast i64 addrspace(100)* %storeme to i8 addrspace(100)*
%a.cast = bitcast i64 * %a to i8 *
call void @llvm.memcpy.p100i8.p0i8.i64(i8 addrspace(100)* %storeme.cast, i8*
%a.cast, i64 8, i32 1, i1 true)
ret void
}
define i64 @testload(i64 addrspace(100)* %loadme) {
entry:
%a = alloca i64
%loadme.cast = bitcast i64 addrspace(100)* %loadme to i8 addrspace(100)*
%a.cast = bitcast i64 * %a to i8 *
call void @llvm.memcpy.p0i8.p100i8.i64(i8* %a.cast, i8 addrspace(100)*
%loadme.cast, i64 8, i32 1, i1 true)
%ret = load i64 * %a
ret i64 %ret
}
-----------------------------------------
I have also created a patch to SROA.cpp which causes assertion failures when
adding such bitcasts. I have not been able to find a fix but
the added assert gets triggered in line 2976 (getAdjustedPtr in
visitMemTransferInst).
Index: SROA.cpp
===================================================================
--- SROA.cpp (revision 181030)
+++ SROA.cpp (working copy)
@@ -1869,6 +1869,18 @@
Indices);
}
+// Check that we're not adding a bit-cast between address spaces.
+static Value *makeBitCast(IRBuilderTy &IRB, Value *V, Type *Ty, const Twine
&Name = "")
+{
+ if( V->getType()->isPointerTy() && Ty->isPointerTy() ) {
+ unsigned VAS = V->getType()->getPointerAddressSpace();
+ unsigned TyAS = Ty->getPointerAddressSpace();
+ assert( VAS == TyAS && "Pointer address spaces do not match!");
+ }
+ return IRB.CreateBitCast(V, Ty, Name);
+}
+
+
/// \brief Compute an adjusted pointer from Ptr by Offset bytes where the
/// resulting pointer has PointerTy.
///
@@ -1953,7 +1965,7 @@
if (!OffsetPtr) {
if (!Int8Ptr) {
- Int8Ptr = IRB.CreateBitCast(Ptr, IRB.getInt8PtrTy(),
+ Int8Ptr = makeBitCast(IRB, Ptr, IRB.getInt8PtrTy(),
"raw_cast");
Int8PtrOffset = Offset;
}
@@ -1966,7 +1978,7 @@
// On the off chance we were targeting i8*, guard the bitcast here.
if (Ptr->getType() != PointerTy)
- Ptr = IRB.CreateBitCast(Ptr, PointerTy, "cast");
+ Ptr = makeBitCast(IRB, Ptr, PointerTy, "cast");
return Ptr;
}
@@ -2021,7 +2033,7 @@
if (V->getType()->isPointerTy() && Ty->isIntegerTy())
return IRB.CreatePtrToInt(V, Ty);
- return IRB.CreateBitCast(V, Ty);
+ return makeBitCast(IRB, V, Ty);
}
/// \brief Test whether the given alloca partition can be promoted to a
vector.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130503/cd50d17f/attachment.html>
More information about the llvm-bugs
mailing list