From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) by sourceware.org (Postfix) with ESMTPS id 30E093857341 for ; Fri, 6 May 2022 06:18:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 30E093857341 Received: by mail-vs1-xe2c.google.com with SMTP id v139so6297164vsv.0 for ; Thu, 05 May 2022 23:18:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W74M+Ar/nIewRDbVjtnPzo6BezvV2ouxt3nBor2rd78=; b=uRJpbZQXr2d7cfQxUAPzJYhpFr0Fo8YfgsxeA60EvT4uIf59lUuCtfDVgh2ueNma53 HXFZDyCTqx0ArOtcisj656fpp3LFPM85sV3ZWcH7VA7T8f0pWBGbNACDuuMwlgF7c5M2 z/eBIN4G4NHg8qKcFZ5zlKp9gkKH/2KhCdPSF0OC5E3IOZJ46qKohNwlSQcgNyZgprQs USr4cpzr1vsAyzw9nuQJhshY7oaoQJAih0s/IHl62oXMmy/vfCSkrpxgJsHYchMGE02m w9WZYw8nw1/66FIJlv2tyCrRSqpmsjLAbrTRLK3RTabVxeB01HPUG4B+AzjNdQLWHwre wytA== X-Gm-Message-State: AOAM530y3uW6qRx8VbujAobGXEn4IiymgF4e+l8wHWKUdGP1dAEr0+vA Sh+rsivHOH1Tfthvhh+3izk/VyiUUUM/qfdJHwk= X-Google-Smtp-Source: ABdhPJz6MbNYLC/D6bQN40PmiTerG487Xq80U7KHa46MueKPFm+aBQgkL8baa1qAKwulws5hUDylKo9J7nK9J2BUEUc= X-Received: by 2002:a05:6102:5489:b0:32d:8a59:c908 with SMTP id bk9-20020a056102548900b0032d8a59c908mr584079vsb.9.1651817880507; Thu, 05 May 2022 23:18:00 -0700 (PDT) MIME-Version: 1.0 References: <4df302c6-5bc7-f6fb-916a-6dd9c0460268@linux.ibm.com> In-Reply-To: From: Richard Biener Date: Fri, 6 May 2022 08:17:48 +0200 Message-ID: Subject: Re: [PATCH] Skip constant folding for fmin/max when either argument is sNaN [PR105414] To: Joseph Myers Cc: "Kewen.Lin" , gcc-patches , Peter Bergner , David , Segher Boessenkool Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 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, 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, 06 May 2022 06:18:02 -0000 On Thu, May 5, 2022 at 7:11 PM Joseph Myers wrote: > > 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). Thanks. So I think the patch as posted is correct on the safe side in letting the CPU to decide what happens with sNaNs. As said, the chance seeing an sNaN and MAX/MIN_EXPR is low. So I'm defering to the poster if he wants to re-post with treating MIN/MAX_EXPR special in the optimistic sense. Richard. > -- > Joseph S. Myers > joseph@codesourcery.com