>>>
>>> I discussed this with Bill today. The problem is that we have:
>>>
>>> llvm.memcpy(p, q, 8, 1/*alignment)
>>>
>>> this gets turned into an 8-byte load and an 8-byte store, but the
>>> alignment (of 1) from the memcpy isn't put onto the load or
>>> store, so
>>> the legalizer thinks they are properly aligned.
>>
>> Ok, this makes sense. I'd thought the memcpy alignment was 4.
>>
> Um...so...since the Align that I get is 8 from the memcpy, how do I
> get the alignment of the src/dst pointers?
Okay, well then. Bill and I discussed this again. It sounds like
there are multibugs here. One issue is that the alignment from the
memcpy isn't pushed onto the generated load/stores when lowering the
memcpy.
However, there is another bug with this specific testcase:
@C.0.1173 = external constant [33 x i8]
define void @Bork() {
entry:
%Qux = alloca [33 x i8]
%Qux1 = bitcast [33 x i8]* %Qux to i8*
call void @llvm.memcpy.i64( i8* %Qux1, i8* getelementptr ([33 x i8]*
@C.0.1173, i32 0, i32 0), i64 33, i32 8 )
ret void
}
declare void @llvm.memcpy.i64(i8*, i8*, i64, i32)
Note that the memcpy has an alignment of 8 specified here, but it is
copying out of a global and out of a local alloca that need not be so
aligned. This is a bug in the testcase: whatever generated the
memcpy is broken, as the alignment is not valid. However, invalid
code shouldn't cause llc to abort, so we have to fix *that too*. :)
-Chris
_______________________________________________
llvm-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
