On Wed, Jul 11, 2012 at 11:49 PM, Florian Brandner <span dir="ltr"><<a href="mailto:flbr@imm.dtu.dk" target="_blank">flbr@imm.dtu.dk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed July 11 2012 11:50:01 Chandler Carruth wrote:<br>
> - What else did I miss?<br>
><br>
><br>
> Things that are totally out of scope: pass registration, the current pass order and structure, the fundamental interface of mapping from a pass to an analysis, etc. This is really about pass management and scheduling.<br>

><br>
<br>
</div>Hi Chandler,<br>
<br>
I understand why the pass registration and the pass order/structure is out of<br>
scope for your work. However, as others have already noted, there are problems<br>
that are somewhat related to how pass scheduling works. From my perspective,<br>
the current way we specify the pass order/structure is too much spread all over<br>
different places.</blockquote><div><br></div><div>Really? It seems fairly reasonable to me: the PassManagerBuilder has the canonical bits for a reasonable optimization pipeline combined with extension hooks that clients can use to inject custom passes into reasonable places in the pipeline.</div>
<div><br></div><div>I don't see a huge problem here, and so I'd like to keep the scope narrow. If you do see problems, i would build on top of the hopefully cleaner version. =]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One idea, for instance, could be to extend tablegen to specify pass<br>
pipelines,</blockquote><div><br></div><div>I don't think this is useful. We can define reasonable and clear natural C++ interfaces for this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another important point are passes in the backend. Currently we have some<br>
severe limitations there (for instance, all codegen passes have to be function<br>
passes). It would be great if the full flexibility of the pass scheduling<br>
framework could be preserved even in the backend.<br></blockquote><div><br></div><div>I agree that backend passes are important, but don't want to go there for this effort. It's just not in scope at all.</div></div>