[Freemint-list] Beyond Brown

[Markus Fröschle]

On Wed, Mar 1, 2017 at 11:22 AM, Adam Klobukowski <adamklobukowski at gmail.com
> wrote:

>
> With elf binary we could use linking options like Ffunction-sections
>  fdata-sections flto, that allow linker to remove unused functions and data
> from the resulting binary.  We all do not like 100kb hello world programs,
> and with that they would shrink considerable.
>
>
-ffunction-sections and -fdata-sections only help (a little) regarding
executable size if you have rather unorganized sources (i.e scattered
external functions that don't belong to each other in the same file). If
you have a clean source tree with only one external function per module
(and possible supporting static functions in the same compilation unit),
you won't gain much from these options. mintlib has usually one function
per compilation unit and all objects compiled into an archive. The linker
only pulls an object from the archive if something it already has requests
it to do so. There is not much of a risk that ld will produce bloated
binaries with unused functions this way - if a function is pulled in, it's
actually used (at least to a high probability).

What -flto does it does is actually much smarter: it delays optimization to
link time and thus does enables cross-module optimizing. Basically, all
objects keep their original source (in gcc's internal format) in a special
section. On final link, ld does not use the binary object, but takes all
the sources out of that section and glues them together just as if it were
one large compilation unit, compiling them altogether. This enables it to
act much smarter regarding inlining it could do otherwise.

I have done a comparision of m68k-atari-mint-gcc and m68k-elf-gcc with
EmuTOS (which supports both compilers) a few months ago to see what LTO can
do for m68k.

There are differences regarding size in general: newer gcc versions seem to
invest more program size into optimization at higher optimization levels
than our 4.6.4 mint version does, but also can do better size optimization
when told to do so with -Os.

Actually, the size improvements from -flto were below 2-3% best case. With
a (pretty non-scientific) brief GEMBENCH benchmark, there were speed
improvements in around the same percentage area.

Bottom line is: while it certainly would be desireable to always have the
latest and best toolchain available, do not expect too much from it...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170301/2e6a5f5c/attachment.html