[PATCH] D35741: Add MemorySSA alternative to AliasSetTracker in LICM.

Davide Italiano via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 21 17:32:32 PDT 2017


davide added a comment.

In https://reviews.llvm.org/D35741#817873, @dberlin wrote:

> In https://reviews.llvm.org/D35741#817737, @davide wrote:
>
> > Thanks, I'll review this soon.
> >  A quick question. a concern people have about MemorySSA is that you pay upfront for O(1) queries, which may have some impact on compile time.
>
>
> FWIW: This is and always has been false accounting in most passes as you know.  
>  Most passes that could use MemorySSA already ask about every load and store in the function.  
>  The only reason people think it's faster to not use MemorySSA, or to avoid the upfront cost,  is because our time-passes doesn't account function time to lazy utilities/analysis properly.
>  If it did, AA/etc time would look *much* larger than it does now, because in reality, it *is* much larger than it seems.
>
> IE if you avoid optimize uses, and call getClobberingAccess on every load/store, "MemorySSA" time goes down, overall time goes up.


Yes :) Sorry if it wasn't clear, I'm fairly sure this is the correct way forward.
You know this already, but for the records. 
What I was referring to is that when EarlyCSE was switched to MemorySSA that resulted in a "regression", which was basically "compute MemorySSA" (this doesn't necessarily apply here as the old earlyCSE was using a fairly simple scheme while LICM uses AST which is already costly).
This could've been avoided if GVNHoist was still the default and both updated MemSSA so you didn't pay the cost of recomputing.
I guess the more stuff we move in the compiler to use MemSSA (and teach to preserve, the more we amortize the cost), but I was curious about what was the situation today with this change :)

>> (e.g. in EarlyCSE). AST is already O(N^2), and in some cases badly so, but I wonder if you have compile time measurements of the impact of your change?
> 
> MemorySSA as alias sets (IE as done promotion) in this manner is not going to be faster in a lot of cases.
> 
> But you are going to have to rewrite how promotion in LICM functions (IE not use alias sets) to get the advantages of really using MemorySSA.
>  RIght now it's kinda wonky




https://reviews.llvm.org/D35741





More information about the llvm-commits mailing list