[PATCHv2][PR 57371] Remove useless floating point casts in comparisons

[Yuri Gribov]

On Sat, Jul 8, 2017 at 5:30 AM, Yuri Gribov <tetra2005@gmail.com> wrote:
> On Fri, Jul 7, 2017 at 11:51 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Fri, 7 Jul 2017, Yuri Gribov wrote:
>>
>>> > I suspect infinities would already work with the patch as-is (the logic
>>> > dealing with constants outside the range of the integer type).  I'm less
>>> > clear that NaNs would work properly.  (If the comparison is == or != you
>>> > can optimize it for quiet NaNs, to false and true respectively.  If it's a
>>> > signaling NaN, or < <= > >=, optimizing to false is only valid with
>>> > -fno-trapping-math, as it would lose an "invalid" exception.)
>>>
>>> It's actually under -fsignaling-nans (which if off by default). I've
>>
>> No, ordered comparisons with qNaNs should result in exceptions,
>
> I assume you mean sNaNs.
>
>> so it's not valid by default to optimize them to false (whereas it is valid for
>> equality comparisons, as those only raise exceptions for signaling NaNs).
>
> I'm afraid this is default GCC behavior atm - e.g. check existing
>    /* a CMP (-0) -> a CMP 0  */
>    ...
>    (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
>         && ! HONOR_SNANS (@1))
>     { constant_boolean_node (cmp == NE_EXPR, type); })
> (this pattern causes testcase in my patch pr53731-5.c to be optimized).
>
> Or documentation for -fsignaling-nans which says that "the default is
> -fno-signaling-nans" and it "may change the number of exceptions
> visible with signaling NaNs".
>
> In any case, decision to optimize sNaNs is done in HONOR_NANS macro
> which my code duly checks

Actually I should probly change this to be HONOR_SNANS to enable sNaN
optimization by default (like other matchers do).

> so I'm not really sure what else needs to be
> done about discussed patch in this regards.
>
> -Y