From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12484 invoked by alias); 3 Aug 2014 23:56:07 -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 12473 invoked by uid 89); 3 Aug 2014 23:56:06 -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,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f175.google.com Received: from mail-pd0-f175.google.com (HELO mail-pd0-f175.google.com) (209.85.192.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 03 Aug 2014 23:56:05 +0000 Received: by mail-pd0-f175.google.com with SMTP id r10so8537376pdi.6 for ; Sun, 03 Aug 2014 16:56:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bB2iJsXyT4NM+5baoyrk5OabyK2bA2K1UAzHNKknMzA=; b=MWzudQspnXOd0/p39Smv3p+KdPzfktcdgEXDYFRpvyVZVto6gzWfmUMJTIB+i2Hg7O nVIjoQT3UUvVV1uKoD7XYdnOpq0sBmc8XRqC3/5BqNM8b4SFZiZEujCTEpGJZrVRM1GZ vjpjxxc0R4+DmwiIzKlXvHllAly1QEZTLfYl2GCJ3Pz/J93KE9cyZarpzi1Gfbm+3J5U hK4ykvZ7jiLeGQRaURPD4ci0A61kD5cc7pk49mU2iN3+jgHbNIOxz4vH+Qo46UNb8MDt zjIRg6tqvUXFftSqt1D8D33rgAT4v2vgmDYsL9hbEKlsU+gCWwdDUVIVOo5zRe/8JjTZ 2WKg== X-Gm-Message-State: ALoCoQmryxU4XnbWmfRE22rJohdVpmmQ2Hbt8WleOmX0NBt775b4iEZZ3xX0W429nKbZBzdXkACo X-Received: by 10.66.66.133 with SMTP id f5mr4995447pat.81.1407110163603; Sun, 03 Aug 2014 16:56:03 -0700 (PDT) Received: from [10.1.1.8] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by mx.google.com with ESMTPSA id f12sm18823881pat.19.2014.08.03.16.56.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Aug 2014 16:56:02 -0700 (PDT) Message-ID: <53DECC0F.2020505@linaro.org> Date: Sun, 03 Aug 2014 23:56:00 -0000 From: Kugan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Richard Biener CC: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 2/2] Enable elimination of zext/sext References: <53A9658F.2070304@linaro.org> <53A966BF.30806@linaro.org> <20140624122101.GX31640@tucnak.redhat.com> <53AA8501.809@linaro.org> <20140625083618.GZ31640@tucnak.redhat.com> <53BA4458.30804@linaro.org> <53BFD000.1030909@linaro.org> <53C34734.2080103@linaro.org> <53DB1CE2.3080401@linaro.org> <53DBBA6B.3070507@linaro.org> In-Reply-To: <53DBBA6B.3070507@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00192.txt.bz2 On 02/08/14 02:03, Kugan wrote: >>>> if (rhs_uns) >>>> return wi::ge_p (min, 0); // if min >= 0 then range contains positive values >>>> else >>>> return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE >>>> (ssa)), SIGNED); // if max <= signed-max-of-type then range doesn't >>>> need sign-extension >>> >>> I think we will have to check that ssa has necessary sign/zero extension >>> when assigned to lhs_type. If PROMOTE_MODE tells us that ssa's type will >>> be interpreted differently, the value range of ssa also will have >>> corresponding range. In this cases, shouldn’t we have to check for >>> upper and lower limit for both min and max? >> >> Hmm? That's exactly what the check is testing... we know that >> min <= max thus if min >= 0 then max >= 0. >> >> zero_extension will never do anything on [0, INF] >> >> If max < MAX-SIGNED then sign-extension will not do anything. Ok, >> sign-extension will do sth for negative values still. So rather >> >> if (rhs_uns) >> return wi::geu_p (min, 0); >> else >> return wi::ges_p (min, 0) && wi::les_p (max, wi::max_value >> (TYPE_PRECISION (TREE_TYPE (ssa)), SIGNED)); >> >> ? Looking at your comments again, I think we have to consider three things here. To be able assign to LHS (of lhs_uns and lhs_mode) without conversion of RHS (tree SSA) * If we ignore the mode changes (i.e. LHS_mode can be different in terms of precision) and ignore PROMOTE_MODE and consider only the sign of LHS and RHS if (lhs_uns) return wi::ge_p (min, 0, rhs_signop); // if min >= 0 then range contains positive values else if (rhs_uns) // if max <= signed-max-of-type then range doesn't need sign-extension return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE (ssa)), SIGNED); else return true; * However, if we consider the PROMOTE_MODE might change the RHS sign if (lhs_uns) { return wi::ge_p (min, 0, rhs_signop); } else { signed_max = wide_int::from (TYPE_MAX_VALUE (lhs_type), TYPE_PRECISION (TREE_TYPE (ssa)), rhs_signop); if (rhs_uns) /* If PROMOTE_MODE changed an RHS signed to unsigned and SSA contains negative value range, we still have to do sign-extend. */ return wi::ge_p (min, 0, TYPE_SIGN (TREE_TYPE (ssa))) && wi::le_p (max, signed_max, rhs_signop); else /* If PROMOTE_MODE changed an RHS unsigned to signed and SSA contains value range more than signed-max-of-type, we still have to do sign-extend. */ return wi::le_p (max, signed_max, TYPE_SIGN (TREE_TYPE (ssa))); } * If we also consider that LHS mode and RHS mode precision can be different if (lhs_uns) { unsigned_max = wide_int::from (TYPE_MAX_VALUE (lhs_type), TYPE_PRECISION (TREE_TYPE (ssa)), rhs_signop); /* If min >= 0 then range contains positive values and doesnt need zero-extension. If max <= unsigned-max-of-type, then value fits type. */ return wi::ge_p (min, 0, rhs_signop) && wi::le_p (max, unsigned_max, rhs_signop); } else { signed_max = wide_int::from (TYPE_MAX_VALUE (lhs_type), TYPE_PRECISION (TREE_TYPE (ssa)), rhs_signop); signed_min = wide_int::from (TYPE_MIN_VALUE (lhs_type), TYPE_PRECISION (TREE_TYPE (ssa)), rhs_signop); if (rhs_uns) /* If PROMOTE_MODE changed an RHS signed to unsigned and SSA contains negative value range, we still have to do sign-extend. */ return wi::ge_p (min, 0, TYPE_SIGN (TREE_TYPE (ssa))) && wi::le_p (max, signed_max, rhs_signop); else /* If PROMOTE_MODE changed an RHS unsigned to signed and SSA contains value range more than signed-max-of-type, we still have to do sign-extend. */ return wi::le_p (max, signed_max, TYPE_SIGN (TREE_TYPE (ssa))) && wi::ge_p (min, signed_min, rhs_signop); } } Since we can have PROMOTE_MODE changing the sign and LHS mode and RHS mode precision can be different, the check should be the third one. Does that make sense or am I still missing it? Thanks again for your time, Kugan