This is an archive of the discontinued LLVM Phabricator instance.

[GVN] When merging blocks update LoopInfo if it's available
ClosedPublic

Authored by anemet on Nov 30 2016, 4:53 PM.

Details

Summary

If LoopInfo is available during GVN, BasicAA will use it. However
MergeBlockIntoPredecessor does not update LI as it merges blocks.

This didn't use to cause problems because LI was freed before
GVN/BasicAA. Now with OptimizationRemarkEmitter, the lifetime of LI is
extended so LI needs to be kept up-to-date during GVN.

Diff Detail

Repository
rL LLVM

Event Timeline

anemet updated this revision to Diff 79841.Nov 30 2016, 4:53 PM
anemet retitled this revision from to [GVN] When merging blocks update LoopInfo if it's available.
anemet updated this object.
anemet added reviewers: hfinkel, dberlin.
anemet added a subscriber: llvm-commits.
reames accepted this revision.Nov 30 2016, 6:15 PM
reames added a reviewer: reames.
reames added a subscriber: reames.

This appears straightforward. LGTM

This revision is now accepted and ready to land.Nov 30 2016, 6:15 PM
This revision was automatically updated to reflect the committed changes.
efriedma added inline comments.
llvm/trunk/lib/Transforms/Scalar/GVN.cpp
2697

This doesn't make sense... getAnalysisUsage says that GVN doesn't preserve LoopInfo, so it shouldn't be required to preserve it. How exactly is this causing a problem?

anemet added inline comments.Dec 1 2016, 11:41 AM
llvm/trunk/lib/Transforms/Scalar/GVN.cpp
2697

This is not about preserving for subsequent passes but preserving while running GVN. The reason is that BasicAA uses LI if it's available and it is using it *lazily*, i.e. holding onto the analysis pass rather than querying its result right away.

What's changed is that LI is kept alive during GVN now because a new analysis pass OptimizationRemarkEmitter indirectly uses LI. As a consequence, BasicAA will now use LI, so we need to keep it up-to-date during GVN so that BasicAA uses consistent state.

I believe that this is a known problem with analysis passes holding on to other analysis passes and using them lazily. The "lazy" dependencies will have to be kept consistent downstream.

efriedma added inline comments.Dec 1 2016, 12:16 PM
llvm/trunk/lib/Transforms/Scalar/GVN.cpp
2697

Oh, I see, GVN requires OptimizationRemarkEmitter, OptimizationRemarkEmitter requires LI, therefore GVN must preserve LI. That's fine, I guess, although it's pretty subtle.

Could you add an explicit call to addPreserved<LoopInfoWrapperPass> for documentation purposes?

anemet added inline comments.Dec 1 2016, 1:25 PM
llvm/trunk/lib/Transforms/Scalar/GVN.cpp
2697

Yes it is subtle, and I should have added a comment about this. Will do in a follow-up (this is already committed).

Could you add an explicit call to addPreserved<LoopInfoWrapperPass> for documentation purposes?

Makes sense, will do that in a follow-up too.

anemet added inline comments.Dec 2 2016, 10:34 AM
llvm/trunk/lib/Transforms/Scalar/GVN.cpp
2697

Looks like this will need a bit more work. Critical-edge-splitting should probably also preserve LI -- currently we only update DT.

My plan is to insert an LI-verification pass after GVN and run through the test suite to feel comfortable marking LI preserved by GVN.