This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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).
Richard.