[PATCH] D84609: [MemDepAnalysis] Cut-off threshold reshuffling

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D84609#2179323 <https://reviews.llvm.org/D84609#2179323>, @asbirlea wrote:

> Some general comments:
>
> - The MemDepAnalysis has been known to be problematic for compile-time, so reducing the 100k implicit threshold seems reasonable.
> - It's natural the compiler tracker will be happy, but can we consider runtime implications due to potential missed optimizations?
> - Could we evaluate which optimizations are missed, in which passes using MemDepAnalysis along with their run-time impact? (in particular for the benchmarks where we see the large compile-time benefits)
>
> AFAIK, the main passes using MemDepAnalysis are DSE, MemCpyOpt and GVN and there is active work in porting these to MemorySSA. The same analysis of compile-time vs run-time benefits is needed for that switch, so having data from reducing thresholds here will be very valuable for the short term (current patch) on deciding how much to reduce it to, and for the long-term switch to MemorySSA.

Background: the motivation for this patch is the fact that D84108 <https://reviews.llvm.org/D84108> significantly
regresses compile-time of lencod, especially `context_ini.c` (+79.97%).
It has been traced to GVN spending most of the time in `GVN::processNonLocalLoad()`,
in `MemoryDependenceResults::getNonLocalPointerDependency()`.

Since a compile-, and run- time performance assessment will be needed both here,
and in MemorySSA switch, would it be more productive to directly proceed to the latter?
Without having much(any) prior expirience with MemSSA, should it be too complicated ?
How long-term is the switch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84609