Link-time optimization status

[Matúš Kukan]

Hi Michael,

On 19 June 2012 10:55, Michael Meeks <michael.meeks at suse.com> wrote:
>> I also got an internal compiler error somewhere.
>
>        Yep, so we should file those bugs I suppoe.

For me, to file a bug is almost like to fix a bug for non-developer.
And it works with newer gcc anyway.

>> Here are few differences in size (not stripped): LTO / not-LTO
>> total size of workdir/*/LinkTarget/Library: 290M / 304M
>
>        Goodness - an un-stripped library is of a random size; highly affected
> by debuginfo / symbol tables etc. IMHO it is only worth comparing
> stripped library sizes; can you easily generate those ? :-)

Sure.
It's 189M vs. 204M in total.
libmergedlo.so 36M / 41M
...
libcuilo.so 3.9M / 3.8M is slightly bigger
...
nothing more really interesting.

I guess -Os would behave similar.

>> so sometimes is creates bigger libraries.
>
>        That is interesting; so - Jan - how well does LTO cope with -Os vs. -O2
> etc. and/or Matus - what compile flags are we using ?

It's quite random. For me it's -O2 on 64bit system.
But we are using -Os on 32bit linux platform.

>> Maybe it's not all about the size ?
>
>        :-) well; we want to be smaller of course. Potentially getting more
> code inside the libmerged perimiter helps - and potentially better
> visibility markup so that the LTO can know that a given function is not
> used outside of that libmerged is useful. So far we have only a markup
> that says "used outside of un-merged library", really we need to split
> that into two types of markup that distinguish whether it is used
> outside of libmerged or not (I think).

Hmm, this does not seem to be doable quickly.
But maybe it's easy and possible to file an easy hack ?

>        Thanks ! this was a great GSOC project :-)

Yep, thanks.

Best,
Matus