<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 3:11 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div></div></blockquote></div><br>So, the design actually makes precisely the distinction you're looking for. Analyses are different beasts from transformations at a reasonably firm level.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">That said, they still are "passes" in some very vague sense -- they still benefit (sometimes) from having a phase where the run over the given unit of IR to build up the datastructure / information that they intend to vend.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The current design has two different but similar concepts: transformation passes and analysis passes. You can see the difference in the interface: a transformation pass returns the set of invalidated analyses, an analysis pass returns the results of that analysis which should be cached, queried, and (eventually) invalidated by the pass manager infrastructure.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">And yes, the invalidation is already *much* more precise and I think we can make it even better. I still need to document some of this, but want to hold off on doing tons of documentation of guarantees and invariants until I have more things converted over (but not enabled of course) so that I'm more confident that the invariants promised can be upheld. =]</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>