From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-400122-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 115580 invoked by alias); 9 Jun 2015 12:15:59 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 115500 invoked by uid 89); 9 Jun 2015 12:15:58 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: mx2.suse.de
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 09 Jun 2015 12:15:57 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 08D25ADB6;	Tue,  9 Jun 2015 12:15:54 +0000 (UTC)
Date: Tue, 09 Jun 2015 12:22:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Marc Glisse <marc.glisse@inria.fr>
cc: Richard Biener <richard.guenther@gmail.com>,     Marek Polacek <polacek@redhat.com>, Jakub Jelinek <jakub@redhat.com>,     GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Optimize (CST1 << A) == CST2 (PR tree-optimization/66299)
In-Reply-To: <alpine.DEB.2.20.1506091355570.9052@stedding.saclay.inria.fr>
Message-ID: <alpine.LSU.2.11.1506091415170.30088@zhemvz.fhfr.qr>
References: <20150528121545.GE27320@redhat.com> <20150528123436.GM10247@tucnak.redhat.com> <alpine.DEB.2.11.1505282124310.2177@laptop-mg.saclay.inria.fr> <20150608151055.GR2756@redhat.com> <alpine.DEB.2.20.1506081901550.28961@stedding.saclay.inria.fr> <CAFiYyc2vfBzHGHQEkvRujiE2z-brW4J3P0R+TyjQuy44PZj0-A@mail.gmail.com> <alpine.DEB.2.20.1506091305110.9052@stedding.saclay.inria.fr> <alpine.LSU.2.11.1506091347300.30088@zhemvz.fhfr.qr> <alpine.LSU.2.11.1506091348160.30088@zhemvz.fhfr.qr> <alpine.DEB.2.20.1506091355570.9052@stedding.saclay.inria.fr>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2015-06/txt/msg00657.txt.bz2

On Tue, 9 Jun 2015, Marc Glisse wrote:

> On Tue, 9 Jun 2015, Richard Biener wrote:
> 
> > On Tue, 9 Jun 2015, Richard Biener wrote:
> > 
> > > On Tue, 9 Jun 2015, Marc Glisse wrote:
> > > 
> > > > On Tue, 9 Jun 2015, Richard Biener wrote:
> > > > 
> > > > > > Tweaking it so that (6<<X)==0 becomes X>=31 for TYPE_OVERFLOW_WRAPS
> > > > > > and
> > > > > > false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
> > > > > 
> > > > > Hm, yes.  I think signed overflow != shift amount overflow, so testing
> > > > > the
> > > > > overflow macros for this isn't valid.
> > > > 
> > > > Would it be ok to always turn it to X>=31 then? (the value 31 is
> > > > conveniently
> > > > already computed in 'cand')
> > > 
> > > I think so.
> > 
> > Or even ((unsigned)X - 31) < 1 (I probably got that wrong) to properly
> > say X>=29 && X<32, that is, preserve the implicit upper bound on X
> > we have because it is used in a shift.
> 
> I don't understand in what sense this preserves the upper bound. I would
> understand storing a range for X (when it is an SSA_NAME, and it would require
> a lot of care not to propagate backwards too far), or more simply introducing
> if(X>=32) __builtin_unreachable();. But you seem to be talking about
> generating more complicated code so that if someone checks (6<<123)==0 it
> returns false?

Well, I'm mixing simplifying the computation and preserving extra
info we got from the complex computation.  So yes, you are right.

Richard.