This is the mail archive of the gcc@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] WHOPR - A whole program optimizer framework for GCC


Hi,
> 
> Jan, wrt the optimization plan coming out of the analysis phase, and the 
> various pieces of header/summary information, what do you think are the 
> major pieces we need?

The cgraph used to be organized on a separate analysis, propagation and
modify stages and the passes in implemented fall quite naturally into
those pieces. Naturally it is limiting ellement, but not that bad and
for some fancier passes I am sure we can arrange interesting things to
be compiled at once or something like that.

As discussed with Kenny in the past, there are ordering issues - ie one
pass might invalidate info of other so there is a lot of interference
that makes it more challenging to order the IPA pass queue than for
all-in-memory IPA consisting of couple of completely independent passes.

We will need better memory management for Gimple, have effective way to
load function body into memory and actually cheaply release it when it
is no longer needed that is quite challenging with GGC.  I would hope
that in longer term we can move tupleized gimple into pools.

I also have sort of implementation plan TODO, I never got around putting
it into wiki well, but I will try to check how much ours differ and
update it.  One area that is quite nasty WRT LTO is debug info.

Honza
> 
> In terms of branch mechanics, I'm initially tempted to do this 
> implementation on a branch separate from tuples and lto.  This will 
> allow us to merge both lto and tuples separately, as the rest of the 
> optimizer is still a long ways away.  What do folks think?
> 
> 
> Thanks.  Diego.


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