Re: Build performance regressions originating from min()/max() macros

["Jürgen Groß" <jgross@suse.com>]

On 24.07.24 10:31, Lorenzo Stoakes wrote:
> On Wed, Jul 24, 2024 at 10:14:12AM GMT, Jürgen Groß wrote:
>> On 23.07.24 23:59, Lorenzo Stoakes wrote:
>>> Arnd reported a significant build slowdown [0], which was bisected to the
>>> series spanning commit 80fcac55385c ("minmax: relax check to allow
>>> comparison between unsigned arguments and signed constants") to commit
>>> 867046cc70277 ("minmax: relax check to allow comparison between unsigned
>>> arguments and signed constants"), originating from the series "minmax:
>>> Relax type checks in min() and max()." [1].
> 
> [snip]
> 
>> I can send a patch to simplify the problematic construct, but OTOH this
>> will avoid only one particularly bad example.
> 
> Thanks, appreciated but I am a little concerned that we might get stuck in
> whack-a-mole here a bit. I'm pretty sure we've had previous patches that
> have addressed invocation points, but obviously the underlying issue are
> these macros which will keep cropping up again and again.

The xen example seems to be one of the worst due to nesting of min3() and
min(), so being de facto a min4().

I think drivers/firmware/sysfb_simplefb.c has a similar problem, as it is
nesting max() with max3(). Same applies to arch/x86/kernel/cpu/cacheinfo.c
and multiple times to fs/xfs/libxfs/xfs_trans_resv.c.

There are probably more such extreme cases.


Juergen