[llvm-commits] PATCH: Cleanup allocas aggressively in instcombine

[Chandler Carruth]

Hello,

One of the last places where LLVM doesn't generate good code for the
hashing seems to be a pretty fundamental issue with cleanup during
iterative SROA / inlining / instcombine progressions:

We start out with an alloca, store values into it, and then call functions
which operate on the alloca'ed memory. As we inline these functions
(because they're trivial in this case), we iteratively propagate the values
directly into the computation rather than using the alloca. However, we
still need to store the values inte the alloca because of (often dead) code
that is still using it. Eventually, we prove all the code using the alloca
dead or we manage to push all the values directly into the computations.

Unfortunately, by this time, the inliner and SROA passes have finished, and
they finished while there were still uses of the alloca'ed pointer and so
the stores weren't completely dead.

This patch teaches instcombine to walk alloca instructions and if they are
only used by GEPs, bitcasts, and stores, remove them. I added this to
instcombine because I would like this to run iteratively with other passes
so that dead allocas don't block further inlining, etc.

Seem reasonable? I'm working on reduced test cases, I've been testing it
against the hashing code, and this nicely removes the dead alloca
instructions which is the only remaining cruft in the following code:

hash_code foo(int *x, int *y) { return hash_combine(x, y); }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120408/6886973b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup_allocas.diff
Type: application/octet-stream
Size: 3064 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120408/6886973b/attachment.obj>