From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 52AB33858D28 for ; Thu, 29 Sep 2022 09:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52AB33858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 3238621E53; Thu, 29 Sep 2022 09:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1664444442; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1oPQUOTgGvGGH3fdwxscxQ+TEj1OBMd3mmJrQKVjf1M=; b=Vg5sW5BM1Mf2/jg2PMEr/dJj8SXrqIeoW6ovUQwXPvPpAFkOAJJxTFj3rriW4YerdyK5aq fDpJvpAdHH/Za3JIoPT/Ix8eRPydHOYtGcaTmSpaweJ5D7b2pmOMT81k192RvNPsz6n/tl WS/MqSlJzBo7fMoGKHaV3AhR7ZHxnBU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1664444442; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1oPQUOTgGvGGH3fdwxscxQ+TEj1OBMd3mmJrQKVjf1M=; b=wgHeSvLLbsrhfBPvSFXsX19MhmlfcHb2uioSLBSNG+Vkq1sflDH2q35+gaGxCODrpRsosE odbg9o970vvE4HCQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 2638E2C146; Thu, 29 Sep 2022 09:40:42 +0000 (UTC) Date: Thu, 29 Sep 2022 09:40:42 +0000 (UTC) From: Richard Biener To: Richard Sandiford cc: Jeff Law , Tamar Christina , "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 In-Reply-To: Message-ID: References: <057c8b16-50a4-61cb-1801-759d1ae19021@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609957120-519533707-1664444442=:6652" X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-519533707-1664444442=:6652 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 29 Sep 2022, Richard Sandiford wrote: > 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 could > >>> prevent the issue with changes to code on other targets. > >>> > >>>>>> We have undocumented addcc, negcc, etc. patterns, should we have aandcc > >>> 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 this > >>> 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 relatively > >> common operation, especially on CISCy targets. > > > > But don't we represent these single bit tests using zero_extract as the > > condition of the branch?  I guess if we can generate them directly > > rather than waiting for combine to deduce that we're dealing with a > > single bit test and constructing the zero_extract form would be an > > 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. Yes, I think a compare-and-branch pattern is the best fit here. Note on GIMPLE we'd rely on the fact this is a BOOLEAN_TYPE (so even 8 bit precision bools only have 1 and 0 as meaningful values). So the 'compare-' bit in compare-and-branch would be interpreting a BOOLEAN_TYPE, not so much a general compare. Richard. ---1609957120-519533707-1664444442=:6652--