From: David Laight <David.Laight@ACULAB.COM>
To: 'Lorenzo Stoakes' <lorenzo.stoakes@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"Jason@zx2c4.com" <Jason@zx2c4.com>,
"hch@infradead.org" <hch@infradead.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"pedro.falcato@gmail.com" <pedro.falcato@gmail.com>,
Mateusz Guzik <mjguzik@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: Build performance regressions originating from min()/max() macros
Date: Wed, 24 Jul 2024 11:05:17 +0000 [thread overview]
Message-ID: <1877ab0f14cf4f7d9da2a53e211cfdc1@AcuMS.aculab.com> (raw)
In-Reply-To: <3ad33eb6-49d7-4e67-8fa5-1beec8d4af4f@lucifer.local>
From: Lorenzo Stoakes
> Sent: 24 July 2024 09:45
..
> It seems that (again, all credit to Arnd for his thorough analysis here) a
> lot of the underyling issue revolves around the macros need to function
> both in scenarios where we absolutely must have a constant value (for
> instance, array size) as well as in scenarios where this is not the case.
>
> Arnd also discovered [0] there _relatively_ few call sites that require
> this, so maybe a way forward might be to create specific min()/max() macros
> for the strictly const case and to fix up the core ones to reduce expansion
> at the cost of not being able to use these in these scenarios?
>
> Does this seem viable? Perhaps David you might have thoughts on this?
Indeed.
MIN() and MAX() could be used for compile-time constants (and require constants).
They would then be usable for static initialisers.
Before that can be done all the places that locally define MIN() and MAX()
need changing to either use min()/max() or surround the local definition
with an #ifdef until the global definition is added.
But there are some optimisations that can be done first.
The significant one is implement min3() directly (and probably without
the 'can be constant' logic.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2024-07-24 11:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 21:59 Lorenzo Stoakes
2024-07-24 8:14 ` Jürgen Groß
2024-07-24 8:31 ` Lorenzo Stoakes
2024-07-24 9:40 ` Jürgen Groß
2024-07-24 9:43 ` Lorenzo Stoakes
2024-07-24 14:47 ` David Laight
2024-07-24 8:34 ` David Laight
2024-07-24 8:50 ` Arnd Bergmann
2024-07-24 8:44 ` Lorenzo Stoakes
2024-07-24 11:05 ` David Laight [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1877ab0f14cf4f7d9da2a53e211cfdc1@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@kernel.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mjguzik@gmail.com \
--cc=pedro.falcato@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox