Re: Optmize bitmapword macros calc (src/backend/nodes/bitmapset.c)

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optmize bitmapword macros calc (src/backend/nodes/bitmapset.c)
Date: 2024-01-29 19:53:13
Message-ID: 20240129195313.GA3673695@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 29, 2024 at 04:43:32PM -0300, Ranier Vilela wrote:
> Em seg., 29 de jan. de 2024 às 16:32, Nathan Bossart <
> nathandbossart(at)gmail(dot)com> escreveu:
>> -#define WORDNUM(x) ((x) / BITS_PER_BITMAPWORD)
>> -#define BITNUM(x) ((x) % BITS_PER_BITMAPWORD)
>> +#define WORDNUM(x) ((bitmapword)(x) / BITS_PER_BITMAPWORD)
>> +#define BITNUM(x) ((bitmapword)(x) % BITS_PER_BITMAPWORD)
>>
>> I'm curious why we'd cast to bitmapword and not straight to uint32. I
>> don't think the intent is that callers will provide a bitmapword to these
>> macros.
>
> bitmapword It is the most correct and prudent option, if in the future,
> we decide to change the number of nwords to uint64.

If we change nwords to a uint64, I think there will be many other changes
required. Using uint32 probably trims the instructions further on machines
with 64-bit pointers, too (e.g., cdqe).

>> I also wonder if it's worth asserting that x is >= 0 before
>> casting here.
>>
> I don't think this would change anything.

Right, but it would offer another layer of protection against negative
integers in Bitmapsets.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-01-29 19:58:04 Re: Should we remove -Wdeclaration-after-statement?
Previous Message Ranier Vilela 2024-01-29 19:43:32 Re: Optmize bitmapword macros calc (src/backend/nodes/bitmapset.c)