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 24334388451F for ; Fri, 18 Mar 2022 07:43:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24334388451F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From: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=3wz3Y2g2lFPpUTJesoWrrGsnkf5XIvirsJPwfJ19/rc=; b=px48ivMJfxkix2GIsg55pW2fPE 6uZy7o8javVQpd2EQInzwTt3B1a4hF64nSf7J797Lawkz+I6B0A3Kzy02CywRMTBEgPrxlh8WB+vb pFElihdta5bk8DcACA1bOBrcEVharYkj1oCzDNzVoqgSe34tDxupCgDmKkNFf4q0efaV7Lubk71Mq Tse8wVLyC7xi2mmnAWh9C6dTrSyIpzYvX848gM7pshOqWfPEl6Y8SElL73cT4Nuvm6NqqujguZPtQ bXvRUKm8OUIfG3Svn/2JGLj7cGCJ95QUwjQh7W9OfuFCX1lhNzxnra3tRUIdNp35z/ucQb18AKEjq l9f7qHOA==; Received: from host109-154-242-85.range109-154.btcentralplus.com ([109.154.242.85]:58763 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nV7Gz-0007AD-E4; Fri, 18 Mar 2022 03:43:45 -0400 From: "Roger Sayle" To: "'Jeff Law'" , "'Andrew MacLeod'" Cc: "'GCC Patches'" , "'Richard Biener'" References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> In-Reply-To: Subject: RE: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons. Date: Fri, 18 Mar 2022 07:43:42 -0000 Message-ID: <00dc01d83a9b$e50e2140$af2a63c0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHHl55/yMsiL4+bf9wRSdV3pKMaBwHTHh2sAofyspsCEYFGhKyylTDg Content-Language: en-gb 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, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 07:43:48 -0000 Hi Jeff/Andrew, > If you're going to do more work in this space, you might want to reach = out to > Aldy and Andrew to see if there's space for collaboration. One (clever?) suggestion that I do have for ranger would be to add = support for an additional value_range_kind, VR_NONZEROBITS, which would be a variant = of VR_RANGE (for unsigned types?) and require very few changes to the = existing code. Just like VR_RANGE all values would lie in [MIN, MAX], so by = default treating this value_range_kind identically to VR_RANGE there should be = no visible changes, but the change in semantics is that MIN has the minimum = bits set, and MAX, the maximum bits set [equivalent to the RVAL and RMASK = pairs from CCP's bit_value_{bin,un}op]. Hence, the VR_NONZEROBITS range [2,7] would represent the possible values {2, 3, 6, 7} rather than {2, 3, 4, = 5, 6, 7}.=20 For a small number of bits, int_range can already handle this with = multiple irange spans, but adding this representation would allow the unification = of the bit-based propagation performed in tree-ssa-ccp with the range-value = based propagation performed in EVRP/ranger, allowing the clever = forwards/backwards functionality. As Andrew's recent (partial) review points out, tracking the effect of = operations like BIT_XOR_EXPR on VR_RANGE is much more complicated than on the proposed VR_NONZEROBITS. Alas, I'm not the sort of contributor to make large infrastructure = changes myself, but if the above functionality were in place, I/the compiler = would be able to make use of it. Cheers, Roger -- > -----Original Message----- > From: Jeff Law > Sent: 17 March 2022 23:28 > To: Roger Sayle ; 'Richard Biener' > > Cc: 'GCC Patches' > Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP > comparisons. >=20 >=20 > On 3/15/2022 2:03 AM, Roger Sayle wrote: > >> -----Original Message----- > >> From: Richard Biener > >> Sent: 15 March 2022 07:29 > >> To: Roger Sayle > >> Cc: GCC Patches > >> Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of = FP > >> comparisons. > >> > >> On Mon, Mar 14, 2022 at 8:26 PM Roger Sayle > >> wrote: > >>> > >>> I've been wondering about the possible > >>> performance/missed-optimization impact of my patch for PR > >>> middle-end/98420 and similar IEEE correctness fixes that disable > >>> constant folding optimizations when worrying > >> about -0.0. > >>> In the common situation where the floating point result is used by = a > >>> FP comparison, there's no distinction between +0.0 and -0.0, so = some > >>> HONOR_SIGNED_ZEROS optimizations that we'd usually disable, are = safe. > >>> > >>> Consider the following interesting example: > >>> > >>> int foo(int x, double y) { > >>> return (x * 0.0) < y; > >>> } > >>> > >>> Although we know that x (when converted to double) can't be NaN or > >>> Inf, we still worry that for negative values of x that (x * 0.0) = may > >>> be -0.0 and so perform the multiplication at run-time. But in = this > >>> case, the result of the comparison (-0.0 < y) will be exactly the > >>> same as (+0.0 < y) for any y, hence the above may be safely = constant > >>> folded to "0.0 < > >> y" > >>> avoiding the multiplication at run-time. > >>> > >>> This patch has been tested on x86_64-pc-linux-gnu with make > >>> bootstrap and make -k check with no new failures, and allows GCC = to > >>> continue to optimize cases that we optimized in GCC 11 (without = regard to > correctness). > >>> Ok for mainline? > >> Isn't that something that gimple-ssa-backprop.c is designed to > >> handle? I wonder if you can see whether the signed zero speciality = can be > retrofitted there? > >> It currently tracks "sign does not matter", so possibly another > >> state, "sign of zero does not matter" could be introduced there. > > Two questions. Would adding tracking of "sign of zero does not = matter" > > to gimple-ssa-backprop.c be suitable for stage4? Secondly, even if > > gimple-ssa-backprop.c performed this kind of optimization, would = that > > be a reason not to support these transformations in match.pd? = Perhaps > > someone could open a missed optimization PR for backprop in = Bugzilla, > > but the above patch still needs to be reviewed on its own merits. >=20 > Can't see how it's appropriate for stage4, but definitely interesting = for gcc-13. >=20 > It'd fit well into some of the Ranger plans too -- Aldy and Andrew = have been > talking about tracking the special FP values in Ranger. This is = related, though > not exactly the same since rather than tracking the special value, = you're tracking > if those special values actually matter. If you're going to do more = work in this > space, you might want to reach out to Aldy and Andrew to see if = there's space > for collaboration. >=20 >=20 > > > > Speaking of tree-ssa passes that could be improved, I was wondering > > whether you could review my EVRP patch to fix regression PR/102950. = Pretty > please? > > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589569.html >=20 > I forwarded this to Aldy & Andrew. I suspect they missed it. >=20 >=20 > > > > Thanks (as always), >=20 > No, thank you. I'm so happy to see you contributing to GCC regularly = again! >=20 >=20 > Jeff >=20 > >