Enabling LTO for target libraries (e.g., libgo, libstdc++)

[Nikhil Benesch]

Richard, regarding your first mail, I'm afraid I'm not sure what you
mean. Isn't this exactly the section of configure.ac that handles
CC_FOR_TARGET? The Makefile is dumb and just passes the
autoconf-substituted value for CC_FOR_TARGET directly through.

(I agree the patch will need some tweaks to work for all the
build/host/target combination possibilities.)

On Fri, Jan 25, 2019 at 12:18 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 25 Jan 2019, Nikhil Benesch wrote:
>
> > I am attempting to convince GCC to build target libraries with link-time
> > optimizations enabled. I am primarily interested in libgo, but this discussion
>
> Note that as far as I know issues with host-dependencies of LTO bytecode
> (bug 41526) may still exist, so this wouldn't work with Canadian cross
> compilers.

Ack, thanks for the heads up. For now I'm only interested in turning on
LTO during native builds.

> > I have a simple patch to the top-level configure.ac that resolves the issue by
> > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which were
> > built earlier and know how to pass the linker plugin to the underlying ar/ranlib
> > commands. The patch is small enough that I've included it at the end of this
> > email.
>
> Will those wrappers properly wrap round tools for the target that were
> configured using --with-build-time-tools?

That's a good question. I think the answer is no. I'll investigate
further.

On Fri, Jan 25, 2019 at 12:39 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers <joseph@codesourcery.com> wrote:
> >On Fri, 25 Jan 2019, Nikhil Benesch wrote:
> >
> >> I am attempting to convince GCC to build target libraries with
> >link-time
> >> optimizations enabled. I am primarily interested in libgo, but this
> >discussion
> >
> >Note that as far as I know issues with host-dependencies of LTO
> >bytecode
> >(bug 41526) may still exist, so this wouldn't work with Canadian cross
> >compilers.
>
> I was expecting the LTO byte code not to be retained in the built libraries.
>
> >> I have a simple patch to the top-level configure.ac that resolves the
> >issue by
> >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers
> >which were
> >> built earlier and know how to pass the linker plugin to the
> >underlying ar/ranlib
> >> commands. The patch is small enough that I've included it at the end
> >of this
> >> email.
> >
> >Will those wrappers properly wrap round tools for the target that were
> >configured using --with-build-time-tools?
>