This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][LTO] Rework -flto-partition=, add =one case
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Apr 2014 12:23:58 +0200 (CEST)
- Subject: Re: [PATCH][LTO] Rework -flto-partition=, add =one case
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1404011533560 dot 31108 at zhemvz dot fhfr dot qr> <20140401171333 dot GB29079 at kam dot mff dot cuni dot cz>
On Tue, 1 Apr 2014, Jan Hubicka wrote:
> > This reworks the option to use the Enum support we have now and
> > adds a =one case (to eventually get rid of one LTO operation mode,
> > =none ...). I was tempted to support -flto-partition=<number>
> > and get rid of --param lto-partitions (thereby also supporting =1),
> Yep, I preffer to have one switch to chose algorithm and other to set
> its parameter as you do now. At the moment partitioning is quite a non-issue
> since only important IPA passes works on whole thing, but that may change and
> we may want to play with different partitionings.
> (I have plans for that for incremental compilation and other things)
Well, partitioning is important to get a parallel build.
> > but that param specifies the maximum number of partitions and
> > still uses the balanced algorithm, thus the result would be
> > confusing (and of little use I suppose, as opposed to =1 which should
> > give you the same answer as =none).
> =none still seems somewhat useful - for setups where you do multiple parallel
> compilations it will be faster than WHOPR and it helps developing IPA passes
> since you do not need to worry about WHOPR complexities at start.
True, but as it ends up eating more memory your multiple parallel
compilations may in the end be slower if they run into swap ;)
And you can do simple IPA passes just where IPA-PTA sits now - at LTRANS
> But with the code to bring function bodies at demand, this is less important.
> I believe with passmanager being bit more flexible, the code paths can be
> almost completely shared. Have few patches on this and pass queue reorg for
> next stage1, so will try to push them out.
Yeah, it would be nice to make the flow of compilation somewhat more
obvious that it is now ...