[PATCH] D58359: [Analysis] fold load of untouched alloca to undef

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 19 12:00:57 PST 2019


spatel added a comment.

In D58359#1402730 <https://reviews.llvm.org/D58359#1402730>, @efriedma wrote:

> Yes, we fold loads from alloca to undef. (In GVN like you mention, but also in mem2reg.)  LangRef should state memory allocated with alloca is uninitialized, and that loading from uninitialized memory produces undef; if either of those is missing, patch welcome to fix it.
>
> That said, this seems like the wrong direction, in terms of where we want to perform this sort of optimization.  Most functions have more than one basic block, and you won't catch any of those cases.  EarlyCSE/GVN/NewGVN should be able to handle this case, and similar cases where there's more than one basic block.  Also, FindAvailablePtrLoadStore is basically only used from two places: JumpThreading, and InstCombine.   InstCombine really shouldn't be doing this sort of scan, and JumpThreading obviously only triggers in functions with more than one BB.


Thanks. I agree that the load optimizations from instcombine are iffy. I assumed that was there as a cheap first cut of optimization to save time for other passes, but it might be doing the opposite for overall compile-time at this point. I only noticed this because an unrelated instcombine change showed up as a possible regression on 1 of the fuzzer-reduced tests, but it sounds like I should ignore that.

I'll add some text to the LangRef.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58359/new/

https://reviews.llvm.org/D58359





More information about the llvm-commits mailing list