This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Cleaning up the pass manager


> 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.

This has been my goal for years, but somehow it always got off the top of
TODO list ;)
> 
> 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.
> - 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.
> - dump_file and dump_flags are no longer globals.

One thing I would like to see (i.e. plan to add once I have time for it)
is to commonize normal&LTO&WHOPR queues.
At the moment WHOPR WPA somehow stands away and LTO is implemented by breaking
up the previously continuous pass queue into pieces.

I hope to be able to add cgraph API to bring function bodies in at demand and
commonize LTO&WHOPR pass queues up to the end of IPA passes.  WPA then can be a
pass that will simply do the streaming and tell passmanager to terminate
compilation (the second feature will be useful to iplement LTO .o files not
containing assembly at all for compile time perfomrance reasons).

This imply some reshuffling of lto.c from lto dir into backend, but I hope it
won't be that bad: most of functionality is already there anyway.
(or a way of allowing FE to add its own pass into queue)

Honza
> 
> Are there any particular pain points that people are currently
> experiencing that fit this?
> 
> 
> Thanks.  Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]