Scripted pass manager

[Richard Guenther]

On Nov 27, 2007 2:39 PM, Richard Guenther <richard.guenther@gmail.com> wrote:
>
> On Nov 26, 2007 11:20 PM, Rob Quill <rob.quill@gmail.com> wrote:
> > Hi all,
> >
> > This patch scripts the pass manager in a way similar to the the
> > options.c and options.h are generated. It shows no regressions against
> > the current mainline on x86_64-linux.
>
> ;)
>
> With a "scripted pass manager" I of course ment a pass manager that
> allows re-configuration of the pass pipeline without re-compiling.  For
> example by embeding LUA (or another tiny scripting language).  With
> control flow you should be able to experiment with looping over
> optimization passes until nothing changes, etc., much like a simple
> "plugin" interface without actually having plugins.

Let me elaborate a bit on what I want from a 'scripted pass manager'.
The statically specified pass pipeline is a limitation for experiments with
pass ordering - so as a first thing I'd like to dynamically initialize the
pass pipeline from - say - a textual description - that is either specified
on the command-line or by looking up a default (which would match
the current pipeline configuration) which is statically built into gcc.

<crazy ideas>
This textual description could look like your passes.def, but it could also
be a procedural elaboration of the pass flow interpreted by the GCC pass
manager.  In whatever language of choice (and with whatever interface
we can come up with).  Like:

do_passes ()
{
  if (optimize > 0)
    do_early_optimizations ()
  ...
}

do_early_optimizations ()
{
  execute_one_pass (early_inline)
  execute_one_pass (cleanup_cfg)
  ...
}

basically you would provide a scripting interface to the pass manager
backend and process the pass flow using an interpreter.
</crazy ideas>

About your patch - I would suggest to split the part that defines passes
and the pipeline description explicitly, that is, do a passes.def and a
pass-pipeline.def, where in the end we may want to move more information
to passes.def that is now spread out to the various places where we
actually define the struct tree_pass things (the TODO_s come into my mind
here).  One could even go further and try to integreate this somewhat with
common.opt where documentation and options for most of the passes are
(that is, generate a optimizers.opt from the passes.def).  But that's for
a second stage as well.

Richard.