From: David Laight <david.laight.linux@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
Yury Norov <yury.norov@gmail.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
Andi Shyti <andi.shyti@linux.intel.com>,
David Laight <David.Laight@aculab.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v4 4/8] bits: introduce fixed-type BIT
Date: Wed, 5 Mar 2025 21:13:44 +0000 [thread overview]
Message-ID: <20250305211344.0c7c3782@pumpkin> (raw)
In-Reply-To: <Z8hyNXVZxLzhEzNy@smile.fi.intel.com>
On Wed, 5 Mar 2025 17:48:05 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> > On 05/03/2025 at 23:33, Andy Shevchenko wrote:
> > > On Wed, Mar 05, 2025 at 10:00:16PM +0900, Vincent Mailhol via B4 Relay wrote:
>
> ...
>
> > >> +#define BIT_U8(b) (BIT_INPUT_CHECK(u8, b) + (unsigned int)BIT(b))
> > >> +#define BIT_U16(b) (BIT_INPUT_CHECK(u16, b) + (unsigned int)BIT(b))
Why even pretend you are checking against a type - just use 8 or 16.
> > >
> > > Why not u8 and u16? This inconsistency needs to be well justified.
What is the type of BIT(b) ?
it really ought to be unsigned int (so always 32bit), but I bet it
is unsigned long (possibly historically because someone was worried
int might be 16 bits!)
> >
> > Because of the C integer promotion rules, if casted to u8 or u16, the
> > expression will immediately become a signed integer as soon as it is get
> > used. For example, if casted to u8
> >
> > BIT_U8(0) + BIT_U8(1)
> >
> > would be a signed integer. And that may surprise people.
They always get 'surprised' by that.
I found some 'dayjob' code that was doing (byte_var << 1) >> 1 in order
to get the high bit discarded.
Been like that for best part of 30 years...
I wasn't scared to fix it :-)
> Yes, but wouldn't be better to put it more explicitly like
>
> #define BIT_U8(b) (BIT_INPUT_CHECK(u8, b) + (u8)BIT(b) + 0 + UL(0)) // + ULL(0) ?
I don't think you should force it to 'unsigned long'.
On 64bit a comparison against a 32bit 'signed int' will sign-extend the
value before making it unsigned.
While that shouldn't matter here, someone might copy it.
You just want to ensure that all the values are 'unsigned int', trying
to return u8 or u16 isn't worth the effort.
When I was doing min_unsigned() I did ((x) + 0u + 0ul + 0ull) to ensure
that values would always be zero extended.
But I was doing the same to both sides of the expression - and the compiler
optimises away all the 'known 0' extension to 64bits.
> Also, BIT_Uxx() gives different type at the end, shouldn't they all be promoted
> to unsigned long long at the end? Probably it won't work in real assembly.
> Can you add test cases which are written in assembly? (Yes, I understand that it will
> be architecture dependent, but still.)
There is no point doing multiple versions for asm files.
The reason UL(x) and ULL(x) exist is because the assembler just has integers.
Both expand to (x).
There might not even be a distinction between signed and unsigned.
I'm not sure you can assume that a shift right won't replicate the sign bit.
Since the expression can only be valid for constants, something simple
like ((2 << (hi)) - (1 << (lo)) really is the best you are going to get
for GENMASK().
So just define a completely different version for asm any nuke the UL() etc
for readability.
David
next prev parent reply other threads:[~2025-03-05 21:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 13:00 [PATCH v4 0/8] bits: Fixed-type GENMASK()/BIT() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 1/8] bits: fix typo 'unsigned __init128' -> 'unsigned __int128' Vincent Mailhol via B4 Relay
2025-03-05 14:30 ` Yury Norov
2025-03-05 14:36 ` Andy Shevchenko
2025-03-05 14:38 ` Yury Norov
2025-03-05 16:09 ` Vincent Mailhol
2025-03-05 14:34 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 2/8] bits: split the definition of the asm and non-asm GENMASK() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 3/8] bits: introduce fixed-type genmasks Vincent Mailhol via B4 Relay
2025-03-05 14:30 ` Andy Shevchenko
2025-03-05 14:38 ` Vincent Mailhol
2025-03-05 14:41 ` Andy Shevchenko
2025-03-06 14:48 ` Lucas De Marchi
2025-03-05 15:22 ` Yury Norov
2025-03-05 15:50 ` Andy Shevchenko
2025-03-19 1:46 ` Yury Norov
2025-03-19 3:34 ` Anshuman Khandual
2025-03-19 4:13 ` Anshuman Khandual
2025-03-21 17:05 ` Yury Norov
2025-03-22 11:46 ` Vincent Mailhol
2025-03-05 15:47 ` Yury Norov
2025-03-05 15:52 ` Jani Nikula
2025-03-05 16:48 ` Vincent Mailhol
2025-03-05 19:45 ` Andy Shevchenko
2025-03-06 9:22 ` Vincent Mailhol
2025-03-06 9:28 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 4/8] bits: introduce fixed-type BIT Vincent Mailhol via B4 Relay
2025-03-05 14:33 ` Andy Shevchenko
2025-03-05 14:48 ` Vincent Mailhol
2025-03-05 15:48 ` Andy Shevchenko
2025-03-05 17:17 ` Vincent Mailhol
2025-03-05 19:56 ` Andy Shevchenko
2025-03-05 21:50 ` David Laight
2025-03-06 8:12 ` Jani Nikula
2025-03-06 9:12 ` Andy Shevchenko
2025-03-06 9:38 ` Vincent Mailhol
2025-03-05 21:13 ` David Laight [this message]
2025-03-05 13:00 ` [PATCH v4 5/8] drm/i915: Convert REG_GENMASK* to fixed-width GENMASK_* Vincent Mailhol via B4 Relay
2025-03-05 14:37 ` Andy Shevchenko
2025-03-05 13:00 ` [PATCH v4 6/8] test_bits: add tests for __GENMASK() and __GENMASK_ULL() Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 7/8] test_bits: add tests for fixed-type genmasks Vincent Mailhol via B4 Relay
2025-03-05 13:00 ` [PATCH v4 8/8] test_bits: add tests for fixed-type BIT Vincent Mailhol via B4 Relay
2025-03-05 15:59 ` [PATCH v4 0/8] bits: Fixed-type GENMASK()/BIT() Jani Nikula
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=20250305211344.0c7c3782@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=David.Laight@aculab.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lucas.demarchi@intel.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=yury.norov@gmail.com \
/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