Re: Scripted pass manager

["Ramana Radhakrishnan" <ramana dot r at gmail dot com>]

Hi,

I don't know if this totally makes sense but anyways here goes.

<continuation on crazy idea>

While we are at this . A lot of the gate functions to passes are
essentially dependent on the optimization level at which the pass is
run. I wonder if it might be worthwhile interpreting gating functions
for passes at run time.

If we are to tie this in with some of the ideas with the Function
level optimization specification bit where the user want to possibly
compile certain functions with different  optimization options and /
or passes , would we have to specify the pass dependencies so that the
pass manager would be able to automatically detect these cases and run
the dependent passes before. To run the loop unroller pass alone I
wouldn't want to ask the pass manager to have run any other pass that
this depends on.

</end continuation on crazy idea>


cheers
Ramana

On Nov 29, 2007 7:06 PM, Richard Guenther <richard.guenther@gmail.com> wrote:
>
> 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>
>
>
> Richard.
>



-- 
Ramana Radhakrishnan