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

[Bill Wendling]

On 10/25/07, Chris Lattner <clattner at apple.com> wrote:
> 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*. :)
>
The FE is generating the 8-byte align thing. However, it's doing it by
checking only one of the pointer's alignment types instead of both.
The trick is getting it to check both and take the minimal alignment.

And then the other two bugs. :-/

-bw