Re: Some questions

[Patrick Oppenlander <patrick.oppenlander@gmail.com>]

On Tue, May 1, 2018 at 1:29 AM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Apr 30, 2018 at 03:17:11PM +1000, Patrick Oppenlander wrote:
>> Last time I tried to LTO a C library I ran into this:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215#c1
>
> I don't quite understand the issue as reported there. The example is
> defining abs in a way that could be self-referential in the absence of
> -fno-builtin or -ffreestanding (which implies -fno-builtin). But the
> use of -ffreestanding is always necessary to build a libc. This is in
> no way specific to LTO.

There were other related bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203

It all boiled down to the case where gcc was emitting a runtime symbol
and couldn't resolve the reference at static link time.

I've just run through the various test cases and they appear to be
resolved in the gcc on this arch box (7.3.1).

> Anyway I don't think this issue affects musl but I'm not sure.

You're probably right.

> The issue I'm aware of is that the reference to _start_c from the
> top-level asm _start function is not seen by LTO. This should be
> possible to work around just by teaching configure to check if
> -fno-lto is supported, and if so having the Makefile pass it for crt
> files. But I'm skeptical that you'd get much benefit applying LTO to
> musl itself. It's known that you don't for producing a shared library
> (ppl have tested this), but static may fare better. In theory a really
> smart LTO could optimize out the whole floating point support from
> printf when all formst strings are literals and none contain %f's, but
> in practice none are anywhere near that smart.

Marking _start_c with __attribute__((used)) should also work.

In a static link LTO will also inline many trivial functions from the
C library which can reduce binary size and help with instruction cache
footprint & locality. I've had good results especially on targets with
small instruction caches executing in place.

Another benefit is constant propagation across the library boundary
which can also eliminate reasonable amounts of code.

Patrick