[llvm] [GVN] MemorySSA for GVN: eliminate redundant loads via MemorySSA (PR #152859)

[Antonio Frighetto via llvm-commits]

antoniofrighetto wrote:

> Did you run clang-format on the patch? I think there are a couple of places where I see coding violation.

clang-format run correctly, CI complains due to the introduction of new test checks containing undef. In this case is fine, as those checks were already there before (we simply updated them, showing that MemDep and MSSA converge on the same result).

Compile-time impact of the change: https://llvm-compile-time-tracker.com/compare.php?from=7e1f79c9935fe86b072119fdbb01ee25a80060e6&to=bb3e1cc8b54af17bb360432359eb2ecca3bd7bd2&stat=instructions:u. Some little regressions in stage1-ReleaseLTO-g. Picking CMakeFiles/consumer-typeset.dir/z06.c.o (which has one of the largest regression, +0.35%), putting it under callgrind, and it looks like the new extra time is mostly spent in `SmallVectorImpl<GVNPass::ReachingMemVal>::emplace_back()`, when copying the MemDepAnalysis-populated deps vector (`NonLocalDepResult`) to the new one (`ReachingMemVal`), before processing the non-local load. Reserving the capacity upfront and preventing possible reallocations seems to have some little benefit: https://llvm-compile-time-tracker.com/compare.php?from=7e1f79c9935fe86b072119fdbb01ee25a80060e6&to=bbe0dd87bcc45a0a73a0fd04a06143ea7682222b&stat=instructions:u.

Considering that the regression doesn't look that excessive, and this whole happens on code that is meant to live temporarily (till we turn on MemorySSA), I believe this may be moved forward if on track.

https://github.com/llvm/llvm-project/pull/152859