This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Slim lto objects
> Hi,
> I build Mozilla without debug info with slim LTO and non-LTO.
> slim LTO build is:
>
> real 14m26.882s
> user 78m47.547s
> sys 6m58.870s
> jh@evans:/abuild/jh/build-mozilla-new14> du -s .
> 1056120 .
> jh@evans:/abuild/jh/build-mozilla-new14> size toolkit/library/libxul.so
> text data bss dec hex filename
> 46552709 3585416 381640 50519765 302ded5 toolkit/library/libxul.so
>
> non-LTO build is:
> real 13m19.251s
> user 61m21.386s
> sys 7m28.672s
> jh@evans:/abuild/jh/build-mozilla-new14-no-lto> du -s .
> 424224 .
> jh@evans:/abuild/jh/build-mozilla-new14-no-lto> size toolkit/library/libxul.so
> text data bss dec hex filename
> 32403100 2659736 385224 35448060 21ce4fc toolkit/library/libxul.so
And fat lto build
real 21m43.009s
user 101m43.305s
sys 8m40.085s
jh@evans:/abuild/jh/build-mozilla-new14-fatleto> du -s .
1173900 .
jh@evans:/abuild/jh/build-mozilla-new14-fatleto> size toolkit/library/libxul.so
text data bss dec hex filename
35374139 2908088 380584 38662811 24df29b toolkit/library/libxul.so
fat and slim LTO binary should really be equilvalent, so something is wrong. I can only
think of confused symbol tables in static libraries or so.
Will try to work out what happens.
Also fat LTO and non-LTO Mozilla performs better than slim LTO build.
Honza