Re: [RFC] Cleaning up the pass manager

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo <dnovillo@google.com> wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. ?In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we have now.
>
> Additionally, I would like to (at some point) incorporate some/most of
> the functionality provided by ICI
> (http://ctuning.org/wiki/index.php/CTools:ICI). ?I'm not advocating
> for integrating all of ICI, but leave enough hooks so such
> experimentations are easier to do.
>
> Initially, I'm going for some low hanging fruit:
>
> - Fields properties_required, properties_provided and
> properties_destroyed should Mean Something other than asserting
> whether they exist.
> - Whatever doesn't exist before a pass, needs to be computed.

How do you want to deal with dump-files needed by the
property computation?  How do we know that it is really only
the following pass that requires a property and not followup
passes (we have been very bad at asserting required properties
in passes).  I'm thinking of PRE which requires split critical
edges for example.

I think using properties can make things less obvious when
debugging what happens.

> - Pass scheduling can be done by simply declaring a pass and
> presenting it to the pass manager. ?The property sets should be enough
> for the PM to know where to schedule a pass.

Ugh.  Please no - how should it know?  Do you want to
introduce PROP_run_after_ccp or what?  Or are you refering
to passes that are just information providers or massage
the IL, like crited or alias?

> - dump_file and dump_flags are no longer globals.

Ugh.

> Are there any particular pain points that people are currently
> experiencing that fit this?

No.  But I'd rather have somebody that wants to improve the
pass manager start to drive more things by it - that way we
will notice things we need before re-designing the whole thing
in a wrong way.

Thanks,
Richard.