This is an archive of the discontinued LLVM Phabricator instance.

PM: Implement a basic loop pass manager
AbandonedPublic

Authored by bogner on Jan 15 2016, 8:09 PM.

Details

Reviewers
chandlerc
Summary

This creates the new-style LoopPassManager and wires it up with dummy
and print passes.

TODO:

  • Is a BasicBlock name sufficient for Loop::getName(), or should we include the containing function's name as well?
  • LoopAnalysisManagerFunctionProxy::run could use an assert to ensure that we don't run Loop Analyses before the proxy is created, but this can't work without a good model for invalidating the cache between functions. Note: this is an existing issue with FunctionAMModuleProxy as well.
  • There is no LoopVerifierPass. This can be added later.

Diff Detail

Repository
rL LLVM

Event Timeline

bogner updated this revision to Diff 45070.Jan 15 2016, 8:09 PM
bogner retitled this revision from to PM: Implement a basic loop pass manager.
bogner updated this object.
bogner added a reviewer: chandlerc.
bogner set the repository for this revision to rL LLVM.
bogner added a subscriber: llvm-commits.
anemet added a subscriber: anemet.Jan 18 2016, 1:02 PM
chandlerc edited edge metadata.Feb 24 2016, 1:36 AM

OMG, the delaays reviewing. So sorry.

Most of this is excellent. I think the tricky question is around handling the mutation of the loop nest correctly. I wonder if it'd be worthwhile to just rip handling of that out entirely in order to land the rest and then support mutation as a follow-up patch so we can look at the alternatives there without having so much boiler plate hanging in a patch?

include/llvm/Analysis/LoopInfo.h
473–478

I think this is fine, the caller can dig out more info as needed.

include/llvm/Analysis/LoopPassManager.h
41–44

This trait isn't really commented, but I see what you're using it for (at least I think so -- to stop the LoopPassManager when the current loop gets deleted?).

That technique feels a bit clumsy to me. What do you think about instead expanding the LoopPassManager to just be its own beast and have loop-specific logic where it halts the passes if the loop itself goes away, and logs helpfully? Maybe we could sink some of the boilerplate into a base class so it is reasonably easy to define a custom pass manager here?

214–218

Why not a worklist rather than explicit recursion? Either way, either inline the code or if still recursive use a lambda rather than a helper function?

232

Why a deque? It looks like we just push_back, so a vector (or smallvector) would seem more appropriate?

233

Some comment about the reverse?

236–237

It's a bit odd that you don't directly handle updates to the loop structure here. I feel like you could by potentially avoiding the queue above entirely and directly sinking this into the recursive walk over the LoopInfo so that as passes update LoopInfo, in turn your traversal is kept up-to-date.

As part of that, maybe check that passes preserve LoopInfo here?

bogner abandoned this revision.Feb 7 2023, 3:46 PM

This was superceded years ago...

Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2023, 3:46 PM
Herald added a subscriber: mcrosier. · View Herald Transcript