From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id AB1C63861872 for ; Mon, 13 Feb 2023 18:54:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB1C63861872 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x52a.google.com with SMTP id v3so8748575pgh.4 for ; Mon, 13 Feb 2023 10:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1676314448; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T8Vqrhy7zeO4VErMzH/HNNmDj4ynikjlUz9OS/moQ7g=; b=dmclPOjHW8eiD+f5bCuaeZkly65HwJVKdVT6r45nzmDaUXbviuQQN0T2rDDnHl/PPk zhQ4R8ZWwGzZ2pSA3r1SjAdGjBg0Jx4PKwXuvjUakHIJiXxC1HvVDP9hJS0b0J5pAsvS 0neX0wqVeU4kF1L4/TKccFxTZhGWwURBUcLUhQ1UBEKSBIikEzUuJloO9WdCxy9g7Mg7 wOk/gbf2amyrwglH5LbfFfyF1w6ae6nHAy92YcmPAKDBXyg+gXl9B8bXQeHnizrOcyCv 1G2Wnr9aCqA7+axdFkRrFFFbCSj+zg4fAEQ9dMFqyS6wZ8nJhUifAl/C5iTKlMRReEjx X3mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676314448; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T8Vqrhy7zeO4VErMzH/HNNmDj4ynikjlUz9OS/moQ7g=; b=rTNV4jRPwldg9gyeWjXQXCGrm1L+SnM0ZL7ETW3Ne0YIIxTwNtOodQBwH//ww/kBIg Ko6afU3w1Z9VeHryh4K/P83pb7VWPM3E+iGSOiGKUfxYh8ftZ8Qh8e56TVbmcDgh6zWw ec+H2uWKyMqswj6Vg5hX9XtBrYqHd3wyV9XrDhKS2r0dgZbgiqznHcgRqM7jd3W00+w8 iZNWIdZU8wFZgVMEa4kCOaVX94NwXlPm2Tqo5YMxsPQK9NA95pVdwBWZKXyMfy5Q9iwg d3e9uu/X0wQ6ZRPq5Qaxiz9Wl639NQBnxyXnVfeTDuJ5jAj0pAxKKpQ84AsapimOtbgo 5OMg== X-Gm-Message-State: AO0yUKWQ8JxYl2GRF0nE4Hyb1+2LTx2DyBwqrHUBoHrVmuoPlGvusxhB 9Zl5B1zAUA2a75k9+ChAouSo/1M5f7ND30bdHU0= X-Google-Smtp-Source: AK7set+FtiD3N28P85Rm8diYa69hw2+bTt/vEtBspSowezqHqrGvhlVxVBKSGbtyE1TOmpn5ZDDiWk/QrppEltLjEM0= X-Received: by 2002:aa7:94a3:0:b0:5a8:4eef:4db9 with SMTP id a3-20020aa794a3000000b005a84eef4db9mr3392935pfl.22.1676314448510; Mon, 13 Feb 2023 10:54:08 -0800 (PST) MIME-Version: 1.0 References: <20230210224150.2801962-1-philipp.tomsich@vrull.eu> <20230210224150.2801962-9-philipp.tomsich@vrull.eu> In-Reply-To: From: Andrew Pinski Date: Mon, 13 Feb 2023 10:53:54 -0800 Message-ID: Subject: Re: [RFC PATCH v1 08/10] ifcvt: add if-conversion to conditional-zero instructions To: Jeff Law Cc: Andrew Pinski via Gcc-patches , Philipp Tomsich , Kito Cheng , Christoph Muellner , Palmer Dabbelt , Andrew Waterman , Vineet Gupta , richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Mon, Feb 13, 2023 at 10:43 AM Jeff Law wrote: > > > > On 2/13/23 10:32, Richard Sandiford via Gcc-patches wrote: > > Andrew Pinski via Gcc-patches writes: > >> On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich > >> wrote: > >>> > >>> Some architectures, as it the case on RISC-V with the proposed > >>> ZiCondOps and the vendor-defined XVentanaCondOps, define a > >>> conditional-zero instruction that is equivalent to: > >>> - the positive form: rd = (rc != 0) ? rs : 0 > >>> - the negated form: rd = (rc == 0) ? rs : 0 > >>> > >>> While noce_try_store_flag_mask will somewhat work for this case, it > >>> will generate a number of atomic RTX that will misdirect the cost > >>> calculation and may be too long (i.e., 4 RTX and more) to successfully > >>> merge at combine-time. > >> > >> Can you expand on this? Especially when there are patterns that use > >> (if_then_else) already. > >> > >>> > >>> Instead, we add two new transforms that attempt to build up what we > >>> define as the canonical form of a conditional-zero expression: > >>> > >>> (set (match_operand 0 "register_operand" "=r") > >>> (and (neg (eq_or_ne (match_operand 1 "register_operand" "r") > >>> (const_int 0))) > >>> (match_operand 2 "register_operand" "r"))) > >> > >> Again why are you not using: > >> (set (reg) (if_then_else (eq_ne (reg) (const_int 0)) (reg) (const_int 0))) > >> Form instead of the really bad "canonical" form of the above? > > > > I don't think one form is inherently better than the other if we think > > about just this one case. But I agree that the if_then_else form is > > currently the canonical form for the operation, and extends more > > naturally to the general case. AArch64 already matches specifically > > for it (with xzr providing the zero value). > The more I think about it, the more I prefer the if-then-else form. My > biggest hesitation with getting behind one form or the other is a lack > of knowledge about which is likely better interpreted by simplify-rtx > and friends -- though it may not matter much in practice. In the case of IF_THEN_ELSE, combine tries a few things: /* If this is a simple operation applied to an IF_THEN_ELSE, try applying it to the arms of the IF_THEN_ELSE. This often simplifies things. Check for cases where both arms are testing the same condition. Also see simplify_if_then_else inside combine.cc. I don't think the first one could be done not using IF_THEN_ELSE. Thanks, Andrew Pinski > > Jeff