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

[Chandler Carruth]

As came up recently in other threads, loop passes really get in the way.
Here are some of the ways:

- There is only one Loop analysis pass - IVUsers. It seems unlikely that
the loop nest walk is critical to computing this or preserving it.

- Almost all of the things we think of as "required" and dependencies are
actually *transforms* that canonicalize the form of a loop into particular
shapes.

- Because LoopPasses are nested inside of some other pass manager, we can't
compute function analyses after transforming loops with LoopSimplify and/or
LCSSA, and have these analyses available to other LoopPasses such as the
vectorizer and unroller.

- LoopPasses don't obey the typical "rules" of a pass over a narrow chunk
of IR: they routinely access and modify IR outside of the loop.


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.
1.2) LoopExtractor, LoopDeletion, and LoopUnroll delete loops from the
queue (but "no-op" would likely be correct if we didn't have the loop pass
manager).

2) LoopUnswitch and the pass itself use some hooks to update analyses. This
is only actually leveraged by LICM though to update the AliasSetTracker


These don't seem like very serious use cases, and the cost is insanely
high. Can we get rid of it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140122/ef52e5e9/attachment.html>