From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id 5223A3858D1E for ; Sun, 1 Jan 2023 23:00:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bWcIVFrTNzxj+Cb9BWcJeEN23pwKjJEAohlfqubx2vE=; b=IHwm7Mga8xNJKUSZ/tArjNzHRV MRGe/soArqaZ8UPYwxKf9raO+C4UaCCgNpbSptFxbWqc9/cXW8CBg65JYU+ON/h0RLOG1CDcbLNVb UZdrG06Q2JTPR/1ZczHg+IlMltaE3+SpFXRZHrrf8xs7cN3Y2yJ9kGZv2E5geQ59ebww+Jo6VnC9t iVHfSLNa0MCzoxQVBuMsOheaxuiuHwK+QuJALcD7o4OQUtjaJqsNA/tjZeAWmcH4g2HTPj97FnzMR VY8KcellsWy8RH6KVvPolLDz7Xazqfx5pSw/TD20CWLre5jCwevSoeVL8WAWa8YTwg+Fh2J3iFp5p UF92pvHw==; Received: from host86-163-35-31.range86-163.btcentralplus.com ([86.163.35.31]:52360 helo=smtpclient.apple) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pC7JC-0001ui-Na; Sun, 01 Jan 2023 18:00:02 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY. From: "roger@nextmovesoftware.com" In-Reply-To: <20230101210302.GF25951@gate.crashing.org> Date: Sun, 1 Jan 2023 22:59:49 +0000 Cc: GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: <614C09C0-C652-4352-AE07-76625FE13C9E@nextmovesoftware.com> References: <002e01d91df9$79df2670$6d9d7350$@nextmovesoftware.com> <20230101210302.GF25951@gate.crashing.org> To: Segher Boessenkool X-Mailer: Apple Mail (2.3731.300.101.1.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: The motivation for the current design (requiring the result and the = operand to have the same mode) was from PR middle-end/50161. The challenge there is = that when the RTL optimizers can determine that the operand is a constant, = simplify_rtx sees just a CONST_INT with VOIDmode and therefore doesn't know what the = original/intended mode of the operation is/should be. Using patterns with explicit truncates, sign or zero extensions avoids = these problems, but still allows backend insns where the result mode differs from the = operand mode. > On 1 Jan 2023, at 21:03, Segher Boessenkool = wrote: > On Sun, Jan 01, 2023 at 03:55:26PM -0000, Roger Sayle wrote: >> In 2011, the rtl.texi documentation was updated to reflect that the >> modes of the RTX unary operations FFS, POPCOUNT and PARITY must >> match those of their operands. >=20 > Is that not a limitation we should try to get rid of? It does not > really make any sense after all. >=20 >> Unfortunately, some of the transformations >> in simplify-rtx.cc predate this tightening of RTL semantics, and have >> not (until now) been updated/fixed. i.e. The POPCOUNT and PARITY >> optimizations were "correct" when I originally added them back in = 2007. >=20 > What would be needed to fix this the "other" way? Just update the > documentation? Or is there some code that requires this strange > constraint, maybe even some checking thing? >=20 > If we *do* want this strange limitation, we really should have some = RTL > check that enforces it, makes sure we find it if the rules are broken. >=20 > Segher