Subject: Why should we have the LoopPass and LoopPassManager? Can we get rid of this complexity?
Date: Wednesday 22nd January 2014 08:05:42 UTC (over 3 years ago)
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?