On Fri, Dec 4, 2015 at 1:27 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
