Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
gcc-4.8.0-rc1 lto experience
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Mon Mar 18, 2013 6:46 am    Post subject: gcc-4.8.0-rc1 lto experience Reply with quote

Call me a ricer, but I did give gcc-4.8.0-rc1 a try 8) .
I had enabled lto with gcc-4.7 and I wanted to see how lto develops. I'm pleased to say that things got a lot better and I would consider it no more insane than -O3. The reason is mainly that -O3 causes runtime breakage whereas lto usually fails at build time. I'm doing that on my testing system, so unfortunatelly it won't get as much of everyday testing.
My main interest in lto is in space savings, because I'm an embedded developer and if you have to make an update over gprs you're thankful for every byte saved.

With gcc-4.7 my list of software NOT build with lto is:
x11-drivers/xf86-video-intel dev-util/kdevelop dev-db/mysql kde-base/akregator kde-base/okteta app-admin/sudo media-sound/pulseaudio media-libs/opencv app-text/libwps media-libs/libvisio media-sound/alsa-tools dev-lang/ocaml dev-libs/libf2c media-gfx/digikam media-gfx/hugin dev-lang/spidermonkey sci-libs/shapelib sys-apps/sysvinit dev-lang/perl sys-libs/gpm dev-libs/elfutils dev-lang/python sys-fs/e2fsprogs sys-apps/hdparm sys-apps/pciutils dev-vcs/cvs dev-qt/qtscript dev-qt/qtopengl media-libs/alsa-lib dev-util/dialog dev-util/valgrind app-cdr/cdrtools x11-libs/wxGTK dev-qt/qtwebkit dev-qt/qtdeclarative x11-base/xorg-server dev-tex/luatex app-misc/strigi kde-base/kdelibs kde-base/okular sys-devel/llvm dev-libs/glib sys-auth/polkit net-analyzer/nmap media-video/ffmpeg media-video/mplayer app-office/akonadi-server media-libs/mesa sys-fs/ddrescue

And now I tried the same list with gcc-4.8 and the ones failing to build were:
app-admin/sudo dev-db/mysql dev-lang/ocaml dev-lang/perl dev-lang/spidermonkey dev-libs/elfutils dev-qt/qtscript dev-qt/qtwebkit dev-tex/luatex dev-util/kdevelop dev-util/valgrind dev-vcs/cvs kde-base/kdelibs media-libs/alsa-lib media-libs/mesa media-sound/pulseaudio media-video/ffmpeg media-video/mplayer sci-libs/shapelib sys-apps/pciutils sys-devel/llvm x11-base/xorg-server x11-drivers/xf86-video-intel

I did make a backup of my /var/db/pkg to be able to have a close look at the sizes, but this has to wait until next weekend. And it won't tell me the space savings of lto either, because I'm mixing things up a bit. I'm comparing stuff compiled with gcc-4.7 (mostly with lto) with stuff compiled under gcc-4.8 and lto. But this is just a quick and dirty test.

If you want to try yourself copy gcc-4.8.0_alpha20121216.ebuild from the toolchain overlay to gcc-4.8.0_rc20130316.ebuild of your local overlay.

I could imagine very bad results for packages not obeying LDFLAGS, because this can result in an completely unoptimized binary.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Mon Mar 18, 2013 8:16 am    Post subject: Re: gcc-4.8.0-rc1 lto experience Reply with quote

firetwister wrote:
I could imagine very bad results for packages not obeying LDFLAGS, because this can result in an completely unoptimized binary.

Are you sure? I was understanding that .o files are optimized with -flto anyway but only that at link time a second optimization takes place. Has this changed in gcc-4.8? This would be bad...
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Mon Mar 18, 2013 9:21 am    Post subject: Re: gcc-4.8.0-rc1 lto experience Reply with quote

mv wrote:
firetwister wrote:
I could imagine very bad results for packages not obeying LDFLAGS, because this can result in an completely unoptimized binary.

Are you sure? I was understanding that .o files are optimized with -flto anyway but only that at link time a second optimization takes place. Has this changed in gcc-4.8? This would be bad...


It didn't change in gcc-4.8. From the gcc manpage:

Quote:
Additionally, the optimization flags used to compile individual files are not necessarily related to those used at link time.


However the example they provide there didn't optimize during the compile. However some optimizations are quite pointless during compile (e.g inlining) when you will do an lto, so ideally you don't want to optimize during compile anymore and want to do that at linking, but if LDFLAGS will be ignored you end up without optimization.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Mon Mar 18, 2013 3:03 pm    Post subject: Re: gcc-4.8.0-rc1 lto experience Reply with quote

firetwister wrote:
Quote:
Additionally, the optimization flags used to compile individual files are not necessarily related to those used at link time.

I read this as: With -c -flto the optimization parameter (i.e. C{XX,}FLAGS) are applied and again for linking (i.e. LDFLAGS). So if you specify the same optimizations in C{XX,}FLAGS as in LDFLAGS you might have redundant optimizations (like e.g. inlining decisision might change as you mentioned), but even if LDFLAGS are ignored the result should not be worse than without -flto.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Tue Mar 19, 2013 9:00 pm    Post subject: Reply with quote

I've done some mesurements with compiling wget. Wget is rather small, its unoptimized binary is not even 500k, so the results may be different with other sources.

As reference 100 % is compiled with gcc-4.7.2 without optimization, which is 471192 Bytes large and took 4.62 (user) seconds to build.

First of all, "mv" you're right. If you don't optimize with lto during link, you're still left with the other optimizations you've enabled during compile. The compile time overhead for adding lto information is about 10%.
What I'm more confused about is, that it does make a size difference of about 6% if I'm compiling and linking with "-Os -flto", or if I ommit "-Os" at compile time. How does that conform to the man page?

For -O2 the size between 4.7 and 4.8 stayed about the same, for -O3, "-O2 -flto" and any combination of {-O0,-Os} and {,-flto} it shrank about 1% and for "-O3 -flto" it shrank 2%.

Simply optimizing for size gives about 74% in size (349808 Bytes) and 207% in compile time.
To get to the smallest size of 70% (332784 Bytes) I had to compile and link with "-Os -flto" which took 345% of the original time. That's 28% more time than -O3 would take.

So all in all, there seem to be improvements, with gcc-4.8. There are no behaviour changes with lto compared to 4.7, but the quality improved. If there is a size improvement of one percent on avaerage that would be great (seems small, but don't expect wonders from updating a mature compiler).

Now let's find out which wget downloads the fastest :lol:
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Wed Mar 20, 2013 8:49 am    Post subject: Reply with quote

firetwister wrote:
What I'm more confused about is, that it does make a size difference of about 6% if I'm compiling and linking with "-Os -flto", or if I ommit "-Os" at compile time. How does that conform to the man page?

There are two possible explanations, but I don't know which is true:
First explanation is trivial: The optimization flags used for compiling should be stored in the .o files and re-used for the linking phase. At least, this was the original plan, but the implementation was buggy or incomplete - only some flags seemed to be stored. So it might be the case that this has been fixed (I think this was one of the causes for many issues with lto).
The other explanation is less trivial: It might be the case that some optimization used for -Os is not idempotent, i.e. if it applies to already optimized code, it can optimize even more (or maybe produces worse code). Hence, if the code was already optimized during compiling and is optimized again you get a different result than if optimized only once.
Back to top
View user's profile Send private message
drhirsch
n00b
n00b


Joined: 08 May 2004
Posts: 65
Location: Germany

PostPosted: Wed Mar 20, 2013 10:21 am    Post subject: Reply with quote

You could try "-fno-fat-lto-objects". This makes sure that no compiled binary code is contained in the object files at all :-) And it should speed up the compile process somewhat.

Of course then only a lto-aware linker is able to link the object files to an executable binary. If after that apllying "-Os" twice results in a different binary size than only linking it with "-Os" you should ask at the gcc-help mailing list and possibly file a bug ^^
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Wed Mar 20, 2013 7:13 pm    Post subject: Reply with quote

drhirsch wrote:
You could try "-fno-fat-lto-objects". This makes sure that no compiled binary code is contained in the object files at all :-)

Except for the intermediate code, of course, which is the one being optimized. I would be very surprised if this option would change anything besides the size of .o files (and perhaps of .a libraries): The linker will remove all other binary code anyway in the LTO phase.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Wed Mar 20, 2013 9:26 pm    Post subject: Reply with quote

mv wrote:
I would be very surprised if this option would change anything besides the size of .o files (and perhaps of .a libraries): The linker will remove all other binary code anyway in the LTO phase.

This is not the first surprise I had with lto and I'm quite sure it won't be the last either.

The build time reduces dramatically. It's now about the same as normal -Os without lto. But the sizes are exactly the same as the first lto build. It's still the case that the resulting binary is smaller when -Os is specified durling compile and link.

But the -fno-fat-lto-objects option didn't work out of the box. I had to use the "gcc-" wrappers for "ar", "ranlib" and "nm", or else I got tons of unresolved symbols. Same problem when using gold. My binutils are built with --enable-gold and --enable-plugins.

There seems to be a bug in 4.7.2 with those wrappers.
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=192166
I'm getting "gcc-config: error: could not run/locate 'ar'" with gcc-4.7.2, but they work with 4.8. I wrote a wrapper for the 4.7.2 toolchain.

Code:
#!/bin/sh
cmd=$1
shift
/usr/bin/ar $cmd --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-rc20130316/liblto_plugin.so $*


Gold did make binaries a tiny amount smaller (0.2%) but took about 10% more time. I thought gold was meant to be the fastest linker out there.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Thu Mar 21, 2013 7:48 am    Post subject: Reply with quote

firetwister wrote:
#This is not the first surprise I had with lto and I'm quite sure it won't be the last either.

Nothing what you wrote is surprising, provided that you used a program whose built system uses internally .a libraries (which I thought you wouldn't do for a first test): As expected and documented, the option just omits the emission of the processor code to lto files which is not used during lto - in the ideal case which happens currently out-of-the-box only if you link only .o files. If you also link .a files (or first even generate .a files with ar) you need plugins and gold linker.
The speed and size difference for gold comes from the fact that with gold the whole program - including .a files - is optimized while otherwise the .a data is just linked with only the first optimization phase.
Concerning the explaation I gave earlier, still both cases are possible.
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 361
Location: Graben-Neudorf, Germany

PostPosted: Thu Mar 21, 2013 11:11 am    Post subject: Reply with quote

Thank you for your test!

I also activated LTO globally, but with an the 201212xx alpha version of GCC 4.8 and for a full kde-desktop. It worked quite well after disabling LTO for about 30-50 packages. I’ll try to test it again for the rc.

I got my ebuild for testing from the hardened-development overlay.
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Thu Mar 21, 2013 11:28 am    Post subject: Reply with quote

I was surprised by the huge speedup. I didn't expect to get lto optimization almost for free.
The wrappers are documented in the gcc man page, so no surprise there.
You do not need the gold linker to link against archives of no-fat-lto-objects, but the linker needs plugin support. Which refers to the liblto_plugin.so.
I choose wget as my benchmark, because it's a single program in plain C, but not so highly optimized like busybox.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Thu Mar 21, 2013 2:16 pm    Post subject: Reply with quote

firetwister wrote:
You do not need the gold linker to link against archives of no-fat-lto-objects, but the linker needs plugin support

Which AFAIK means practically that you do need the gold linker unless you have written your own linker.
Back to top
View user's profile Send private message
drhirsch
n00b
n00b


Joined: 08 May 2004
Posts: 65
Location: Germany

PostPosted: Fri Mar 22, 2013 8:11 am    Post subject: Reply with quote

I have recompiled my whole system with gcc-4.8-rc and lto and so far it looks quite promising. I will do some size compares with the old (4.7.2) system later. So far I had to disable lto for

Code:

sys-apps/pci-utils no-lto.conf
dev-lang/perl no-lto.conf
dev-qt/qtscript no-lto.conf
dev-qt/qtcore no-lto.conf
dev-java/antlr no-lto.conf
net-analyzer/nmap no-lto.conf
app-text/aspell no-lto.conf
sys-apps/coreutils no-lto.conf
dev-lang/ocaml no-lto.conf
dev-lang/python no-lto.conf
dev-lang/spidermonkey no-lto.conf
dev-util/valgrind no-lto.conf
media-libs/alsa-lib no-lto.conf
app-admin/sudo no-lto.conf
dev-vcs/cvs no-lto.conf
dev-libs/elf-utils no-lto.conf
sys-fs/quota no-lto.conf
dev-qt/qtdeclarative no-lto.conf
dev-qt/qtwebkit no-lto.conf
sys-devel/llvm no-lto.conf
sys-devel/clang no-lto.conf
media-libs/mesa no-lto.conf
media-gfx/inkscape no-lto.conf
media-sound/pulseaudio no-lto.conf
app-office/libreoffice no-lto.conf


Regarding "-fno-fat-lto-objects": My main concern is that during some builds the optimization flags may be stripped during the final link phase (depending on the toolchain and/or portage, I just don't know enough about it) which will result in a binary with no optimization at all, so I have refrained from using it. A lto-aware toolchain should not use any optimization during the compile phase, but only during the final link phase (btw, did you ever try -flto=4 or similar on a multicore box, it works quite good), saving quite an amount of compilation time. But there are still some issues, as the double-size-optimized binary of firetwister shows - I still think its a kind of bug ^^[/code]
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Sat Mar 23, 2013 7:59 am    Post subject: Reply with quote

mv wrote:
Which AFAIK means practically that you do need the gold linker unless you have written your own linker.

The wiki thinks so:
http://gcc.gnu.org/wiki/LinkTimeOptimization
But I don't think so.
1. Using gold results in a slightly smaller binary, if gold would be used implicitly the binary size should be the same. I know we've seen some mysteries regarding sizes.
2. Renaming ld.gold still results in a successful link, except -fuse-ld=gold (4.8 feature) is specified.
3.
man gcc wrote:
-fuse-linker-plugin
Enables the use of a linker plugin during link-time optimization. This option relies on plugin support in the linker, which is available in gold or in GNU ld 2.21 or newer.


drhirsch wrote:
Regarding "-fno-fat-lto-objects": My main concern is that during some builds the optimization flags may be stripped during the final link phase ... which will result in a binary with no optimization at all


Don't worry about that. Even the simplest program will fail to link, so this is a great way of detecting bad buildscripts.
You can override it on a per-packet base in your no-lto.conf with -ffat-lto-objects.

drhirsch wrote:
did you ever try -flto=4 or similar on a multicore box

I'm using -flto=2 during link. It's only a dual core, and the main problem is, that it only has 2 gigs of ram. Not using swap frequently results in "virtual memory exhausted" errors.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Sat Mar 23, 2013 7:38 pm    Post subject: Reply with quote

I submitted bugs:
Optimizing at compile and link result in different binary size than only optimizing at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56700
eselect binutils should allow enabling plugin-aware wrappers
https://bugs.gentoo.org/show_bug.cgi?id=462796
Back to top
View user's profile Send private message
Moonboots
Tux's lil' helper
Tux's lil' helper


Joined: 02 Dec 2006
Posts: 88

PostPosted: Sun Mar 24, 2013 8:06 am    Post subject: Reply with quote

ArneBab wrote:
Thank you for your test!

I also activated LTO globally, but with an the 201212xx alpha version of GCC 4.8 and for a full kde-desktop. It worked quite well after disabling LTO for about 30-50 packages. I’ll try to test it again for the rc.

I got my ebuild for testing from the hardened-development overlay.


Having a hardened setup, i used the same source for gcc-4.8. (rc2 now the released version ) Did you get following error after successfully installling ?

Failed to set XT_PAX markings -re for:
/var/tmp/portage/sys-devel/gcc-4.8.0/image//usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/cc1
Failed to set XT_PAX markings -re for:
/var/tmp/portage/sys-devel/gcc-4.8.0/image//usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/cc1plus
Executables may be killed by PaX kernels.

There were 3/4 package that didn't build with lto,although they worked with gcc-4.7.2-r1. Also 4 just failed to build x11-apps/luit sys-libs/db-4.8.30 net-libs/webkit-gtk-1.10.2-r300 net-wireless/gnome-bluetooth-3.6.1

Also i can't build with genkernel the latest hardened-sources-3.8.4 there is the folowing error

cc1: erreur: cannot load plugin /usr/src/linux-3.8.4-hardened/tools/gcc/constify_plugin.so

Perhaps this is linked to XT_PAX markings error ?
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Sun Mar 24, 2013 8:29 am    Post subject: Reply with quote

The gcc from hardened-development didn't compile for me - it dies not so late with some undefined symbol, I forgot. When I omitted all gentoo/hardened patches it worked.

Concerning the failure of hardened-sources to compile, this is not so surpising: They build a rather complex plugin for the gcc, and probably that plugin interface has changed. With new version of hardened-sources you can configure the kernel such that this plugin is not used, so when you switch it off, the kernel should compile. However, you have then a less hardened kernel, of course :wink:
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5610
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Mon Mar 25, 2013 5:24 pm    Post subject: Reply with quote

sys-devel/gcc-4.8.0 from the hardened-development overlay built fine here:

Quote:
* Switching native-compiler to x86_64-pc-linux-gnu-4.7.2 ...>>> Regenerating /etc/ld.so.cache...
[ ok ]

* If you have issues with packages unable to locate libstdc++.la,
* then try running 'fix_libtool_files.sh' on the old gcc versions.

* You might want to review the GCC upgrade guide when moving between
* major versions (like 4.2 to 4.3):
* http://www.gentoo.org/doc/en/gcc-upgrading.xml

>>> sys-devel/gcc-4.8.0 merged.
>>> Regenerating /etc/ld.so.cache...

* Messages for package sys-devel/gcc-4.8.0:

*
* LTO support is still experimental and unstable.
* Any bugs resulting from the use of LTO will not be fixed.
*
* If you have issues with packages unable to locate libstdc++.la,
* then try running 'fix_libtool_files.sh' on the old gcc versions.
* You might want to review the GCC upgrade guide when moving between
* major versions (like 4.2 to 4.3):
* http://www.gentoo.org/doc/en/gcc-upgrading.xml
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
Randy Andy
Veteran
Veteran


Joined: 19 Jun 2007
Posts: 1009
Location: /dev/koelsch

PostPosted: Mon Mar 25, 2013 8:32 pm    Post subject: No rule without exception Reply with quote

Hi Folks.

Interesting discussion about such bleeding edge technique, I'm also experimenting with, since some weeks.

I just wondering why none of you had listed the

Code:
dev-libs/libaio no-lto.conf


package in your package.env file, which causes me lots of trouble.

The tricky thing with it for me was, it compiles fine with LTO, but as followof this my akonadi-server doesn't work anymore, so my kmail stops working and also I wasn't able to recompile my mariadb package which works fine until then.
I presume it should be the same if you use mysql for akonadi.

Possibly none of you use KDE and so isn't affected by this bug https://bugs.gentoo.org/show_bug.cgi?id=461260, but maybe it could help anyone to prevent some trouble.

Drhirsch.
Yes, I'm also using -flto=4 here on my quad core :wink:

Regards, Andy.
_________________
If you want to see a Distro done right, compile it yourself!
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Wed Mar 27, 2013 8:48 am    Post subject: Reply with quote

I finished rebuilding my system, lto isn't looking as good as in the first test anymore.
I've only 4 packages that do not build with gcc-4.8 at all, which is really good:
Code:
dev-python/pygobject
kde-base/kopete
sys-apps/paludis
x11-apps/luit

Did anybody compile them with 4.8 and this is just another lto bug?

I've seen much more problems with libraries that build fine, but packages depending on them then fail with undefined references.
Libreoffice should build with lto (EXTRA_ECONF="--enable-lto"), but it needs 6gigs of ram. Ram not swap! I wasn't able to build the qt and intel drivers because of lack of ram as well.

Randy Andy I can confirm your problem with libaio, but I probably wouldn't have it noticed for some time on that machine.

Packages now building:
Code:
app-cdr/cdrtools
app-misc/strigi
app-office/akonadi-server
app-text/libwps
dev-lang/python
dev-libs/glib
dev-libs/libf2c
dev-qt/qtopengl
dev-util/dialog
kde-base/akregator
kde-base/okteta
kde-base/okular
media-gfx/digikam
media-gfx/hugin
media-libs/libvisio
media-libs/opencv
media-sound/alsa-tools
net-analyzer/nmap
sys-apps/hdparm
sys-apps/sysvinit
sys-auth/polkit
sys-fs/ddrescue
sys-fs/e2fsprogs
sys-libs/gpm
x11-libs/wxGTK


Packages still broken:
Code:
app-admin/sudo
dev-db/mysql
dev-lang/ocaml
dev-lang/perl
dev-lang/spidermonkey
dev-libs/elfutils
dev-qt/qtdeclarative
dev-qt/qtscript
dev-qt/qtwebkit
dev-tex/luatex
dev-util/kdevelop
dev-util/valgrind
dev-vcs/cvs
kde-base/kdelibs
media-libs/alsa-lib
media-libs/mesa
media-sound/pulseaudio
media-video/ffmpeg
media-video/mplayer
sci-libs/shapelib
sys-apps/pciutils
sys-devel/llvm
x11-base/xorg-server
x11-drivers/xf86-video-intel


Packages broken since 4.8:
Code:
app-arch/par2cmdline
app-text/rarian
dev-lang/tk
dev-libs/dotconf
dev-libs/libaio
dev-libs/libical
dev-libs/libxdg-basedir
dev-qt/qtcore
dev-tcltk/itk
dev-tcltk/tix
gnome-base/orbit
kde-base/kdebase-kioslaves
kde-base/kdeplasma-addons
kde-base/kdesu
kde-base/plasma-workspace
media-gfx/freecad
media-libs/coin
media-libs/liblqr
net-libs/libasyncns
net-misc/openssh
sys-apps/coreutils
x11-libs/libXfixes


So if you compare the size of the first and the last list you see that the improvements don't look like a big step forward anymore. One could compile the last list with gcc-4.7, so there would be only the common ones left. However my aim wasn't to get most packages optimized with lto, but to see if it's prime-time ready and frankly - NO it still isn't, but I think it's still better than -O3.
Having more packages that compile fine, but then letting dependencies of them fail at link, like libXfixes, libasyncns, coin, orbit, libxdg-basedir, libical, dotconf or even fail at runtime like libaio (the only one so far, so better than 4.7) is worse than simply having a package fail to link. However I think there should be something like a lto overlay for the brave testers.
In case of text size reduction, there have been some improvements. Unfortunatelly I realized I forgot to save the size of /usr/lib64/debug halfway during merge, so the size of /usr/lib64 isn't accurate. However comparing the space savings from those directories for the second half of the merge, it seems like the savings are evenly distributed, so the numbers shouldn't be that wrong.

/usr/bin 90%
/usr/lib64/ 94%
/usr/libexec/ 100%
/bin 102%
/lib64 100%
----
Overall the size of the binaries is only 95% of the size of the binaries compiled with gcc-4.7 and lto

My gcc bug report because of the different sizes can now be explained. -O0 does disable local optimization, and optimization in general, so you have to optimize with at least with -O1 at compile time. It's similar to specifying -O0 and -finline-functions, which does nothing.
Back to top
View user's profile Send private message
costel78
Apprentice
Apprentice


Joined: 20 Apr 2007
Posts: 189

PostPosted: Fri Mar 29, 2013 8:09 am    Post subject: Reply with quote

Regarding using -fno-fat-lto-objects I am confused. I'm unable to find proper documentation about those.
After compiled gcc-4.8.0 from hardened-overlay I have installed both:
Code:
ls -als /usr/bin/gcc-ar /usr/bin/ar
 0 lrwxrwxrwx 1 root root    22 mar 27 09:00 /usr/bin/ar -> x86_64-pc-linux-gnu-ar
12 -rwxr-xr-x 1 root root 10024 mar 27 09:36 /usr/bin/gcc-ar


Do I still need those wrappers with gcc 4.8 ?
Can you, please, tell me their name, content and path (where to put them) ?

Thank you!
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 48

PostPosted: Fri Mar 29, 2013 11:29 am    Post subject: Reply with quote

Quote:
Regarding using -fno-fat-lto-objects I am confused. I'm unable to find proper documentation about those.

The gcc manpage mentions them - mentions is the correct term here :wink:
Quote:
After compiled gcc-4.8.0 from hardened-overlay I have installed both:

You already got them with gcc-4.7, though they didn't work for me back then. What those wrappers do is probably best explained by the script I provided in post 9.
IMHO you shouldn't do anything with those wrappers but using them, like you would use their non-wrapped counterparts. But this is where the hassle is. You have to convince all the buildsystems out there to use the wrapped ones and not the original ones. That's why I submitted the bug for eselect/binutils-config which should take care of that systemwide.

In the meantime I have created symlinks in /usr/local/bin

Code:
lrwxrwxrwx 1 root root    56 Mar 20 22:32 ar -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-ar
lrwxrwxrwx 1 root root    56 Mar 20 22:33 nm -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-nm
lrwxrwxrwx 1 root root    60 Mar 20 22:33 ranlib -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-ranlib
lrwxrwxrwx 1 root root    56 Mar 20 22:36 x86_64-pc-linux-gnu-ar -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-ar
lrwxrwxrwx 1 root root    56 Mar 20 22:37 x86_64-pc-linux-gnu-nm -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-nm
lrwxrwxrwx 1 root root    60 Mar 20 22:37 x86_64-pc-linux-gnu-ranlib -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-rc20130316/gcc-ranlib
Back to top
View user's profile Send private message
costel78
Apprentice
Apprentice


Joined: 20 Apr 2007
Posts: 189

PostPosted: Fri Mar 29, 2013 1:50 pm    Post subject: Reply with quote

I see now. They are there, are working - at least for v4.8, but simply they are not called when required.
I'll wait until gcc 4.8 hit portage and I'll try to use globally -fno-fat-lto-objects.
Thank you!
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
FireBurn
Apprentice
Apprentice


Joined: 19 Sep 2004
Posts: 165
Location: Edinburgh, UK

PostPosted: Wed Apr 03, 2013 1:27 am    Post subject: Reply with quote

This is my list so far:


app-admin/sudo no-lto.conf
app-cdr/cdrdao no-lto.conf
app-emulation/wine no-lto.conf
dev-lang/perl no-lto.conf
dev-lang/python no-lto.conf
dev-lang/spidermonkey no-lto.conf
dev-libs/elfutils no-lto.conf
dev-qt/qtdeclarative no-lto.conf
dev-qt/qtscript no-lto.conf
games-fps/tremulous no-lto.conf
media-libs/alsa-lib no-lto.conf
media-libs/mesa-32bit no-lto.conf
media-libs/mesa no-lto.conf
media-sound/wavpack no-lto.conf
media-video/ffmpeg no-lto.conf
media-video/mplayer no-lto.conf
net-misc/openssh no-lto.conf
sys-apps/coreutils no-lto.conf
sys-apps/hwinfo no-lto.conf
sys-apps/pciutils no-lto.conf
sys-boot/grub no-lto.conf
sys-devel/binutils gold.conf
sys-devel/clang-32bit no-lto.conf
sys-devel/clang no-lto.conf
sys-devel/llvm-32bit no-lto.conf
sys-devel/llvm no-lto.conf
sys-process/numactl no-lto.conf
www-client/chromium no-lto.conf
x11-apps/xkbcomp no-lto.conf
x11-base/xorg-server no-lto.conf
x11-drivers/xf86-video-intel no-lto.conf
x11-libs/cairo no-lto.conf

Both wine and libreoffice have run time issues - wine I've tested both with lto and without I get issues either way - libreoffice I'm recompiling without LTO to see if it makes a difference

Make sure you compile xkbcomp without LTO otherwise X11 won't start
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum