[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Jan 2016 03:56:07 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: string word-at-a-time and atomic.h FAQ on twitter
* Matthew Fernandez <matthew.fernandez@...ta.com.au> [2016-01-06 10:39:34 +1100]:
> On 06/01/16 04:50, Rich Felker wrote:
> >On Tue, Jan 05, 2016 at 05:46:41PM +0100, Szabolcs Nagy wrote:
> >>... however i find lto a
> >>weak excuse to rewrite strlen in asm for all targets since lto
> >>of libc is still not practical ...
>
> This is an interesting comment; would you mind expanding on this a little? Though we don't do it
> regularly, we have used LTO on Musl C in the past. I am not aware of any Musl-specific issues we
> encountered, though it's entirely possible our build contained latent bugs.
two things:
1) does not give the expected improvements (smaller, faster)
on code that's factored well.
2) wrong code genertion (because of lto implementation bugs,
or because of invalid c code)
i think we saw issues around file scope inline asm,
we speculated about issues around fenv access because
the compilers don't model that correctly and
early dynamic linker code.
it is easy to imagine other nasty cases especially if
gcc extensions are in use: they are often not carefully
specified enough to have robust semantics with lto
(e.g. attribute const for tls was an example where the
semantics is unclear but lto makes it easier to break
code if the user and compiler disagree)
in short: i dont see the benefits given the risks.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
