On Sat, Jul 8, 2017 at 5:30 AM, Yuri Gribov <tetra2...@gmail.com> wrote: > On Fri, Jul 7, 2017 at 11:51 PM, Joseph Myers <jos...@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