From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 615903858D3C for ; Thu, 5 May 2022 17:11:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 615903858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.91,201,1647331200"; d="scan'208";a="78000295" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 05 May 2022 09:11:35 -0800 IronPort-SDR: qt0OFis9ncfeVrXxoc9+zT/JocEoGKCcCvEtA4OG1Hv1Z5lwIx8AUp/r7iPhqDLox3aQYbxXMS RaXGbrjIItDhJAtfYHK1QZTCuIDrFIGShrNvB40bl2ZoKq1Be8/NVWNj2s5OGlCQapQOvG8kGt sOhlWfFFPsoAaHi+jYc2qlQ7yTvkJm/0bn35IbCzDcIW5t9GZBEDbD62WLmdF8iNXuVc1wwvyk ZW/pmwVS1VbRkp9RkfhO2bUL3+bSKrYerSPOuvVeA8OGqW1OP8bxU67le1krR/5q3EPW/Yyflr LrQ= Date: Thu, 5 May 2022 17:11:29 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Richard Biener CC: Kewen.Lin , gcc-patches , Peter Bergner , David , Segher Boessenkool Subject: Re: [PATCH] Skip constant folding for fmin/max when either argument is sNaN [PR105414] In-Reply-To: Message-ID: References: <4df302c6-5bc7-f6fb-916a-6dd9c0460268@linux.ibm.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3113.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Thu, 05 May 2022 17:11:38 -0000 On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote: > MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this > reason, at least that's what I thought. But yes, you might have a point > here (but maybe it's also not strictly enough specified). One option would > be to do (minmax == MAX_EXPR || minmax == MIN_EXPR || !tree_expr ...) > > Joseph - are MIN_EXPR and MAX_EXPR supposed to turn sNaN into qNaN > and the 'undefinedness' is merely as to which operand is chosen? I don't know what MIN_EXPR and MAX_EXPR are supposed to do with sNaN arguments. As noted, the fmax and fmin functions should produce a qNaN result with the "invalid" exception raised (so with an sNaN argument, it's definitely not valid to fold them in the absence of -fno-trapping-math; with -fsignaling-nans -fno-trapping-math, if an argument is known to be sNaN it would be valid to fold to qNaN, but I doubt there's much use of that option combination). C never attempts to define which qNaN result (choice of payload or sign bit) is produced by an operation and I don't think our optimizations should be trying to define that (with any command-line options currently supported) either (other than for non-computational operations such as fabs and copysign, but even there there is scope for implementation-defined handling of assignment as a convertFormat operation rather than a copy operation). Note that while some architectures propagate NaN payloads from a NaN operand to an instruction, others (e.g. RISC-V) do not, and when payloads are propagated there would still be the matter of which payload is chosen when there is more than one NaN operand (on x86, that is handled differently for SSE and x87 instructions). -- Joseph S. Myers joseph@codesourcery.com