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

[David Laight]

From: Jürgen Groß
> Sent: 24 July 2024 10:40
> 
> 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.

I've just sent in a 7-part patch series that slightly reduces the complexity
and directly implements min3() and max3().
The latter should help.

This is based on part of a series I send months ago that will have 'got lost'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)