On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo <dnovi...@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.
