[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <g2g6uomjry23nhbb7niiz5hqs6uu4lxtuqe4mj6yar3qaarqss@zztppfcuox5h>
Date: Tue, 27 Aug 2024 16:42:35 +0100
From: Pedro Falcato <pedro.falcato@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Proposed printf stack usage improvement
On Tue, Aug 27, 2024 at 11:21:33AM GMT, Rich Felker wrote:
> On Tue, Aug 27, 2024 at 10:23:57AM +0100, Pedro Falcato wrote:
> > LGTM.
> >
> > But maybe you should also include my __attribute__((noinline))
> > sugestion, to make sure the integer printf and floating point paths
> > get mixed by the compiler. Even if current gcc/clang don't seem to
> > want to do that, it's better to be safe than sorry (and I assume any
> > LTO/PGO might change that atm).
>
> I'm not clear what ill effect you're trying to mitigate here.
(fwiw, if it wasn't clear: I meant "make sure the <...> *don't* get mixed)
fmt_fp with the patch applied still has a significant stack impact (520 bytes according to my
measurement) which can be avoided on the vast majority of (integer) printfs.
printf_core OTOH uses up 472 bytes of stack, so the simple possibility of inlining it can
(worst case) more than double the stack space used by all printfs.
Granted, the patch seems to convince clang not to inline fmt_fp at all, but AFAIK this is by no means
a guarantee.
One could consider this somewhat of a microoptimization, but musl thread stacks are by no
means big, so...
--
Pedro
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.
