Implement the first half of PR3290: if there is a store of an
authorChris Lattner <sabre@nondot.org>
Wed, 7 Jan 2009 08:11:13 +0000 (08:11 +0000)
committerChris Lattner <sabre@nondot.org>
Wed, 7 Jan 2009 08:11:13 +0000 (08:11 +0000)
commitd2fa781169175b827e50953a1d0b7edc6b0c4801
treec2421b82d9706cbc476aa1e887390ecbae0edfae
parentd93afec1dbbb1abb3df55e2e007b5f256d09f84a
Implement the first half of PR3290: if there is a store of an
integer to a (transitive) bitcast the alloca and if that integer
has the full size of the alloca, then it clobbers the whole thing.
Handle this by extracting pieces out of the stored integer and
filing them away in the SROA'd elements.

This triggers fairly frequently because the CFE uses integers to
pass small structs by value and the inliner exposes these.  For
example, in kimwitu++, I see a bunch of these with i64 stores to
"%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>"

In 176.gcc I see a few i32 stores to "%struct..0anon".

In the testcase, this is a difference between compiling test1 to:

_test1:
subl $12, %esp
movl 20(%esp), %eax
movl %eax, 4(%esp)
movl 16(%esp), %eax
movl %eax, (%esp)
movl (%esp), %eax
addl 4(%esp), %eax
addl $12, %esp
ret

vs:

_test1:
movl 8(%esp), %eax
addl 4(%esp), %eax
ret

The second half of this will be to handle loads of the same form.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61853 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Scalar/ScalarReplAggregates.cpp
test/Transforms/ScalarRepl/copy-aggregate.ll [new file with mode: 0644]