From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41021 invoked by alias); 6 Sep 2017 09:11:57 -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 40995 invoked by uid 89); 6 Sep 2017 09:11:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=honour, ras X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-ve1eur01on0064.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (104.47.1.64) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Sep 2017 09:11:54 +0000 Received: from HE1PR0802MB2377.eurprd08.prod.outlook.com (10.172.129.19) by HE1PR0802MB2459.eurprd08.prod.outlook.com (10.175.34.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 6 Sep 2017 09:11:49 +0000 Received: from HE1PR0802MB2377.eurprd08.prod.outlook.com ([fe80::a8c2:e391:2b5c:1d5a]) by HE1PR0802MB2377.eurprd08.prod.outlook.com ([fe80::a8c2:e391:2b5c:1d5a%17]) with mapi id 15.20.0013.018; Wed, 6 Sep 2017 09:11:49 +0000 From: Michael Collison To: Richard Sandiford , Richard Biener CC: Richard Kenner , GCC Patches , nd , Andrew Pinski Subject: RE: [PATCH] [Aarch64] Optimize subtract in shift counts Date: Wed, 06 Sep 2017 09:11:00 -0000 Message-ID: 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> <87r2w4cb6w.fsf@linaro.org> <87mv6sc98y.fsf@linaro.org> In-Reply-To: <87mv6sc98y.fsf@linaro.org> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Collison@arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;HE1PR0802MB2459;6:zCxjl7VXRJgDzEfUt7FOqPMp9yTKvVxJV9jX0Pw44s6jNeOz4pR9mmCKgFUFqrljQ9TxbdbMgfmpHNbxCD2czg+IP8HkBKJtnlLAr/A8qdOqbC0Rq6bD5zSUbK2ZpjZe4Tw8Q6wmaittF+gaRHEyBh/tCSQ9JwjYVnh9PkyuqlyGg0RVd7cy0zpbI6VoE65hs3mQuvQt3QLlk0rBL51oH8Ka3HyhHD+Ii1Lojo6F672jUjKQdUFTZG4UEaYXZyq3vPd8duS6QYmMNSBMc7GUMU3ia9wKwOi6AKOeEFcmmpRZPnVgyV1B9JfZn6whV3BtxOjI+fzdijADvfTzATE9+g==;5:IubD/GM7jvkHAgzjqGpixHr9iaSyP5q2RW8EZQn4GusHqRaSECGbiLVV07HekrCVCZDKNyDV3gvvHdCZsrqH3TcYpkvDA4mYBPpmAjxsrgdG7ntKU7PRKZlM3lxIeBNuw2GqKVP3OFZY8uy7ouddlw==;24:P6UhOsrSnvhjKo1jenviThdJoz2vx5W4IIE/sHRQoUnkgqt/mroP4TSEO0wVfaD4Fwsxql9qZ24VdaMxVaAK/g0d10W9+LHiodF5ldRQ+PQ=;7:FKi6sGyJ+3SohJOKX24uWhmtVJzHJvDsEAvn+XbE682txqdFgzGe1E0eFG5f1JRguJfwtb9fbZF1+tZdgvtQEGVaeesDVvUFu3J3QD3kl4Gofb6wwhnnP16KDetvzxV+SXENMMJTVUTH8gj0xM2VLdn2KUYm0mc9D8TGnwjA7Z4vJd8b96DYa+O/VtjJHLMta4loguYfB1GeTifrjjzXy5xJfc2cUrRz6VyxnEBPKKY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: adc725e3-81fc-4a73-608f-08d4f5074ea5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:HE1PR0802MB2459; x-ms-traffictypediagnostic: HE1PR0802MB2459: nodisclaimer: True x-exchange-antispam-report-test: UriScan:(180628864354917)(244540007438412)(22074186197030)(788757137089)(183786458502308); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:HE1PR0802MB2459;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:HE1PR0802MB2459; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(189002)(377454003)(13464003)(24454002)(199003)(2906002)(105586002)(14454004)(68736007)(106356001)(5660300001)(7696004)(74316002)(2950100002)(86362001)(189998001)(305945005)(2900100001)(3846002)(39060400002)(53936002)(55016002)(4326008)(7736002)(3660700001)(97736004)(229853002)(6506006)(478600001)(50986999)(66066001)(54906002)(6116002)(99286003)(102836003)(6246003)(3280700002)(6436002)(33656002)(72206003)(76176999)(9686003)(5250100002)(8936002)(81166006)(54356999)(101416001)(53546010)(81156014)(25786009)(8676002)(93886005);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0802MB2459;H:HE1PR0802MB2377.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 09:11:49.7557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2459 X-SW-Source: 2017-09/txt/msg00320.txt.bz2 Richard Sandiford do you have any objections to the patch as it stands? It = doesn't appear as if anything is going to change in the mid-end anytime soo= n. -----Original Message----- From: Richard Sandiford [mailto:richard.sandiford@linaro.org]=20 Sent: Tuesday, August 22, 2017 9:11 AM To: Richard Biener Cc: Richard Kenner ; Michael Collison ; GCC Patches ; nd ; = Andrew Pinski Subject: Re: [PATCH] [Aarch64] Optimize subtract in shift counts Richard Biener writes: > On Tue, Aug 22, 2017 at 9:29 AM, Richard Sandiford=20 > wrote: >> Richard Biener writes: >>> On August 21, 2017 7:46:09 PM GMT+02:00, Richard Sandiford=20 >>> wrote: >>>>Richard Biener writes: >>>>> On Tue, Aug 8, 2017 at 10:20 PM, Richard Kenner=20 >>>>> wrote: >>>>>>> Correct. It is truncated for integer shift, but not simd shift=20 >>>>>>> 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=20 >>>>>> SHIFT_COUNT_TRUNCATED, so you wouldn't get the benefit of it. >>>>> >>>>> SHIFT_COUNT_TRUNCATED should go ... you should express this in the=20 >>>>> 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=20 >>>>an AND of two constants for constant shifts, or with two separate=20 >>>>patterns, one for constant shifts and one for variable shifts. (And=20 >>>>the problem in theory with two patterns is that it reduces the RA's=20 >>>>freedom, although in practice I guess we'd always want a constant=20 >>>>shift where possible for cost reasons, and so the RA would never=20 >>>>need to replace pseudos with constants itself.) >>>> >>>>I think all useful instances of this optimisation will be exposed by=20 >>>>the gimple optimisers, so maybe expand could to do it based on=20 >>>>TARGET_SHIFT_TRUNCATION_MASK? That describes the optab rather than=20 >>>>the rtx code and it does take the mode into account. >>> >>> Sure, that could work as well and also take into account range info.=20 >>> But we'd then need named expanders and the result would still have=20 >>> the explicit and or need to be an unspec or a different RTL operation. >> >> Without SHIFT_COUNT_TRUNCATED, out-of-range rtl shifts have=20 >> target-dependent rather than undefined behaviour, so it's OK for a=20 >> target to use shift codes with out-of-range values. > > Hmm, but that means simplify-rtx can't do anything with them because=20 > we need to preserve target dependent behavior. Yeah, it needs to punt. In practice that shouldn't matter much. > I think the RTL IL should be always well-defined and its semantics=20 > shouldn't have any target dependences (ideally, and if, then they=20 > should be well specified via extra target hooks/macros). That would be nice :-) I think the problem has traditionally been that shi= fts can be used in quite a few define_insn patterns besides those for shift= instructions. So if your target defines shifts to have 256-bit precision = (say) then you need to make sure that every define_insn with a shift rtx wi= ll honour that. It's more natural for target guarantees to apply to instructions than to rt= x codes. >> And >> TARGET_SHIFT_TRUNCATION_MASK is a guarantee from the target about how=20 >> the normal shift optabs behave, so I don't think we'd need new optabs=20 >> or new unspecs. >> >> E.g. it already works this way when expanding double-word shifts,=20 >> which IIRC is why TARGET_SHIFT_TRUNCATION_MASK was added. There it's=20 >> possible to use a shorter sequence if you know that the shift optab=20 >> truncates the count, so we can do that even if SHIFT_COUNT_TRUNCATED=20 >> isn't defined. > > I'm somewhat confused by docs saying TARGET_SHIFT_TRUNCATION_MASK=20 > applies to the instructions generated by the named shift patterns but=20 > _not_ general shift RTXen. But the generated pattern contains shift=20 > RTXen and how can we figure whether they were generated by the named=20 > expanders or by other means? Don't define_expand also serve as=20 > define_insn for things like combine? Yeah, you can't (and aren't supposed to try to) reverse-engineer the expand= er from the generated instructions. TARGET_SHIFT_TRUNCATION_MASK should on= ly be used if you're expanding a shift optab. > That said, from looking at the docs and your description above it=20 > seems that semantics are not fully reflected in the RTL instruction strea= m? Yeah, the semantics go from being well-defined in the optab interface to be= ing target-dependent in the rtl stream. Thanks, Richard > > Richard. > >> Thanks, >> Richard >> >>> >>> Richard. >>> >>>>Thanks, >>>>Richard