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.
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.
> The downside is that then we wouldn't be able to use the generic one
> and would have to use the type-specific ones which would be annoying.
Doesn't seem to be all that bad to me. If we do the fallback like in the
above it should be fairly ok repetition wise.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
