RE: [PATCH v4 1/3] math.h: add DIV_ROUND_UP_NO_OVERFLOW

From: David Laight
Date: Thu Oct 26 2023 - 04:57:21 EST


From: Linus Torvalds
> Sent: 25 October 2023 18:44
>
> On Wed, 25 Oct 2023 at 05:05, Vasily Gorbik <gor@xxxxxxxxxxxxx> 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)