From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <torvalds@linux-foundation.org>,
Vasily Gorbik <gor@linux.ibm.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Niklas Schnelle" <schnelle@linux.ibm.com>,
"kernel@collabora.com" <kernel@collabora.com>
Subject: RE: [PATCH v4 1/3] math.h: add DIV_ROUND_UP_NO_OVERFLOW
Date: Thu, 26 Oct 2023 08:57:11 +0000 [thread overview]
Message-ID: <055dd714f98f4e45b2add561b7663378@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHk-=wgs2DDdckcONG+YbB-GDH2QFCoZJ=Vm+YXxb1moZzuDgQ@mail.gmail.com>
From: Linus Torvalds
> Sent: 25 October 2023 18:44
>
> On Wed, 25 Oct 2023 at 05:05, Vasily Gorbik <gor@linux.ibm.com> wrote:
> >
> > You probably want
> >
> > #define __div_round_up(n,d) _Generic((n)+(d), \
> > unsigned long long: __div_round_up_ull, \
> > long long: __div_round_up_ll, \
> > unsigned long: __div_round_up_ul, \
> > long: __div_round_up_l, \
> > unsigned int: __div_round_up_u, \
> > int: __div_round_up_i)(n,d)
> >
> > to avoid early type-checking for expressions that will be discarded
> > and prevent errors like:
>
> Ack. I noticed that later when I tried to do a bigger config build -
> the compiler would warn about the implicit truncation of the integer
> arguments (for the cases where they weren't used).
>
> > Plus typos fixes below passes allyesconfig for s390, 32-bit x86 and arm.
>
> Lovely.
>
> It would have been even better if somebody told me that I was stupid
> and there was some nice trick to it, but at least the _Generic()
> approach doesn't seem broken - just a few tweaks needed.
Doesn't that version end up calling inline functions?
So won't be usable in static initialisers - the same as statement functions.
Will this trick work:
#define ZERO_UNLESS_TYPE(x, type) _Generic(x, type: x, default 0)
#define div_ru(type, fn, n, d) \
type: fn(ZERO_UNLESS_TYPE(type, (n) + (d), n), ZERO_UNLESS_TYPE(type, (n) + (d), d)
then:
#define __div_round_up(n, d) _Generic((n)+(d), \
div_ru(unsigned long long, __div_round_up_ull, n, d),
...
Which would allow the 'functions' be #defines.
But it still has the issues of doing 'big' divisions.
Although the compiler will use 32bit (and 64 by 32 bit) divisions
for 64 bit types if it knows the values are small.
clang seems to add conditionals to avoid 64x64 divides.
Probably worth it for intel x86 cpu, but not for amd ones.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-10-26 8:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 16:18 [PATCH v4 0/3] Fix clock division overflow problem Sebastian Reichel
2023-10-24 16:18 ` [PATCH v4 1/3] math.h: add DIV_ROUND_UP_NO_OVERFLOW Sebastian Reichel
2023-10-24 16:26 ` David Laight
2023-10-24 19:32 ` Linus Torvalds
2023-10-24 22:53 ` Linus Torvalds
2023-10-25 8:03 ` Rasmus Villemoes
2023-10-25 17:37 ` Linus Torvalds
2023-10-25 8:38 ` David Laight
2023-10-25 17:41 ` Linus Torvalds
2023-10-26 8:41 ` David Laight
2023-10-25 15:05 ` Vasily Gorbik
2023-10-25 17:43 ` Linus Torvalds
2023-10-26 8:57 ` David Laight [this message]
2023-10-26 16:54 ` Linus Torvalds
2023-10-27 7:24 ` David Laight
2023-10-25 17:36 ` Sebastian Reichel
2023-10-25 17:28 ` Sebastian Reichel
2023-10-24 16:18 ` [PATCH v4 2/3] clk: divider: Fix divisor masking on 64 bit platforms Sebastian Reichel
2023-10-24 16:18 ` [PATCH v4 3/3] clk: composite: replace open-coded abs_diff() Sebastian Reichel
2023-10-24 16:23 ` Andy Shevchenko
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=055dd714f98f4e45b2add561b7663378@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=kernel@collabora.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=sebastian.reichel@collabora.com \
--cc=torvalds@linux-foundation.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