Re: [HACKERS] Current int & float overflow checking is slow.

On Mon, Oct 30, 2017 at 4:57 PM, Andres Freund  wrote:
> 0001) Introduces pg_{add,sub,mul}{16,32,64}_overflow(a, b, *result)
>       These use compiler intrinsics on gcc/clang. If that's not
>       available, they cast to a wider type and to overflow checks. For
>       64bit there's a fallback for the case 128bit math is not
>       available (here I stole from an old patch of Greg's).
>
>       These fallbacks are, as far as I can tell, C free of overflow
>       related undefined behaviour.

Looks nice.

>       Perhaps it should rather be pg_add_s32_overflow, or a similar
>       naming scheme?

Not sure what the s is supposed to be?  Signed?

> 0002) Converts int.c, int8.c and a smattering of other functions to use
>       the new facilities. This removes a fair amount of code.
>
>       It might make sense to split this up further, but right now that's
>       the set of functions that either are affected performancewise by
>       previous overflow checks, and/or relied on wraparound
>       overflow. There's probably more places, but this is what I found
>       by visual inspection and compiler warnings.

I lack the patience to review this tonight.

> 0003) Removes -fwrapv. I'm *NOT* suggesting we apply this right now, but
>       it seems like an important test for the new facilities. Without
>       0002, tests would fail after this, after it all tests run
>       successfully.

I suggest that if we think we don't need -fwrapv any more, we ought to
remove it.  Otherwise, we won't find out if we're wrong.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers