This is an archive of the discontinued LLVM Phabricator instance.

[SimpleLoopUnswitch] Inform pass manager when child loops are deleted
ClosedPublic

Authored by bjope on Sep 3 2021, 1:20 PM.

Details

Summary

As part of the nontrivial unswitching we could end up removing child
loops. This patch add a notification to the pass manager when
that happens (using the markLoopAsDeleted callback).

Without this there could be stale LoopAccessAnalysis results cached
in the analysis manager. Those analysis results are cached based on
a Loop* as key. Since the BumpPtrAllocator used to allocate
Loop objects could be resetted between different runs of for
example the loop-distribute pass (running on different functions),
a new Loop object could be created using the same Loop pointer.
And then when requiring the LoopAccessAnalysis for the loop we
got the stale (corrupt) result from the destroyed loop.

Change-Id: Id976debe231ee6595752f501b36e719200834997

Diff Detail

Event Timeline

bjope created this revision.Sep 3 2021, 1:20 PM
bjope requested review of this revision.Sep 3 2021, 1:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 3 2021, 1:20 PM

Do we need to do the same at the end of rebuildLoopAfterUnswitch()? Looks like another loop is getting destroyed there.

bjope added a comment.EditedSep 3 2021, 2:17 PM

Do we need to do the same at the end of rebuildLoopAfterUnswitch()? Looks like another loop is getting destroyed there.

I actually added a similar DestroyedLoopCB callback in rebuildLoopAfterUnswitch() in an earlier draft of the patch. But then I realized that the destroy call in that place is for the base loop that is being unswitched. And as far as I could tell that boils down to rebuildLoopAfterUnswitch() returning false, and then unswitchNontrivialInvariants() will pass on information in the UnswitchCB call that the loops has been destroyed, and the markLoopAsDeleted call is made from that call back.
I was thinking that it would be nice to have a code comment explaining that next to the LI.destroy(&L) call. Seems like I forgot about adding such a comment.

aeubanks accepted this revision.Sep 3 2021, 2:29 PM
aeubanks added inline comments.
llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
2

maybe to simplify this a bit you could just do require<access-info> instead of running a full optimization pass that uses it. it'd make this test a bit more robust

This revision is now accepted and ready to land.Sep 3 2021, 2:29 PM

and thanks for debugging/fixing this! these sorts of issues are rough

bjope added inline comments.Sep 3 2021, 2:50 PM
llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
2

Well, I had the same idea. But decided not to do like that in the end.

My original problem was related to loop-distribute, which is a function pass. So in that situation there is a LoopAnalysisManagerFunctionProxy involved. If using require<access-info>, then I got the impression that things might be a bit different. But given that we basically only want to see that there is a "Clearing all analysis results" for the destroyed loop, then maybe it is ugly to use loop-distribute here.

aeubanks added inline comments.Sep 3 2021, 3:37 PM
llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
2

Ah makes sense. Yeah I think checking for the "Clearing all analysis results" is sufficient

This revision was landed with ongoing or failed builds.Sep 4 2021, 8:55 AM
This revision was automatically updated to reflect the committed changes.

This certainly should go into 13.x, please file a bug if there isn't one already.

bjope added a comment.Sep 5 2021, 1:18 AM

This certainly should go into 13.x, please file a bug if there isn't one already.

Ok, noted. I filed a PR (and added release-13.0.0 as blocks): https://bugs.llvm.org/show_bug.cgi?id=51754

I believe the 13.0.0-rc3 release is today, we should probably get this in soon

I believe the 13.0.0-rc3 release is today, we should probably get this in soon

Sorry, not sure how I missed that this was already submitted.