From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) by sourceware.org (Postfix) with ESMTPS id B10FE3857034 for ; Thu, 5 May 2022 08:35:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B10FE3857034 Received: by mail-vk1-xa2a.google.com with SMTP id bc42so1756628vkb.12 for ; Thu, 05 May 2022 01:35:59 -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:content-transfer-encoding; bh=YIiryAYR7bSK9sgNrSF+D8RJwlvm08MTYVb3fbMHcHI=; b=cLHIjk58NyCsy3IVDJcKtZf3t0fReAnFy5E4PKf68kW9xrxuR15LObFaYqyDZX4S8D xXNUyQ7PS7g6AGwfE2Kvw5/rDmtnMDpP52bsSsOPzKkieW2MbRZOjZ8lBDj5WTJ/bunJ qQZorVulc+TKkCoXe/46qqFyYj49msmOytjOIf1trM041nIlmO0+lJHBRSNOZi5SnlY/ XgabSm/j8too5B52LY8bW7YCQDE6EyEK0OsBF3yhOdadXnMNeONpIwCdfW5wsOvK4b43 x/DnvR26Mm+oKHhoECHGY++odrm2K+rMrsYP53iRlBXN/7qHiOLIC/eKIxOLFKjvym07 zyOQ== X-Gm-Message-State: AOAM533f6mmG7yghv1jSZMHfPibvU1/aG/5Dj9zwP4cBbSTvU2u0tT/F fzBcCkWLwYdNQ0C76gLvZdSKVj5toFNPcGr4huU= X-Google-Smtp-Source: ABdhPJxRSH0/Y4JQ9n+5CLriLu7oF1xvPHN/8j61V+yGqXZ5ynecAEHNpXGRu0PlK/BRBYXtikhL4yfHVVH955zgIAI= X-Received: by 2002:a1f:aa16:0:b0:345:df50:5f89 with SMTP id t22-20020a1faa16000000b00345df505f89mr8039577vke.21.1651739759067; Thu, 05 May 2022 01:35:59 -0700 (PDT) MIME-Version: 1.0 References: <4df302c6-5bc7-f6fb-916a-6dd9c0460268@linux.ibm.com> In-Reply-To: From: Richard Biener Date: Thu, 5 May 2022 10:35:47 +0200 Message-ID: Subject: Re: [PATCH] Skip constant folding for fmin/max when either argument is sNaN [PR105414] To: "Kewen.Lin" , "Joseph S. Myers" Cc: HAO CHEN GUI , Peter Bergner , gcc-patches , Segher Boessenkool , David Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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: Thu, 05 May 2022 08:36:01 -0000 On Thu, May 5, 2022 at 10:30 AM Kewen.Lin wrote: > > on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote: > > On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches > > wrote: > >> > >> Hi, > >> This patch skips constant folding for fmin/max when either argument > >> is sNaN. According to C standard, > >> fmin(sNaN, sNaN=EF=BC=89=3D qNaN, fmin(sNaN, NaN) =3D qNaN > >> So signaling NaN should be tested and skipped for fmin/max in match= .pd. > >> > >> Bootstrapped and tested on ppc64 Linux BE and LE with no regression= s. > >> Is this okay for trunk? Any recommendations? Thanks a lot. > > > > OK. > > > > Thanks, > > Richard. > > > >> ChangeLog > >> > >> 2022-05-05 Haochen Gui > >> > >> gcc/ > >> PR target/105414 > >> * match.pd (minmax): Skip constant folding for fmin/fmax when = both > >> arguments are sNaN or one is sNaN and another is NaN. > >> > >> gcc/testsuite/ > >> PR target/105414 > >> * gcc.dg/pr105414.c: New. > >> > >> patch.diff > >> > >> diff --git a/gcc/match.pd b/gcc/match.pd > >> index cad61848daa..f256bcbb483 100644 > >> --- a/gcc/match.pd > >> +++ b/gcc/match.pd > >> @@ -3093,7 +3093,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > >> (for minmax (min max FMIN_ALL FMAX_ALL) > >> (simplify > >> (minmax @0 @0) > >> - @0)) > >> + /* if both are sNaN, it should return qNaN. */ > >> + (if (!tree_expr_maybe_signaling_nan_p (@0)) > >> + @0))) > > Sorry for chiming in. > > IIUC this patch is mainly for libc function fmin/fmax and the iterator he= re > covers min/max and fmin/fmax. I wonder if it's intent to make this chang= e > for min/max as well? > > As tree.def, "if either operand is NaN, then it is unspecified", the opti= mization > for min/max seems still acceptable? 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 =3D=3D MAX_EXPR || minmax =3D=3D 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? Richard. > > BR, > Kewen