You are not logged in.

#1 2019-03-12 01:02:37

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

The legend of ld.gold (testing link-time optimization)

Can we discuss the GNU compiler in this subforum?

EDIT:

quequotion wrote:

Is gimp just a bad example to test this on?

I notice that gimp-git does configure in prepare(), which means none of the flags set by libmakepkg/buildenv extensions (which only set during build()) are applied; probably much ado about nothing here.

I use these flags to enable link-time optimization:

CFLAGS+=" -flto=$(getconf _NPROCESSORS_ONLN)"
CXXFLAGS+=" -flto=$(getconf _NPROCESSORS_ONLN)"
LDFLAGS+=" -fuse-linker-plugin"
LTOPLUGIN="$(gcc -print-search-dirs | grep install | awk '{print $2 "liblto_plugin.so"}')"
ARFLAGS+=" --plugin $LTOPLUGIN"
RANLIBFLAGS+=" --plugin $LTOPLUGIN"
NMFLAGS+=" --plugin $LTOPLUGIN"

I am considering if I should additionally make use of ld.gold, under the impression this may be a requirement for, or optional benefit to the oft-recommended "-fuse-linker-plugin" flag, but most of the information I can find on it seems rather old and ad-hoc.

gcc.gnu.org wrote:

LTO will take advantage of the plugin feature in gold. This allows the compiler to pick up object files that may have been stored in library archives. To use this feature, you must be using gold as the linker and enable the use of the plugin by compiling with gcc -fuse-linker-plugin.

A lot of places recommend putting $CFLAGS in $LDFLAGS to use LTO, which does not seem to come from the gcc developers:

dnovillo wrote:

To enable LTO, simply add the flag '-flto' to both compile and
link commands.

Rather this seems to be (hesitantly) purported by Debian:

wiki.debian.org wrote:

There is only one weird thing: The compiler still compiles when you think it should be linking. This is why you pass the compile time flags (like -O2 etc.) also at link time. ... Frankly speaking, there is apparently the same effect by just adding -flto to the LDFLAGS, not the whole $CFLAGS.

I find no evidence that it makes any difference, nor that it makes a difference to specify "-flto" in both $CFLAGS and $LDFLAGS. Some other places recommend putting both "-flto" and "-fuse-linker-plugin" in both groups of flags, but again, no proof that changes anything.

Five years and one month ago, another archer searching for the El Dorado of gcc was given this advice:

Allan wrote:

gcc -fuse-ld=gold

That is probably based on the official documentation:

gcc.gnu.org wrote:

-fuse-ld=gold
Use the gold linker instead of the default linker.

I was not able to prove that this flag actually has the effect it says it does; the ordinary linker appears to be used regardless. I also tried changing the linker with $LD, but the ordinary linker appears to be used regardless.

Another common suggestion is to symlink /usr/bin/ld to /usr/bin/ld.gold to force the issue.

I spent some time trying out all of the above suggestions and possible combinations of flags to (clean chroot) build gimp-git a dozen or so times. The only one that resulted in a reduction in the size of the compiled binary--by 0.6%--(far less than what the Debian wiki page above suggests as evidence that LTO worked) was to move the existing /usr/bin/ld (appears to be a copy of ld.bfd) out of the way and symlink /usr/bin/ld to /usr/bin/ld.gold.

Is that the only way to use the gold linker? Does LTO really work otherwise? Is gimp just a bad example to test this on?

Last edited by quequotion (2019-03-13 00:04:25)

Offline

#2 2019-03-12 12:52:46

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: The legend of ld.gold (testing link-time optimization)

This sounds like you're comparing red/blue apples with red/blue oranges

You basically have 4 scenarios that should be compared :

1. ld without LTO
2. ld with LTO
3. gold without LTO
4. gold with LTO

Maybe you should simplify things and just test LTO with one linker ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2019-03-12 13:52:01

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: The legend of ld.gold (testing link-time optimization)

Lone_Wolf wrote:

This sounds like you're comparing red/blue apples with red/blue oranges

Turns out I was barking up the wrong tree entirely. The tests you suggest are worth doing, but my post above is based on the results of working with a bad package.

We're going to have to do something to discourage packagers from generating makefiles in prepare(), which prevents flags set (or unset) by scripts in /usr/share/makepkg/buildenv/ from being applied to the resulting makefiles, as those scripts are only run during build().

To be honest I am guilty of the same, a bad habit I picked up by learning to write PKGBUILDs from reading other people's PKGBUILDs.

EDIT: On the case; as is eschwartz!

Last edited by quequotion (2019-03-12 18:41:05)

Offline

#4 2019-03-13 09:27:38

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: The legend of ld.gold (testing link-time optimization)

Those changes look like an improvement.

One question about them :
I've advocated putting autoreconf in prepare() for a long time as it changes sourcecode files.
Is that advise correct ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#5 2019-03-13 11:37:56

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: The legend of ld.gold (testing link-time optimization)

Lone_Wolf wrote:

I've advocated putting autoreconf in prepare() for a long time as it changes sourcecode files.

Yes

Offline

Board footer

Powered by FluxBB