[llvm] [GVN] MemorySSA for GVN: embed the memory state in symbolic expressions (PR #123218)

[Antonio Frighetto via llvm-commits]

antoniofrighetto wrote:

Some bottlenecks during linking: https://llvm-compile-time-tracker.com/compare.php?from=d7afafdbc464e65c56a0a1d77bad426aa7538306&to=b4e2bbc42d1582b36b0d89ebdd10bd8113af8d6a&stat=instructions:u.

I have been profiling this, and it seems like the new increase stems from higher `lookupOrAdd` hit (increased by ~7% in stage1-O3 when taking `7zip/UI/Common/SetProperties.cpp.o`, invoked from newly-added `lookupOrAddLoadStore`).
1) Even though lookupAdd is recursively called when including the memory state, arguably, this should just a lookup as the value for the memory access should already be visited (if it's a call/load/store, whereas should be added to the map if it's a basic block)? Not sure if this can be done better rather than having a hashmap.
2) Attempts to favour capacity over size while resizing the vector in assignExpNewValueNum seem to give little improvements in stage-1 but regressions in stage-2: https://llvm-compile-time-tracker.com/compare.php?from=6cb2f6de9b3cf0e72b7d45c9fc149457b3462ca3&to=767cd78b3a9c54c17dd20e7e99a7158174af5924&stat=instructions:u (regressions if we employ a DenseMap instead of resizing the vector).

To move this forward, I'd suggest temporarily having load / store handling subject to `IsMSSAEnabled` (https://llvm-compile-time-tracker.com/compare.php?from=d7afafdbc464e65c56a0a1d77bad426aa7538306&to=f924a3b5278b047488f1cd228342821171cc477a&stat=instructions:u), and revisiting this afterwards while turning off MemDep. Although now visiting load/stores incur some overhead, I'd expect this to level off as we switch to a computationally cheaper analysis. Any thoughts? @alinas, @nikic

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