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 3FBEC3858C74 for ; Thu, 29 Sep 2022 11:09:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3FBEC3858C74 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 imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 4980721C15; Thu, 29 Sep 2022 11:09:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1664449768; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/N2FipobCUhgYGv2HbzQKElAMEhrlo8+whtSFvhcQ1s=; b=rLDDNy31n/zjyOztAJv11RXurqAF1+qtbtmgvQdZg3I7emrB1hy2VjFGiYDNU4cAFtBlCk coE9cS+Y96LZh4Wd95WV7sbH7QcHbdcq3Y++CE1uU/bnt5y8ATFcqRud+8GW2zJ+2rKHxR I1Z2gjpW1hT50IlGkwyJkG46c/GB3Iw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1664449768; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/N2FipobCUhgYGv2HbzQKElAMEhrlo8+whtSFvhcQ1s=; b=BSQjPhqPXryB+LSaVlwI2CJpDwXlIaTU9wHhgUd324q2Vy0NqTKx+qA+G+ieWswLPqS/2s 31Ev+q50DJ3ckcCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 34D221348E; Thu, 29 Sep 2022 11:09:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id OvfWDOh8NWPaZQAAMHmgww (envelope-from ); Thu, 29 Sep 2022 11:09:28 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend Date: Thu, 29 Sep 2022 13:09:27 +0200 Message-Id: <8873DC9F-F868-458D-9AD6-90DDC5465057@suse.de> References: Cc: Richard Sandiford , nd In-Reply-To: To: Tamar Christina via Gcc-patches X-Mailer: iPhone Mail (19H12) X-Spam-Status: No, score=-5.9 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: > Am 29.09.2022 um 12:23 schrieb Tamar Christina via Gcc-patches : >=20 > =EF=BB=BF >>=20 >> -----Original Message----- >> From: Richard Biener >> Sent: Thursday, September 29, 2022 10:41 AM >> 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 >>=20 >>> On Thu, 29 Sep 2022, Richard Sandiford wrote: >>>=20 >>> 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. >>>>>>=20 >>>>>>>>> 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. >>>>>=20 >>>>> Would it help if we promoted the test-and-branch instructions to >>>>> optabs, alongside cbranch? The jump expanders could then target it >> directly. >>>>>=20 >>>>> IMO that'd be a reasonable thing to do if it does help. It's a >>>>> relatively common operation, especially on CISCy targets. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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.= >>=20 >> 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 precis= ion >> 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. >=20 > Oh, I was thinking of adding a constant argument representing the precisio= n that > is relevant for the compare in order to make this a bit more general/futur= e proof. >=20 > Are you thinking I should instead just make the optab implicitly only work= for 1-bit > precision comparisons? What=E2=80=99s the optab you propose (cite also the documentation part)? >=20 > Thanks, > Tamar >=20 >>=20 >> Richard.