Re: [PATCH] Make BITMAP_WORD more easily configurable

[Richard Biener <rguenther at suse dot de>]

On Tue, 30 Jul 2019, Martin Sebor wrote:

> On 7/30/19 9:19 AM, Jakub Jelinek wrote:
> > On Tue, Jul 30, 2019 at 09:16:45AM -0600, Martin Sebor wrote:
> > > Say something like this POC:
> > 
> > We have those already, see ctz_hwi, clz_hwi etc.
> > The thing is that BITMAP_WORD isn't always the same type as unsigned
> > HOST_WIDE_INT, and so we need ones with the BITMAP_WORD type.
> 
> That sounds like a problem overloading would solve to the benefit
> of all clients.  I.e., overload count_trailing_zeros (or whatever
> other name) to take integer arguments of all widths (signed and
> unsigned) and call the appropriate built-in from each.  That way
> we just have to remember one function name and know that it will
> be the right choice regardless of the type of the argument.

The problem with clz at least is that you have to make sure
to only allow overloads to exactly match the type of the
operand since semantics change once you do any promotion.
For popcount and ctz that's only an issue for signed arguments,
but still.

And I don't see any optimization of (uint){clzl,popcountl}((ulong)uintvar)
-> {clz,popcount} (uintvar)

unsigned int foo (unsigned int x)
{
  unsigned long y = x;
  unsigned long z = __builtin_popcountl (y);
  return z;
}

calls __popcountdi2 for me.

So if you dislike the macros then we could add 
{popcount,clz,ctz}_bitmap_word () functions.

Still having the plumbing in once place looks like an improvement
to me - not sure if your comments were an objection to the original
patch?

Thanks,
Richard.