[llvm-commits] [llvm] r43270 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp test/CodeGen/PowerPC/2007-10-23-UnalignedMemcpy.ll

[Chris Lattner]

>>>
>>> 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