linux-kernel - Re: [PATCH] compiler_types: Introduce inline_for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260119190341.39c3d04c@pumpkin>
Date: Mon, 19 Jan 2026 19:03:41 +0000
From: David Laight <david.laight.linux@...il.com>
To: Nicolas Pitre <nico@...xnic.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Eric Dumazet
 <edumazet@...gle.com>, linux-kernel <linux-kernel@...r.kernel.org>,
 netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet
 <eric.dumazet@...il.com>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH] compiler_types: Introduce inline_for_performance

On Mon, 19 Jan 2026 10:47:51 -0500 (EST)
Nicolas Pitre <nico@...xnic.net> wrote:

> On Sun, 18 Jan 2026, David Laight wrote:
> 
> > On 32bit you probably don't want to inline __arch_xprod_64(), but you do
> > want to pass (bias ? m : 0) and may want separate functions for the
> > 'no overflow' case (if it is common enough to worry about).  
> 
> You do want to inline it. Performance quickly degrades otherwise.

If it isn't inlined you want a real C function in div.c (or similar),
not the compiler generating a separate body in the object file of each
file that uses it.
That is just the worst of both worlds.

> Numbers are in the commit log where I introduced that change.
> 
> And __arch_xprod_64() exists only for 32bit btw.

I wonder how much of a mess gcc makes of that code.
I added asm functions for u64 mul_add(u32 a, u32 b, u32 c) calculating
a * b + c without explicit zero extending any of the 32 bit values.
Without that gcc runs out of registers and starts spilling to stack
instead of just generating 'mul; add; adc $0'.

I could only find the definition in the header file - may not have
looked hard enough.
But 64bit systems without a 64x64=>128 multiply (ie without u128
support) also need the 'multiply in 32bit chunks' code.
And common code is fine with u128 support (ignoring old compilers
that generate a call on 64bit mips even though it has exactly the
instruction you want).

	David