Re: [PATCH v2 next 05/11] tools/nolibc/printf: Simplify __nolibc_printf()

[David Laight <david.laight.linux@gmail.com>]

On Sun, 8 Feb 2026 15:44:29 +0100
Willy Tarreau <w@1wt.eu> wrote:

> Hi David,
> 
> On Sun, Feb 08, 2026 at 12:20:31PM +0000, David Laight wrote:
> > On Sat, 7 Feb 2026 23:50:19 +0000
> > David Laight <david.laight.linux@gmail.com> wrote:
> >   
> > > On Sat, 7 Feb 2026 21:05:42 +0100
> > > Willy Tarreau <w@1wt.eu> wrote:
> > >   
> > > > On Fri, Feb 06, 2026 at 07:11:15PM +0000, david.laight.linux@gmail.com wrote:    
> > > > > From: David Laight <david.laight.linux@gmail.com>
> > > > > 
> > > > > Move the check for the length modifiers into the format processing
> > > > > between the field width and conversion specifier.
> > > > > This lets the loop be simplified and a 'fast scan' for a format start
> > > > > used.
> > > > > 
> > > > > If an error is detected (eg an invalid conversion specifier) then
> > > > > copy the invalid format to the output buffer.
> > > > > 
> > > > > Reduces code size by about 10% on x86-64.      
> > > > 
> > > > I'm surprised, because for me it's the opposite:
> > > > 
> > > >   $ size hello-patch*
> > > >      text    data     bss     dec     hex filename
> > > >      1859      48      24    1931     78b hello-patch1
> > > >      2071      48      24    2143     85f hello-patch2
> > > >      2091      48      24    2163     873 hello-patch3
> > > >      2422      48      24    2494     9be hello-patch4
> > > > 
> > > > The whole program grew by almost 16%, and that's a 30% increase since
> > > > the first patch. This is with gcc 15 -Oz. aarch64 however decreased by
> > > > 15 bytes since previous patch.
> > > > 
> > > > I have not figured what makes this change yet, I'm still digging.    
> > > 
> > > Running scripts/bloat-o-meter will give more detail.
> > >   
> > > > Willy    
> > > 
> > > I'm using gcc 12.2 and just running 'make O=xxx' for the test program.
> > > The object looks like what I'd expect, so might be -O2.
> > > 
> > > Is it constant folding the #defines.
> > > For me it generating the (1 << (c & 31)) & 0xxxxx as you might hope.  
> > 
> > Further thoughts:
> > 
> > On some of the builds I've done gcc duplicated the code following an 'if'
> > into both the 'then' and 'else' clauses.
> > This isn't good for code size.  
> 
> That's common in loops for example. That's also one reason for avoiding
> "else" statements in compact code.
> 
> However here I finally found what inflates the code, when disassembling
> the whole function: with the move of the multiple "if" statements,
> recent compilers managed to turn it into a jump table, that considerably
> inflates .rodata and the function as well. By passing -fno-jump-tables,
> the size drops by ~500 bytes:

That is just insane...
That might go away with the patch that changes is all to bit-masks.

I'd done some full disassembly comparisons myself to see why changes
made the code larger.
I had an OPTIMIZER_HIDE_VAR(sign) in there to help, but the final
version didn't need it.
What this sort of code needs is something to force the compiler to
only have one copy of something - I found a proposal for an attribute
(or similar) for an asm block to do that, but nothing came of it.

> 
>    text    data     bss     dec     hex filename
>    2422      48      24    2494     9be hello-patch4
>    1917      48      24    1989     7c5 hello-patch4-alt   <---
> 
> Building with gcc before 13 also avoids this table and explains why
> you had better code with gcc-12.
> 
> I also noticed that we can reduce the loop by ~40 bytes by moving the
> literal copy after after the block that deals with format sequences,
> because it eases comparisons, but that's no big deal for now since your
> subsequent patches are going to change all that.

Some of the early patches are carefully arranged to reduce churn
later on.

I might add the 'if (v == 0)' clause much earlier to avoid the churn
cause by the extra indent when it is added.

I'll add some extra comments as you suggested in the other patches.

I do know all about optimising for size, and for the 'worst case path'.
The latter was some embedded hdlc code that had to finish in 196 clocks.

	David

> 
> At least I wanted to understand what was causing this difference for
> us both, and whether it risked remaining definitive or not, so now
> this patch is OK to me.
> 
> Acked-by: Willy Tarreau <w@1wt.eu>
> 
> Willy