Hello,<div><br></div><div>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:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>hash_code foo(int *x, int *y) { return hash_combine(x, y); }</div>