Re: [RFC] overflow checks optimized away

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 +

In response to

Responses

Browse pgsql-hackers by date

  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