This is an archive of the discontinued LLVM Phabricator instance.

[NewPM] Actually recompute GlobalsAA before module optimization pipeline
ClosedPublic

Authored by aeubanks on Mar 7 2022, 3:26 PM.

Details

Summary

RequireAnalysis<GlobalsAA> doesn't actually recompute GlobalsAA.
GlobalsAA isn't invalidated (unless specifically invalidated) because
it's self-updating via ValueHandles, but can be imprecise during the
self-updates.

Rather than invalidating GlobalsAA, which would invalidate AAManager and
any analyses that use AAManager, create a new pass that recomputes
GlobalsAA.

Fixes #53131.

Diff Detail

Event Timeline

aeubanks created this revision.Mar 7 2022, 3:26 PM
Herald added a project: Restricted Project. · View Herald Transcript
aeubanks requested review of this revision.Mar 7 2022, 3:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 3:26 PM
aeubanks edited reviewers, added: fhahn, asbirlea; removed: ctetreau.Mar 7 2022, 3:27 PM
nikic added a subscriber: nikic.Mar 8 2022, 12:28 AM

We have some places doing a Require<GlobalsAA>, Invalidate<AAManager> dance, can that be replaced with this as well? Or is the situation there that we do need to invalidate the AAManager because otherwise the new GlobalsAA just isn't going to be used?

fhahn added inline comments.Mar 8 2022, 9:51 AM
llvm/lib/Passes/PassBuilderPipelines.cpp
1169

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.

We have some places doing a Require<GlobalsAA>, Invalidate<AAManager> dance, can that be replaced with this as well? Or is the situation there that we do need to invalidate the AAManager because otherwise the new GlobalsAA just isn't going to be used?

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.

llvm/lib/Passes/PassBuilderPipelines.cpp
1169

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)

fhahn accepted this revision.Mar 10 2022, 7:28 AM

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?

llvm/lib/Passes/PassBuilderPipelines.cpp
1169

Oh right, I guess that makes sense, even though it seems a bit unfortunate we have to add a dedicated 'invalidation' pass.

This revision is now accepted and ready to land.Mar 10 2022, 7:28 AM
asbirlea accepted this revision.Mar 10 2022, 2:01 PM

Given the situation, I agree this is a reasonable way to handle it.

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?

Yes, it requires different mechanisms than this patch

This revision was landed with ongoing or failed builds.Mar 14 2022, 9:42 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 9:42 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript