Experiences with link time optimization?

[Paul Menzel]

Dear SeaBIOS folks,

in #coreboot on <irc.freenode.net> Stefan mentioned that link time
optimization (LTO) [1] might yield some speed improvements for coreboot
as the resulting firmware image might be smaller and therefore it takes
less time to read it from flash. This was confirmed with coreboot and
GCC 4.6.0 in 2011 by Scott Duplichan [2][3].

The same is true for the payload. As LTO has been greatly improved in
GCC 4.9.0 and is currently all over the news, I wanted to build SeaBIOS
with LTO, but noticed that it already uses `-fwhole-program`. Reading
GCC’s online documentation [1], it says it should not be used in
combination with `-lto`.

-fwhole-program
        Assume that the current compilation unit represents the whole
        program being compiled. All public functions and variables with
        the exception of main and those merged by attribute
        externally_visible become static functions and in effect are
        optimized more aggressively by interprocedural optimizers.
        This option should not be used in combination with -flto.
        Instead relying on a linker plugin should provide safer and more
        precise information.

Using GCC 4.8.2 from Debian Sid/unstable and just removing
`-fwhole-program` and adding `-lto` increased the resulting binary size
though.

As I do not know a lot about compilers and linkers, could some expert
please comment, if `-fwhole-program` already optimizes the code the best
way possible for GCC and therefore LTO is not going to reduce SeaBIOS’
binary size? Unfortunately I did not yet try GCC 4.9.0, so I have no
idea if something improved in that version. And probably my hack was
incorrect anyway.

Thanks,

Paul

[1] http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
    (search for `lto`)
[2] http://www.coreboot.org/pipermail/coreboot/2011-April/064859.html
[3] http://www.coreboot.org/pipermail/coreboot/2011-May/064874.html

[Peter Stuge]

Paul Menzel wrote:
> could some expert please comment, if `-fwhole-program` already
> optimizes the code the best way possible for GCC and therefore
> LTO is not going to reduce SeaBIOS’ binary size?

I think this is a moving target; how well the optimizer works depends
on how mature the optimizer is (not very) and on the code it is asked
to optimize...

//Peter

[Kevin O'Connor]

On Fri, Apr 25, 2014 at 12:06:57AM +0200, Paul Menzel wrote:
> Dear SeaBIOS folks,
>
> in #coreboot on <irc.freenode.net> Stefan mentioned that link time
> optimization (LTO) [1] might yield some speed improvements for coreboot
> as the resulting firmware image might be smaller and therefore it takes
> less time to read it from flash. This was confirmed with coreboot and
> GCC 4.6.0 in 2011 by Scott Duplichan [2][3].

The LTO option allows gcc to perform whole program optimization.
SeaBIOS has been using whole program optimization since SeaBIOS'
inception.  So, there wont be any further improvement to SeaBIOS code
generation in this area.

Currently, SeaBIOS passes all the source code to gcc as one
compilation unit (by effectively concatenating all the code into one
big file) to accomplish the whole program optimization.  The gcc -lto
stuff allows one to use a more traditional compilation of one source
file at a time while still obtaining the benefits of whole program
optimization.  I played with the -lto option quite a bit a year or so
back, but I've found it to be finicky when working with other
necessary build options (eg, for building the code in 16bit mode),
it's been changing a little as new versions of gcc are released, and
it seems to produce less optimized code then the current mechanism.
Might be worth a look again after things have stabilized a bit in gcc
(but only to make the build more traditional).

-Kevin