<div dir="ltr">As came up recently in other threads, loop passes really get in the way. Here are some of the ways:<div><br></div><div>- There is only one Loop analysis pass - IVUsers. It seems unlikely that the loop nest walk is critical to computing this or preserving it.</div>
<div><br></div><div>- 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.</div><div><br></div><div>- 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.</div>
<div><br></div><div>- 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.</div><div><br></div><div><br></div><div>There appear to be two chunks of "functionality" provided by loop passes:</div>
<div><br></div><div>1) A worklist of loops to process. This is very rarely used:</div><div>1.1) LoopSimplify and LoopUnswitch add loops to the queue.</div><div>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).</div>
<div><br></div><div>2) LoopUnswitch and the pass itself use some hooks to update analyses. This is only actually leveraged by LICM though to update the AliasSetTracker</div><div><br></div><div><br></div><div>These don't seem like very serious use cases, and the cost is insanely high. Can we get rid of it?</div>
</div>