From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32756 invoked by alias); 23 May 2017 14:42:22 -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 32178 invoked by uid 89); 23 May 2017 14:42:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2075 X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 May 2017 14:42:18 +0000 Received: by mail-wm0-f50.google.com with SMTP id b84so27560352wmh.0 for ; Tue, 23 May 2017 07:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=cUYAV0Z613rIdG86ZnNqvlS6Vs9jDMOeyQNl/3X4jz4=; b=mL1BB38vcjrYQvEvFL9A6vV13ZTGCWnoEgq8RnxmGJeQlHG1ZBcPSPZfzy7MgQ58Ge 1Mg4dr5bOUYf+iLFCGmWBfwnrQehxY0tOnYqgf4ChUFkc7bvGVdZOVB/HVygC7lbPwx+ 7AGdCXxqWD6v+sidEWpqYNmLlxS0jaBRwH2rZeyyVPDgmcIlv4KtGk3kQnwCm7Gc/RVc N69GtFtemSqiFoZ1/jcYVmTQ5h3kk1fgyCNU5BAnv4/64O4dCwpsDgjQnGjvf2Q3Tgrv P/Cun6mcbGRMaMWJU1j1HgknxdcLgM4qsZGZC3CK7bAcFKdbMJBqEPLOM3jMmguyQGL9 3c7A== X-Gm-Message-State: AODbwcAq1P2cJcb5HjTaBKF8HGmqBX2fjDClKW7A3BNjJTyZltYVWdey zqJQnkp9KIbMaGQRvpgOIg== X-Received: by 10.223.164.81 with SMTP id e17mr14994944wra.133.1495550540178; Tue, 23 May 2017 07:42:20 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id 4sm1520654wrv.33.2017.05.23.07.42.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 May 2017 07:42:19 -0700 (PDT) From: Richard Sandiford To: Bin Cheng Mail-Followup-To: Bin Cheng ,"gcc-patches\@gcc.gnu.org" , nd , richard.sandiford@linaro.org Cc: "gcc-patches\@gcc.gnu.org" , nd Subject: Re: [PATCH GCC]Check tieable TRUNCATE only if inner rtx is register References: Date: Tue, 23 May 2017 14:54:00 -0000 In-Reply-To: (Bin Cheng's message of "Fri, 19 May 2017 15:59:44 +0000") Message-ID: <878tln1vp1.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-05/txt/msg01763.txt.bz2 Bin Cheng writes: > Hi, > Revision 247881 possibly exposes bug in RTL or ARM backend, while the > change itself > may be incomplete too. Given a TRUNCATE rtx with complicated sub-rtx, > backend may > want to know the complicated sub-rtx happens in context of TRUNCATE in > order to give > different costs. This patch adds restriction only checking tieable > TRUNCATE if its operand > is register. This is enough for middle-end, it builds up (truncate:SI > (reg:DI)) in order to setup > conversion cost for GIMPLE optimizations. On the other hand, targets > like i386/arm don't > handle register truncation at the moment. > > Note, this patch minimize the impact of cost change and workaround > PR80754 for now. > So far the effect of change in r247881 is to allow smulsi3_highpart_v6 > pattern to be used > rather than smullsidi, which means it actually gives RA more free in > choosing registers. > If it's because of the cost change that smulsi3_highpart_v6 is now > preferred, it could be > suggesting that r247881 is good. Anyway, it's just my guess before > looking into rtl passes. > > Bootstrap and test ongoing. Is it OK? > > 2017-05-13 Bin Cheng > > * rtlanal.c (rtx_cost): Check tieable TRUNCATE only if inner rtx > is register. > > diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c > index d9f57c3..b211efb 100644 > --- a/gcc/rtlanal.c > +++ b/gcc/rtlanal.c > @@ -4165,7 +4165,10 @@ rtx_cost (rtx x, machine_mode mode, enum rtx_code outer_code, > break; > > case TRUNCATE: > - if (MODES_TIEABLE_P (mode, GET_MODE (XEXP (x, 0)))) > + /* If inner rtx isn't register, fall through and call target hook. > + Backend may want to know that sub-rtx is in truncate. */ > + if (REG_P (XEXP (x, 0)) > + && MODES_TIEABLE_P (mode, GET_MODE (XEXP (x, 0)))) > { > total = 0; > break; Even for !REG_P (i.e. even when you still call the hook), 0 seems like a better default to pass than COSTS_N_INSNS (1). Would it be worth guarding just the break with REG_P? Thanks, Richard