From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46563 invoked by alias); 21 Aug 2017 18:06:01 -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 46547 invoked by uid 89); 21 Aug 2017 18:06:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=kenner, Kenner, Hx-languages-length:1996 X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Aug 2017 18:05:59 +0000 Received: by mail-wr0-f176.google.com with SMTP id 30so33148305wrk.0 for ; Mon, 21 Aug 2017 11:05:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=ZYmzeSsqTGjV+/m3eD5RK1nBPsCC2RBl2+NS3eCipaU=; b=fH+aQu4xfF7BZuTOr7mRXaMViUvKb256kUzRWdPU/waVx797pL94NMZpPyvyFlrwUO rihrnU88po72KcQ0n6p3AafgkDgcfPTG5Fbutg8RzRxIuocEC3rR+LaALiufCqslbg3P Z1RLNJB7kZH6DssoyoqSHMu6ePVVGc96JNOvijMZEiF/GvtAZUmw/DC++tOTT939b30u /QcIRR9k3tb/q/Z6ll2q6ihZZ8YdqZXAm8hRpsHej/ZNKhIc0/aNNqEd5Gmfq/bwm2mf PornW2nnSS9gT6jBKCiU0yg6wz2Xa/8pxLOql1Qgh9ryFhSzoAMyrCo4Z1wA/HzBRLqn RqCw== X-Gm-Message-State: AHYfb5j56G5L3g0eYnS/KFC8LxsxFfAYs4wZjYW2MJkgzB9sqYQ8g4pG 96L8R6Qvzq2WKg== X-Received: by 10.223.178.2 with SMTP id u2mr12718143wra.150.1503338757491; Mon, 21 Aug 2017 11:05:57 -0700 (PDT) Received: from android-f83b394395796e13.fritz.box (p5494E583.dip0.t-ipconnect.de. [84.148.229.131]) by smtp.gmail.com with ESMTPSA id v185sm10269872wmd.25.2017.08.21.11.05.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Aug 2017 11:05:56 -0700 (PDT) Date: Mon, 21 Aug 2017 19:14:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <87valgddb2.fsf@linaro.org> References: <20170807210159.86DD633CA8@vlsi1.gnat.com> <20170808015616.1386833CA8@vlsi1.gnat.com> <20170808121311.5B7D033CAD@vlsi1.gnat.com> <20170808195158.352B333ED7@vlsi1.gnat.com> <20170808200402.3B4BE33EE9@vlsi1.gnat.com> <20170808202024.8AC9533F0E@vlsi1.gnat.com> <87valgddb2.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] [Aarch64] Optimize subtract in shift counts To: Richard Sandiford CC: Richard Kenner ,Michael.Collison@arm.com,GCC Patches ,nd@arm.com,Andrew Pinski From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01224.txt.bz2 On August 21, 2017 7:46:09 PM GMT+02:00, Richard Sandiford wrote: >Richard Biener writes: >> On Tue, Aug 8, 2017 at 10:20 PM, Richard Kenner >> wrote: >>>> Correct. It is truncated for integer shift, but not simd shift >>>> instructions. We generate a pattern in the split that only >generates >>>> the integer shift instructions. >>> >>> That's unfortunate, because it would be nice to do this in >simplify_rtx, >>> since it's machine-independent, but that has to be conditioned on >>> SHIFT_COUNT_TRUNCATED, so you wouldn't get the benefit of it. >> >> SHIFT_COUNT_TRUNCATED should go ... you should express this in >> the patterns, like for example with >> >> (define_insn ashlSI3 >> [(set (match_operand 0 "") >> (ashl:SI (match_operand ... ) >> (subreg:QI (match_operand:SI ...)))] >> >> or an explicit and:SI and combine / simplify_rtx should apply the >magic >> optimization we expect. > >The problem with the explicit AND is that you'd end up with either >an AND of two constants for constant shifts, or with two separate >patterns, >one for constant shifts and one for variable shifts. (And the problem >in >theory with two patterns is that it reduces the RA's freedom, although >in >practice I guess we'd always want a constant shift where possible for >cost reasons, and so the RA would never need to replace pseudos with >constants itself.) > >I think all useful instances of this optimisation will be exposed by >the gimple optimisers, so maybe expand could to do it based on >TARGET_SHIFT_TRUNCATION_MASK? That describes the optab rather than >the rtx code and it does take the mode into account. Sure, that could work as well and also take into account range info. But we= 'd then need named expanders and the result would still have the explicit a= nd or need to be an unspec or a different RTL operation.=20 Richard.=20 >Thanks, >Richard