Re: [RFC] stdbit.h implementation

[Jakub Jelinek <jakub@redhat.com>]

On Sat, Nov 18, 2023 at 11:51:34AM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
> 
> > On Sat, Nov 18, 2023 at 11:10:56AM +0100, Florian Weimer wrote:
> >> * Jakub Jelinek:
> >> 
> >> > +# define __stdc_type_width(x)				\
> >> > +  __builtin_popcountg ((__typeof (x)) ~(__typeof (x)) 0)
> >> 
> >> > +# define stdc_leading_zeros(x)				\
> >> > +  ((unsigned int)					\
> >> > +   __builtin_clzg (x, __stdc_type_width (x)))
> >> 
> >> These macros will not be very useful if they expand their arguments
> >> multiple times because the preprocessor output becomes too big if
> >> expressions are nested.  I think we learned that with the type-generic
> >> math facilities.
> >
> > That is the case of the previously posted macros (some of them) as well:
> > #define stdc_first_leading_one(x)                       \
> >   (sizeof (x) == 8 ? stdc_first_leading_one_ull (x)     \
> >    : sizeof (x) == 4 ? stdc_first_leading_one_ui (x)    \
> >    : sizeof (x) == 2 ? stdc_first_leading_one_us (x)    \
> >    : stdc_first_leading_one_uc (x))
> 
> > Do we really need to add compiler builtins for all those 14 type-generic
> > macros because of that?
> 
> Can we use auto?

Maybe __auto_type, I think while the header is C23 only, we want to make
it usable even in older C modes.

>   #define stdc_first_leading_one(x)                            \
>     ({auto __x = (x);                                          \
>       sizeof (__x) == 8 ? stdc_first_leading_one_ull (__x)     \
>       : sizeof (__x) == 4 ? stdc_first_leading_one_ui (__x)    \
>       : sizeof (__x) == 2 ? stdc_first_leading_one_us (__x)    \
>       : stdc_first_leading_one_uc (__x))
> 
> That would avoid multiple expansions.

I think Joseph wanted to avoid ({ }) as it isn't usable outside of functions
(nor in C++ in template argument lists).  Something like
int a = sizeof (stdc_first_leading_one (0ULL));
is valid C23 I believe, though any of the type-generic macro implementations
which use inline functions for something actually isn't usable in C constant
expressions.

If we wanted to build at least most of the stdc type-generic macros that
can't be done right now without preprocessing arguments more than once
through some smaller building blocks, I think we could have some
__builtin_clzg/__builtin_ctzg variants which would use as second argument
implicitly the bitwidth of the first argument and have some type-generic
builtin which would invert bits of argument (__builtin_invertg) -
~(x) is good enough for bitint types and int and larger, but not for
unsigned char/unsigned short.
Perhaps if we don't want to extend the two former builtins two 3 arguments
or add 2 new builtins for that, we could document that if the second
argument has some special type (not int), it would mean the bit width of
the first argument.  Something like (void *) 0, or 0.0, or
__builtin_type_width (), ...
I think with such extensions we could cover all but stdc_bit_width
(where we want to subtract clzg from the type's bit width) and
stdc_bit_floor/stdc_bit_ceil (which are just complicated).

	Jakub