From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101932 invoked by alias); 9 Jun 2015 12:05:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 101873 invoked by uid 89); 9 Jun 2015 12:05:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 09 Jun 2015 12:05:51 +0000 Received: from stedding.saclay.inria.fr (HELO stedding) ([193.55.250.194]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 Jun 2015 14:05:30 +0200 Received: from glisse (helo=localhost) by stedding with local-esmtp (Exim 4.85) (envelope-from ) id 1Z2IHa-0004lR-KX; Tue, 09 Jun 2015 14:05:30 +0200 Date: Tue, 09 Jun 2015 12:13:00 -0000 From: Marc Glisse To: Richard Biener cc: Richard Biener , Marek Polacek , Jakub Jelinek , GCC Patches Subject: Re: [PATCH] Optimize (CST1 << A) == CST2 (PR tree-optimization/66299) In-Reply-To: Message-ID: References: <20150528121545.GE27320@redhat.com> <20150528123436.GM10247@tucnak.redhat.com> <20150608151055.GR2756@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2015-06/txt/msg00655.txt.bz2 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<=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? -- Marc Glisse