From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Xi Wang <xi(dot)wang(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] overflow checks optimized away |
Date: | 2015-10-09 13:52:19 |
Message-ID: | 20151009135219.GD21859@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Any news on this item from 2013, worked on again 2014?
---------------------------------------------------------------------------
On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 02:04:10AM +0000, Greg Stark wrote:
> > Attached is what I have so far. I have to say I'm starting to come
> > around to Tom's point of view. This is a lot of hassle for not much
> > gain. i've noticed a number of other overflow checks that the llvm
> > optimizer is not picking up on so even after this patch it's not clear
> > that all the signed overflow checks that depend on -fwrapv will be
> > gone.
> >
> > This patch still isn't quite finished though.
> >
> > a) It triggers a spurious gcc warning about overflows on constant
> > expressions. These value of these expressions aren't actually being
> > used as they're used in the other branch of the overflow test. I think
> > I see how to work around it for gcc using __builtin_choose_expr but it
> > might be pretty grotty.
> >
> > b) I'm concerned these checks depend on INT_MIN/MAX and SHRT_MIN/MAX
> > which may not be exactly the right length. I'm kind of confused why
> > c.h assumes long is 32 bits and short is 16 bits though so I don't
> > think I'm making it any worse. It may be better for us to just define
> > our own limits since we know exactly how large we expect these data
> > types to be.
> >
> > c) I want to add regression tests that will ensure that the overflow
> > checks are all working. So far I haven't been able to catch any being
> > optimized away even with -fno-wrapv and -fstrict-overflow. I think I
> > just didn't build with the right options though and it should be
> > possible.
> >
> > The goal here imho is to allow building with -fno-wrapv
> > -fstrict-overflow safely. Whether we actually do or not is another
> > question but it means we would be able to use new compilers like clang
> > without worrying about finding the equivalent of -fwrapv for them.
>
> Where are we on this?
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2015-10-09 14:32:31 | Re: PATCH: index-only scans with partial indexes |
Previous Message | Peter Eisentraut | 2015-10-09 13:22:01 | Re: proposal: PL/Pythonu - function ereport |