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: LTO question


> On 4/28/10 10:26 , Manuel López-Ibá?ez wrote:
> >>>> Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> >>>> and it is just for solving scaling issue of large program.(These two
> >>>> options do look similar :-). I shall try next.
> >>>
> >>> Yep, -fwhopr is not ideal name, but I guess there is not much
> >>> to do about it.
> > 
> > It is marked as experimental, so if it is going to stay for GCC 4.6,
> > then we should change the name. I think one possibility discussed
> > somewhere is that LTO scales back automatically, so the option would
> > be not necessary.
> 
> Yes.  I think we should just keep -flto and make it use split
> compilation if needed.  -fwhopr is only needed to explicitly enable it.
>  My suggestion is to just keep -flto and invoke whopr with -flto=split
> or -flto=big (until the automatic threshold is added).

Yep, I like this idea too.  I hope to be able to drop "experimental" status
from mainline whopr soonish (basically I need to implement references and then
I will burn a lot of time fixing how clones are streamed to enable ipa-cp).

We probably want something like

 -flto for "do whatever you think is best"
       (it will be interesting to unify the paths enough so WPA can decide to be
        LTO at its will after reading in cgraph and concluding on program size)
 -flto=n to force whopr optimized for N parallel coputations (we probably will
       end up with more than N units for sufficiently large programs since we anyway
       can't resonably expect that compile times will be even).
 -flto=incremental to force inremental LTO.

Honza
> 
> 
> Diego.


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