On Fri, Dec 4, 2015 at 1:27 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-12-03 12:10:27 +0000, Greg Stark wrote:
>> I'm leaning towards using the builtin functions described here
>
> For performance reasons? Michael's version of the patch had the
> necessary 'raw' macros, and they don't look *that* bad. Using the
> __builtin variants when available, would be nice - and not hard. On
> e.g. x86 the overflow checks can be done much more efficiently than both
> the current and patched checks.
Using the _builtin functions when available would be indeed a nice
optimization that the previous patch missed.
> I wonder though if we can replace
>
> #define PG_INT16_ADD_OVERFLOWS(a, b) ( \
> ((a) > 0 && (b) > 0 && (a) > PG_INT16_MAX - (b)) || \
> ((a) < 0 && (b) < 0 && (a) < PG_INT16_MIN - (b)))
>
> #define PG_INT32_ADD_OVERFLOWS(a, b) ( \
> ((a) > 0 && (b) > 0 && (a) > PG_INT32_MAX - (b)) || \
> ((a) < 0 && (b) < 0 && (a) < PG_INT32_MIN - (b)))
>
> ...
>
> with something like
> #define PG_ADD_OVERFLOWS(a, b, MINVAL, MAXVAL) ( \
> ((a) > 0 && (b) > 0 && (a) > MAXVAL - (b)) || \
> ((a) < 0 && (b) < 0 && (a) < MINVAL - (b)))
> #define PG_INT16_ADD_OVERFLOWS(a, b) \
> PG_ADD_OVERFLOWS(a, b, PG_INT16_MIN, PG_INT16_MAX)
>
> especially for the MUL variants that'll save a bunch of long repetitions.
Yeah, we should. Those would save quite a couple of lines in c.h.
--
Michael