On 5/5/2022 下午 4:30, 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
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> Hi,
>>>    This patch skips constant folding for fmin/max when either argument
>>> is sNaN. According to C standard,
>>>    fmin(sNaN, sNaN)= qNaN, fmin(sNaN, NaN) = 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 regressions.
>>> Is this okay for trunk? Any recommendations? Thanks a lot.
>>
>> OK.
>>
>> Thanks,
>> Richard.
>>
>>> ChangeLog
>>>
>>> 2022-05-05 Haochen Gui <guih...@linux.ibm.com>
>>>
>>> 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 here
> covers min/max and fmin/fmax.  I wonder if it's intent to make this change
> for min/max as well?
> 
> As tree.def, "if either operand is NaN, then it is unspecified", the 
> optimization
> for min/max seems still acceptable?

For MIN/MAX_EXPR, the result is undefined with NaN. So I think we shouldn't do
constant folding. We should let target decide how to deal with it. The 
"undefined"
here means the result depends on targets as far as I understand.
> 
> BR,
> Kewen

Reply via email to