On 6/12/14, 11:03 AM, Chandler Carruth wrote:> > On Thu, Jun 12, 2014 at 4:45 PM, Hanbing Li <hanbing.li at inria.fr > <mailto:hanbing.li at inria.fr>> wrote: > > Hi, > > I know when a pass needs other passes, it will use something like > this: "AU.addRequired<LoopInfo>();". But this is usually used for > the analysis passes. > When a pass needs another transform pass, can it call it > automatically? > For example: > Some loop optimizations may need loop-simplify, I need add > -loop-simplify before calling these passes manually, or they can > call the pass -loop-simplify automatically? > > > Currently, the pass manager allows you (somewhat) to use the > addRequired mechanism even with analyses. However, I strongly > encourage you to not leverage it as it will eventually go away.Just out of curiosity, why is this feature going away? Regards, John Criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140612/3c0914cb/attachment.html>
On Thu, Jun 12, 2014 at 5:23 PM, John Criswell <criswell at illinois.edu> wrote:> On 6/12/14, 11:03 AM, Chandler Carruth wrote: > > > On Thu, Jun 12, 2014 at 4:45 PM, Hanbing Li <hanbing.li at inria.fr> wrote: > >> Hi, >> >> I know when a pass needs other passes, it will use something like this: >> "AU.addRequired<LoopInfo>();". But this is usually used for the analysis >> passes. >> When a pass needs another transform pass, can it call it automatically? >> For example: >> Some loop optimizations may need loop-simplify, I need add -loop-simplify >> before calling these passes manually, or they can call the pass >> -loop-simplify automatically? >> > > Currently, the pass manager allows you (somewhat) to use the addRequired > mechanism even with analyses. However, I strongly encourage you to not > leverage it as it will eventually go away. > > > Just out of curiosity, why is this feature going away?Because it makes understanding the actual pass sequence horribly complex. With analyses, things are simple. Whatever order you run the analyses in doesn't matter because they don't mutate anything. Each analysis can depend on other analyses and you either have a cycle (fast to detect and error on) or you have a DAG and there is a natural walk that produces the set of desired analyses. Now consider when these passes are *transformations*. Now, the relative order in which you run them can dramatically change the results in unpredictable ways. There is no way for multiple "required" transformation passes to be ordered cleanly without a tremendous amount of machinery. All this is what led to LoopSimplify being run 4x as many times as was necessary for a long time. =/ Instead, everyone I've discussed this with (there have bene several email threads about this) prefers that there is a single place (the builder) which spells out the exact sequence of transforms applied. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140612/202a4785/attachment.html>
On 6/12/14, 11:41 AM, Chandler Carruth wrote:> > On Thu, Jun 12, 2014 at 5:23 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > On 6/12/14, 11:03 AM, Chandler Carruth wrote: >> >> On Thu, Jun 12, 2014 at 4:45 PM, Hanbing Li <hanbing.li at inria.fr >> <mailto:hanbing.li at inria.fr>> wrote: >> >> Hi, >> >> I know when a pass needs other passes, it will use something >> like this: "AU.addRequired<LoopInfo>();". But this is usually >> used for the analysis passes. >> When a pass needs another transform pass, can it call it >> automatically? >> For example: >> Some loop optimizations may need loop-simplify, I need add >> -loop-simplify before calling these passes manually, or they >> can call the pass -loop-simplify automatically? >> >> >> Currently, the pass manager allows you (somewhat) to use the >> addRequired mechanism even with analyses. However, I strongly >> encourage you to not leverage it as it will eventually go away. > > Just out of curiosity, why is this feature going away? > > > Because it makes understanding the actual pass sequence horribly complex. > > With analyses, things are simple. Whatever order you run the analyses > in doesn't matter because they don't mutate anything. Each analysis > can depend on other analyses and you either have a cycle (fast to > detect and error on) or you have a DAG and there is a natural walk > that produces the set of desired analyses. > > Now consider when these passes are *transformations*. Now, the > relative order in which you run them can dramatically change the > results in unpredictable ways. There is no way for multiple "required" > transformation passes to be ordered cleanly without a tremendous > amount of machinery. All this is what led to LoopSimplify being run 4x > as many times as was necessary for a long time. =/If I understand what you're saying, you're keeping the current functionality of being able to schedule *analysis* passes using AU.addRequired<>() but removing the ability to schedule *transform* passes via AU.addRequired<>(), correct? Your original email implied that analysis passes would, in the future, not be scheduled via AU.addRequired<>(). I completely understand not scheduling transform passes that way. Regards, John Criswell> > Instead, everyone I've discussed this with (there have bene several > email threads about this) prefers that there is a single place (the > builder) which spells out the exact sequence of transforms applied.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140612/54e44ee9/attachment.html>
On Jun 12, 2014, at 9:41 AM, Chandler Carruth <chandlerc at google.com> wrote:> > On Thu, Jun 12, 2014 at 5:23 PM, John Criswell <criswell at illinois.edu> wrote: > On 6/12/14, 11:03 AM, Chandler Carruth wrote: >> >> On Thu, Jun 12, 2014 at 4:45 PM, Hanbing Li <hanbing.li at inria.fr> wrote: >> Hi, >> >> I know when a pass needs other passes, it will use something like this: "AU.addRequired<LoopInfo>();". But this is usually used for the analysis passes. >> When a pass needs another transform pass, can it call it automatically? >> For example: >> Some loop optimizations may need loop-simplify, I need add -loop-simplify before calling these passes manually, or they can call the pass -loop-simplify automatically? >> >> Currently, the pass manager allows you (somewhat) to use the addRequired mechanism even with analyses. However, I strongly encourage you to not leverage it as it will eventually go away. > > Just out of curiosity, why is this feature going away? > > Because it makes understanding the actual pass sequence horribly complex. > > With analyses, things are simple. Whatever order you run the analyses in doesn't matter because they don't mutate anything. Each analysis can depend on other analyses and you either have a cycle (fast to detect and error on) or you have a DAG and there is a natural walk that produces the set of desired analyses. > > Now consider when these passes are *transformations*. Now, the relative order in which you run them can dramatically change the results in unpredictable ways. There is no way for multiple "required" transformation passes to be ordered cleanly without a tremendous amount of machinery. All this is what led to LoopSimplify being run 4x as many times as was necessary for a long time. =/ > > Instead, everyone I've discussed this with (there have bene several email threads about this) prefers that there is a single place (the builder) which spells out the exact sequence of transforms applied.Yes. Thank you! As for the Analysis passes, why do they need to be “passes”? I don’t think it should be required for a PassManager to schedule them. The static dependence between Analysis->Pass is often not what you want. A pass should be able to conditionally ask for an Analysis only if and when it’s needed. As a compiler matures, these conceptually stand-alone Analysis end up becoming utilities that can be invoked on-the-fly anyway. Furthermore, Analysis results can be built up incrementally as needed, and only valid within some scope. An Analysis “result” just needs to be registered with the PassManager for reuse. The hard part of the problem is managing invalidation of the Analysis. I think it’s a bit crazy for example that when a pass currently invalidates an Analysis, the analysis remains valid until the pass completes and control returns to the PassManager. It would be nice to have a better framework for Analysis invalidation some day. To be clear, there’s nothing wrong with having an AnalysisPass that can be explicitly scheduled. That’s useful for testing passes that only use an analysis “if available”. However, an Analysis should not need to be a pass in order to register its result with the PassManager. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140612/fd7083f7/attachment.html>