This is the mail archive of the 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: Reorganizing -flto and -fwhopr command line options (Was Re: WHOPR partitioning, take 2)

On Tue, 5 Oct 2010, Jan Hubicka wrote:

> > On Tue, 5 Oct 2010, Jan Hubicka wrote:
> > 
> > > > > 
> > > > > 	* doc/invoke.texi (-flto-partition, lto-partitions, lto-minpartition):
> > > > > 	Document.
> > > > > 	* opts.c (decode_options): Handle lto partitions.
> > > > > 	* common.opt (flto-partition): New.
> > > > 
> > > > Shouldn't it be -fwhopr-partition, whopr-partitions and
> > > > whopr-minpartition?  I think it will have no effect for -flto, no?
> > > 
> > > Ah, I plan to bundle -fwhopr as -flto for a while, leaving -flto=0 or similar
> > > option to explicitely disable whopr.  This should make things less confusing for
> > > users - they really don't need to know the difference of lto and whopr.
> > > This is why I called it lto-partition, but I can definitely call it
> > > whopr-partition and rename later once we are ready for the switch (I think we
> > > are, we just need to discuss proper defaults).
> > 
> > Ok, please make sure this gets done then for 4.6 so the current
> > naming is ok then.
> OK, thanks! I can also prepare patch to make -fsuggest-attribute to accept a string.
> I planned to post mail on that.
> Basically we now have
> 1) -flto for LTO (no ltrans streaming)
> 2) -fwhopr for WHOPR with no parallelizm (equivalent of -fwhopr=1)
> 3) -fwhopr=0 for WHOPR with no parallelizm and no temporary makefile
> 4) -fwhopr=n for WHOPR, temporary makefile and parallelizm
> 5) -fwhopr=jobserv for automatic parallelizm, but we need those + rules in GCC.
> I think we want -flto to default to WHOPR and I think it makes sense to adopt
> =n and =jobserv syntax.  I would love it to default to -fwhopr=jobserv but until
> it produces warning about missing + rules (and need them), I think we are stuck.
> We might get fancy and default to 2 or 4 claiming that most developer workstations
> are 2 or 4 core these days, but I guess we will just make it to default to -fwhopr=1?

Yeah, I think so.

> I wonder if we want to support -flto=0 in the sense of 1) or 4). 

I think that eventually we want to get rid of the path not doing
ltrans streaming (would that simplify code?).  Semantically it is
the same if we just have a single ltrans unit, right?

I also think that -flto should default to -fwhopr-partition=single
once it is implemented.

-fwhopr=0 and -fwhopr=1 should both not use a temporary makefile
(what's your reason for the difference?)

> I guess we can have -flto=0 equivalent of -fwhopr=0 these days
> and -flto -flto-partition=none as equivalent of present day -flto.

The question in the end will be what do we expect random Joe user
to do?  Use -flto only?  Use -fwhopr only?  Know about -fwhole-program?

I think in the end having both -flto and -fwhopr adds to the confusion
(not to speak about people thinking -fwhopr implies -fwhole-program,
or the new confusing -f{lto,whopr}-partition or the fancy =XYZ syntax).

Which means we need proper user-level documentation for this LTO thing
(PR 41528).

I'm really undecided on whether and what to do now to all the option
mess (given it's pre-existent in GCC 4.5).


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