[LLVMdev] RFC: Pass Manager Redux
Chandler Carruth
chandlerc at gmail.com
Fri Jul 13 02:44:14 PDT 2012
On Wed, Jul 11, 2012 at 11:49 PM, Florian Brandner <flbr at imm.dtu.dk> wrote:
> On Wed July 11 2012 11:50:01 Chandler Carruth wrote:
> > - What else did I miss?
> >
> >
> > 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.
> >
>
> Hi Chandler,
>
> I understand why the pass registration and the pass order/structure is out
> of
> scope for your work. However, as others have already noted, there are
> problems
> that are somewhat related to how pass scheduling works. From my
> perspective,
> the current way we specify the pass order/structure is too much spread all
> over
> different places.
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.
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. =]
> One idea, for instance, could be to extend tablegen to specify pass
> pipelines,
I don't think this is useful. We can define reasonable and clear natural
C++ interfaces for this.
Another important point are passes in the backend. Currently we have some
> severe limitations there (for instance, all codegen passes have to be
> function
> passes). It would be great if the full flexibility of the pass scheduling
> framework could be preserved even in the backend.
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120713/f49f9d3a/attachment.html>
More information about the llvm-dev
mailing list