[PATCH] D121167: [NewPM] Actually recompute GlobalsAA before module optimization pipeline

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 10 07:28:26 PST 2022


fhahn accepted this revision.
fhahn added a comment.
This revision is now accepted and ready to land.

LGTM, thanks.

> Yes that's right, just recomputing GlobalsAA won't cause AAManager to pick it up. Here we're still using the same GlobalsAA instance that the AAManager already has a reference to.

I'll look into adding GlobalsAA into AAManager without invalidating anything.

Should this be handled separately?



================
Comment at: llvm/lib/Passes/PassBuilderPipelines.cpp:1169
   // memory operations.
-  MPM.addPass(RequireAnalysisPass<GlobalsAA, Module>());
+  MPM.addPass(RecomputeGlobalsAAPass());
 
----------------
aeubanks wrote:
> fhahn wrote:
> > 
> > Is there a drawback to just doing `MPM.addPass(InvalidateAnalysisPass<GlobalsAA>());` before re-requiring `GlobalsAA`? At least for the test case, it looks like this is sufficient.
> Yeah I briefly mentioned it in the summary, we end up having to invalidate any analysis that depends on any alias analysis. This way we don't have to do that.
> (I got annoyed updating new-pm-defaults.ll and co with all the newly invalidated analyses, which might not even be deterministic in the order they're invalidated, which is why I went down this route)
Oh right, I guess that makes sense, even though it seems a bit unfortunate we have to add a dedicated 'invalidation' pass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121167



More information about the llvm-commits mailing list