From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id EA9B93858D37 for ; Thu, 29 Sep 2022 09:37:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA9B93858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 44CC51477; Thu, 29 Sep 2022 02:37:23 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C109D3F73B; Thu, 29 Sep 2022 02:37:15 -0700 (PDT) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,Tamar Christina , Richard Biener , "gcc-patches\@gcc.gnu.org" , nd , richard.sandiford@arm.com Cc: Tamar Christina , Richard Biener , "gcc-patches\@gcc.gnu.org" , nd Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend References: <057c8b16-50a4-61cb-1801-759d1ae19021@gmail.com> Date: Thu, 29 Sep 2022 10:37:14 +0100 In-Reply-To: <057c8b16-50a4-61cb-1801-759d1ae19021@gmail.com> (Jeff Law's message of "Wed, 28 Sep 2022 11:23:32 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-40.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jeff Law writes: > On 9/28/22 09:04, Richard Sandiford wrote: >> Tamar Christina writes: >>>> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. >>> But then I'd still need to change the expansion code. I suppose this co= uld >>> prevent the issue with changes to code on other targets. >>> >>>>>> We have undocumented addcc, negcc, etc. patterns, should we have aan= dcc >>> pattern for this indicating support for andcc + jump as opposedto cmpcc= + jump? >>>>> This could work yeah. I didn't know these existed. >>>> Ah, so they are conditional add, not add setting CC, so andcc wouldn't >>>> be appropriate. >>>> So I'm not sure how we'd handle such situation - maybe looking at >>>> REG_DECL and recognizing a _Bool PARM_DECL is OK? >>> I have a slight suspicion that Richard Sandiford would likely reject th= is >>> though.. >> Good guess :-P We shouldn't rely on something like that for correctness. >> >> Would it help if we promoted the test-and-branch instructions to optabs, >> alongside cbranch? The jump expanders could then target it directly. >> >> IMO that'd be a reasonable thing to do if it does help. It's a relative= ly >> common operation, especially on CISCy targets. > > But don't we represent these single bit tests using zero_extract as the=20 > condition of the branch?=C2=A0 I guess if we can generate them directly=20 > rather than waiting for combine to deduce that we're dealing with a=20 > single bit test and constructing the zero_extract form would be an=20 > improvement and might help aarch at the same time. Do you mean that the promote_mode stuff should use ext(z)v rather than zero_extend to promote a bool, where available? If so, I agree that might help. But it sounds like it would have downsides too. Currently a bool memory can be zero-extended on the fly using a load, but if we used the zero_extract form instead, we'd have to extract the bit after the load. And (as an alternative) choosing different behaviour based on whether expand sees a REG or a MEM sounds like it could still cause problems, since REGs could be replaced by MEMs (or vice versa) later in the RTL passes. ISTM that the original patch was inserting an extra operation in the branch expansion in order to target a specific instruction. Targeting the instruction in expand seems good, but IMO we should do it directly, based on knowledge of whether the instruction actually exists. Thanks, Richard