[LLVMdev] Why should we have the LoopPass and LoopPassManager? Can we get rid of this complexity?

Andrew Trick atrick at apple.com
Wed Jan 22 01:01:03 PST 2014


On Jan 22, 2014, at 12:44 AM, Chandler Carruth <chandlerc at gmail.com> wrote:

> 
> On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote:
> > There appear to be two chunks of "functionality" provided by loop passes:
> >
> > 1) A worklist of loops to process. This is very rarely used:
> > 1.1) LoopSimplify and LoopUnswitch add loops to the queue.
> 
> I’m making this up without much thought, but we may benefit from iterative loop transforms like Rotate -> LICM -> Unswitch -> Rotate -> LICM. We might need to come up with a preferred alternative: we can either continue to convert transforms into a utilities, or we can invent new pass manager tricks. e.g. iterate over a set of function passes or selectively run a pass on “dirty” regions.
> 
> This is a really good point. Owen pointed it out to me as well in another guise: when we unroll a loop, we need to re-run a bunch of the passes, but re-running them when we *haven't* successfully unrolled a loop is a total waste.
> 
> I'd like to think more about this, so a simpler option: what if we *just* extract LoopSimplify and LCSSA? If all the LoopPasses preserve these, then them being function passes would be fine. This would allow us to at least *start* writing function passes over loops (like the LoopVectorizer) rather than being forced to phrase them as LoopPasses.
> 
> I think I could implement this simpler option right away, and that would unblock a lot of our efforts around unrolling, vectorizing, and PGO.

Great. LoopSimplify can be used as a utility to cleanup transformed loops if needed.

LCSSA could eventually be eliminated as prerequisites for some loop passes that should just use the SSA updater instead.

SCEV based passes would be next in line to convert to function passes. Reproducing and debugging issues related to SCEV invalidation and loop pass order is terrifying.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140122/e672cec8/attachment.html>


More information about the llvm-dev mailing list