From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27097 invoked by alias); 7 Aug 2014 08:09:43 -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 27086 invoked by uid 89); 7 Aug 2014 08:09:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f41.google.com Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 07 Aug 2014 08:09:41 +0000 Received: by mail-wg0-f41.google.com with SMTP id z12so3767856wgg.12 for ; Thu, 07 Aug 2014 01:09:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.122.73 with SMTP id lq9mr1384154wjb.133.1407398978554; Thu, 07 Aug 2014 01:09:38 -0700 (PDT) Received: by 10.194.20.69 with HTTP; Thu, 7 Aug 2014 01:09:38 -0700 (PDT) In-Reply-To: <53E30D9C.50701@linaro.org> References: <53BA4458.30804@linaro.org> <53BFD000.1030909@linaro.org> <53C34734.2080103@linaro.org> <53DB1CE2.3080401@linaro.org> <53DBBA6B.3070507@linaro.org> <20140805142142.GW7393@tucnak.redhat.com> <53E22BEA.7070801@linaro.org> <53E30D9C.50701@linaro.org> Date: Thu, 07 Aug 2014 08:09:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Enable elimination of zext/sext From: Richard Biener To: Kugan Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00769.txt.bz2 On Thu, Aug 7, 2014 at 7:24 AM, Kugan wrote: > On 06/08/14 23:29, Richard Biener wrote: >> On Wed, Aug 6, 2014 at 3:21 PM, Kugan wrote: >>> On 06/08/14 22:09, Richard Biener wrote: >>>> On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote: >>>>> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote: >>>>>> what's the semantic of setting SRP_SIGNED_AND_UNSIGNED >>>>>> on the subreg? That is, for the created (subreg:lhs_mode >>>>>> (reg: N))? >>>>> >>>>> SRP_SIGNED_AND_UNSIGNED on a subreg should mean that >>>>> the subreg is both zero and sign extended, which means >>>>> that the topmost bit of the narrower mode is known to be zero, >>>>> and all bits above it in the wider mode are known to be zero too. >>>>> SRP_SIGNED means that the topmost bit of the narrower mode is >>>>> either 0 or 1 and depending on that the above wider mode bits >>>>> are either all 0 or all 1. >>>>> SRP_UNSIGNED means that regardless of the topmost bit value, >>>>> all above wider mode bits are 0. >>>> >>>> Ok, then from the context of the patch we already know that >>>> either SRP_UNSIGNED or SRP_SIGNED is true which means >>>> that the value is sign- or zero-extended. >>>> >>>> I suppose inside promoted_for_type_p >>>> TYPE_MODE (TREE_TYPE (ssa)) == lhs_mode, I'm not sure >>>> why you pass !unsignedp as lhs_uns. >>> >>> In expand_expr_real_1, it is already known that it is promoted for >>> unsigned_p and we are setting SUBREG_PROMOTED_SET (temp, unsignedp). >>> >>> If we can prove that it is also promoted for !unsignedp, we can set >>> SUBREG_PROMOTED_SET (temp, SRP_SIGNED_AND_UNSIGNED). >>> >>> promoted_for_type_p should prove this based on the value range info. >>> >>>> >>>> Now, from 'ssa' alone we can't tell anything about a larger mode >>>> registers value if that is either zero- or sign-extended. But we >>>> know that those bits are properly zero-extended if unsignedp >>>> and properly sign-extended if !unsignedp? >>>> >>>> So what the predicate tries to prove is that sign- and zero-extending >>>> results in the same larger-mode value. This is true if the >>>> MSB of the smaller mode is not set. >>>> >>>> Let's assume that smaller mode is that of 'ssa' then the test >>>> is just >>>> >>>> return (!tree_int_cst_sign_bit (min) && !tree_int_cst_sign_bit (max)); >>>> >>>> no? >>> >>> hmm, is this because we will never have a call to promoted_for_type_p >>> with same sign (ignoring PROMOTE_MODE) for 'ssa' and the larger mode. >>> The case with larger mode signed and 'ssa' unsigned will not work. >>> Therefore larger mode unsigned and 'ssa' signed will be the only case >>> that we should consider. >>> >>> However, with PROMOTE_MODE, isnt that we will miss some cases with this. >> >> No, PROMOTE_MODE will still either sign- or zero-extend. If either >> results in zeros in the upper bits then PROMOTE_MODE doesn't matter. >> > > Thanks for the explanation. Please find the attached patch that > implements this. I have updated the comments and predicate to match this. > > Bootstrap tested on x86_64-unknown-linux-gnu and regression tested on > x86_64-unknown-linux-gnu and arm-none-linux-gnueabi with no new > regressions. Is this OK? Ok with changing + || (TYPE_PRECISION (TREE_TYPE (ssa)) > GET_MODE_PRECISION (mode))) + return false; to check with != (does that even happen?) Thanks, Richard. > Thanks, > Kugan > > gcc/ > 2014-08-07 Kugan Vivekanandarajah > > * calls.c (precompute_arguments): Check > promoted_for_signed_and_unsigned_p and set the promoted mode. > (promoted_for_signed_and_unsigned_p): New function. > (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p > and set the promoted mode. > * expr.h (promoted_for_signed_and_unsigned_p): New function definition. > * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if > SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED. > > > gcc/testsuite > 2014-08-07 Kugan Vivekanandarajah > > * gcc.dg/zero_sign_ext_test.c: New test. > >