LTO vs GCC 8

[Freddie Chopin]

On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting.  Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.

My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sections can are objects from
toolchain library.

> Have you tried with -ffunction-sections and not -fdata-sections?  It
> is
> the -fdata-sections that ruins -fsection-anchors - the
> -ffunction-sections doesn't have the same kind of cost.

Results:
- -ffunction-sections + -fdata-sections = 124396 ROM + 3484 RAM
- -ffunction-sections = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors + -fno-common = 125168 ROM +
3676 RAM 

Generated executables for the second, third and fourth case are
identical - assembly listings for these three cases have no differences
at all.

I've also tried with -fno-section-anchors, and this makes a minor
(negative) difference - 125352 ROM + 3676 RAM.

> No, -fsection-anchors has plenty of use for fixed-position eabi code.
> ...
> The code is clearly bigger and slower, and uses more anchors in the
> code
> section.
> 
> Note that to get similar improvements with non-static data, you need
> "-fno-common" - a flag that I believe should be the default for the
> compiler.

I cannot reproduce this here ); Don't get me wrong - if there's a
"free" way to improve code size/speed with some compiler flags which I
did not use previously, then I'm very much interested, however in my
particular case the best result (size-wise) I get is with just
-ffunction-sections + -fdata-sections. The difference is not huge, but
it's also not negligible. Maybe this has to do with different compiler
versions we are comparing (4.8 vs 8.1)? I guess this is not LTO (which
I did not enable for these measurements), as you did not mention it in
your flags...

Regards,
FCh