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


> 2010/4/29 Jan Hubicka <hubicka@ucw.cz>:
> >> > 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).
> >
> > And do something about paralelizing the whopr build. ?I guess it means storing
> > ltrans partition list into file and making collect2 to execute compilation
> > and re-invent the Makefile code?
> > It would be great if someone took look at this, I am not at all familiar with that
> > code and in a way I would preffer it to stay that way ;))
> 
> I will look at moving the LTRANS driving to the driver, it should be
> easy to do parallel execs from it and hopefully make debugging
> WPA/LTRANS less of a headache.

That would be great, thanks!
It would be also great to get the parallel build working, but I guess it can be done
inrementally.

One problem is that we output .o files via assembly.  We produce a lot of temporary
data and producing all temporary .s files and processing them alter from collect
will increase memory use etc...
So probably doing as from wpa itself is sort of needed to avoid this bottleneck.

Honza
> 
> Richard.
> 
> > Honza
> >


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