OSDN Git Service

Teach SROA how to split whole-alloca integer loads and stores into
authorChandler Carruth <chandlerc@gmail.com>
Thu, 25 Oct 2012 04:37:07 +0000 (04:37 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Thu, 25 Oct 2012 04:37:07 +0000 (04:37 +0000)
commita2b88163af30f59d12ae0172565f3406bdbf6c45
tree2bca1e0574a0720c4ceba0c74b31231ddf27efd6
parent8dbac7b529cfb73bcd0ceef514e5c1d247cf3baa
Teach SROA how to split whole-alloca integer loads and stores into
smaller integer loads and stores.

The high-level motivation is that the frontend sometimes generates
a single whole-alloca integer load or store during ABI lowering of
splittable allocas. We need to be able to break this apart in order to
see the underlying elements and properly promote them to SSA values. The
hope is that this fixes some performance regressions on x86-32 with the
new SROA pass.

Unfortunately, this causes quite a bit of churn in the test cases, and
bloats some IR that comes out. When we see an alloca that consists soley
of bits and bytes being extracted and re-inserted, we now do some
splitting first, before building widened integer "bucket of bits"
representations. These are always well folded by instcombine however, so
this shouldn't actually result in missed opportunities.

If this splitting of all-integer allocas does cause problems (perhaps
due to smaller SSA values going into the RA), we could potentially go to
some extreme measures to only do this integer splitting trick when there
are non-integer component accesses of an alloca, but discovering this is
quite expensive: it adds yet another complete walk of the recursive use
tree of the alloca.

Either way, I will be watching build bots and LNT bots to see what
fallout there is here. If anyone gets x86-32 numbers before & after this
change, I would be very interested.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166662 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Scalar/SROA.cpp
test/Transforms/SROA/basictest.ll
test/Transforms/SROA/big-endian.ll