Scalar replacement introduces store with incorrect alignment

[llvmbot]

Bugzilla Link	3720
Resolution	FIXED
Resolved on	Mar 04, 2009 13:21
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

When the scalar replacement pass replaces a structure which is the source of a llvm.memcpy then it replaces the memcpy with stores. It does not seem to be taking into account the alignment of the memcpy when setting the alignment of these stores.

running opt -scalar-repl on the following:

    %struct.st = type <{ i16 }>

define void @​f(i8* %p) nounwind {
entry:
%s = alloca %struct.st, align 4 ; <%struct.st*> [#uses=2]
%0 = getelementptr %struct.st* %s, i32 0, i32 0 ; <i16*> [#uses=1]
store i16 1, i16* %0, align 4
%s1 = bitcast %struct.st* %s to i8* ; <i8*> [#uses=1]
call void @​llvm.memcpy.i32(i8* %p, i8* %s1, i32 2, i32 1)
ret void
}

declare void @​llvm.memcpy.i32(i8* nocapture, i8* nocapture, i32, i32) nounwind

Results in the following output:

    %struct.st = type <{ i16 }>

define void @​f(i8* %p) nounwind {
entry:
%p1 = bitcast i8* %p to %struct.st* ; <%struct.st*> [#uses=1]
%p1.0 = getelementptr %struct.st* %p1, i32 0, i32 0 ; <i16*> [#uses=1]
store i16 1, i16* %p1.0
ret void
}

declare void @​llvm.memcpy.i32(i8* nocapture, i8* nocapture, i32, i32) nounwind

This is invalid - if %p isn't 16bit aligned then the store will be misaligned and this may trap depending on the target.

[lattner]

taking a look

[lattner]

Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074633.html