From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Non-decimal integer literals |
Date: | 2022-11-23 08:54:25 |
Message-ID: | CAApHDvr6m8Sipff_MjqyQ8HLeDA3LB5x9zE1oMBPBLxFwTUKQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 23 Nov 2022 at 02:37, Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> Here is a new patch.
This looks like quite an inefficient way to convert a hex string into an int64:
while (*ptr && isxdigit((unsigned char) *ptr))
{
int8 digit = hexlookup[(unsigned char) *ptr];
if (unlikely(pg_mul_s64_overflow(tmp, 16, &tmp)) ||
unlikely(pg_sub_s64_overflow(tmp, digit, &tmp)))
goto out_of_range;
ptr++;
}
I wonder if you'd be better off with something like:
while (*ptr && isxdigit((unsigned char) *ptr))
{
if (unlikely(tmp & UINT64CONST(0xF000000000000000)))
goto out_of_range;
tmp = (tmp << 4) | hexlookup[(unsigned char) *ptr++];
}
Going by [1], clang will actually use multiplication by 16 to
implement the former. gcc is better and shifts left by 4, so likely
won't improve things for gcc. It seems worth doing it this way for
anything that does not have HAVE__BUILTIN_OP_OVERFLOW anyway.
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-11-23 08:56:15 | Re: Non-decimal integer literals |
Previous Message | Peter Smith | 2022-11-23 08:36:31 | Re: [DOCS] Stats views and functions not in order? |