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 Wed, 6 Oct 2010, Jan Hubicka wrote:
> > > 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?
>
> Yes, but it does not add too much of hassle to have both paths. I think
> when we have just one partition we might actually just go non-streaming
> path always. It saves noticeable amount of time and disk space.
>
> >
> > I also think that -flto should default to -fwhopr-partition=single
> > once it is implemented.
>
> the balanced partitioning should behave for -flto=1 resonably too
> as it has nim partition limit. Of course creating multiple partition
> is useless
> >
> > -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).
>
> Yes, I want to make -fwhopr go away especially to avoid user confusion
> wrt whole-program.
>
> I don't know about -fwhole-program - it seem sane to have independent
> option for that. What alternative would you suggest?
> It is sort of non-plugin only. With LTO plugin on static binaries,
> we get IRONLY resolution so we know what is bound at link time. While
> for dynamic libraries we can use hidden visibilities.
>
> This however suggest that we should default to -flinker-plugin when the
> build environment allows it.
> >
> > 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).
>
> I would say that there is sort of agreement of making -fwhopr going away
> (and it was broken in 4.5 so it has no existing users).
Ok, then I think we should simply drop -fwhopr, keep the semantic
of -flto at first (use a single partition) and make -flto=...
behave the same as -fwhopr=... did.
We can then decide later whether the default behavior for plain -flto
should change. I agree that we should default to using the linker
plugin if it is available (even more so if GNU ld will support it
at the time when 4.6 arrives). But that's an independend change as well.
Richard.