[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66e58cd2cffa462a979ac5415874a570@AcuMS.aculab.com>
Date: Tue, 25 Jul 2023 13:20:01 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Matthew Wilcox' <willy@...radead.org>
CC: "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
"'Andy Shevchenko'" <andriy.shevchenko@...ux.intel.com>,
'Andrew Morton' <akpm@...ux-foundation.org>,
'Christoph Hellwig' <hch@...radead.org>,
"'Jason A. Donenfeld'" <Jason@...c4.com>
Subject: RE: [PATCH next resend 1/5] minmax: Add min_unsigned(a, b) and
max_unsigned(a, b)
From: Matthew Wilcox
> Sent: 25 July 2023 13:39
>
> On Tue, Jul 25, 2023 at 11:48:14AM +0000, David Laight wrote:
> > +#define min_unsigned(x, y) \
> > + __careful_cmp((x) + 0u + 0ul + 0ull, (y) + 0u + 0ul + 0ull, <)
>
> What is the point of "+ 0u + 0ul + 0ull"? How is that any different
> from "+ 0ull"? And why force the compiler to do a 64-bit comparison
> when it could do a 32-bit comparison?
The "+ 0u + 0ul + 0ull" causes a signed 32bit value to be zero extended
to 64bit. This is significantly cheaper than the sign extension.
(Adding 0ull first converts a signed 32bit value to a signed
64bit one - the same as a cast.)
The compiler also then knows that the high 32bit are zero and
optimises away any associated compares.
So you get a 32bit compare (on both 32bit and 64bit) if both
arguments are 32bit.
This happens even at -O0.
It also has no effect on pointer types.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists