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 19F7A3858D32 for ; Mon, 2 Jan 2023 17:31:03 +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=Fljb65k6NnZTw8Blb9ImwMTDXxWqJarExBtVzozT28U=; b=d0y0i2ortcKRKHvueW1dFWlYDv Z0lzPKjn7M6vt37c4n8oFaFOQfJn5DVlV+nIHh7azk2z2jyvzLdG/hQxcu3J+vc4yp5X7DrTNN8kB MCft0ZjEkZSFJWygntl/sQKa9C09/T0JG1guqZaFD4m3Fne5UjhbCO3djVgHQl5KtkgBwI1J0pmOw W8rpv28FB6btUZD8d2eRXJt8Z8un15evCwXl+voseq4vt8W+N8nD2XhlnDEnrQnr78o1J5VzlvwmV yq4I5nvy6THbyEcdfvI5wH1sWAnX7lx4i1dkCtkqAqnDiyV1PP6ms7ZdEiQ9OfAqkS7yAQ3ws8gKG r+8MrU6A==; Received: from host86-163-35-31.range86-163.btcentralplus.com ([86.163.35.31]:53844 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 1pCOeM-00048D-JR; Mon, 02 Jan 2023 12:31: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: Date: Mon, 2 Jan 2023 17:30:44 +0000 Cc: GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <002e01d91df9$79df2670$6d9d7350$@nextmovesoftware.com> To: Jeff Law 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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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: Hi Jeff, > On 2 Jan 2023, at 15:45, Jeff Law wrote: > On 1/1/23 08:55, 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. 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. >> Segher requested that I split this piece out from a fix for PR 106594 = in >> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html >> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap >> and make -k check, both with and without --target_board=3Dunix{-m32}, >> with no new failures. Ok for mainline? >> 2023-01-01 Roger Sayle >> gcc/ChangeLog >> * gcc/simplify-rtx.cc (simplify_unary_operation_1) : >> Avoid generating FFS with mismatched operand and result modes, = by >> using an explicit SIGN_EXTEND/ZERO_EXTEND instead. >> : Likewise, for POPCOUNT of ZERO_EXTEND. >> : Likewise, for PARITY of {ZERO,SIGN}_EXTEND. > ?!? The docs still seem to indicate to me that the modes of the input = and output operands can differ. > Let's take PARITY as an example: >=20 >> @cindex @code{parity@var{m}2} instruction pattern >> @item @samp{parity@var{m}2} >> Store into operand 0 the parity of operand 1, i.e.@: the number of = 1-bits >> in operand 1 modulo 2. >> @var{m} is either a scalar or vector integer mode. When it is a = scalar, >> operand 1 has mode @var{m} but operand 0 can have whatever scalar >> integer mode is suitable for the target. =20 >=20 > The mode of the pattern name has to match the mode of the input = operand. The mode of the > output operand can differ from the mode of the input operand. we seem = to have a disagreement > on the documented semantics of these opcodes. The documentation that you're looking at is the definition of the parity = optab in md.texi, not the definition of the PARITY rtx in rtl.texi. The = distinction is subtle. Hence a backend can define paritysiqi2 but in the RTL pattern it expands = to the unary PARITY operator must have the same result type as its operand = type, wrapped in either a truncate or extension if necessary. I hope this helps. Cheers, Roger --