[Bug other/63387] New: Optimize pairs of isnan() calls into a single isunordered()

[Bug other/63387] New: Optimize pairs of isnan() calls into a single isunordered()

[jzwinck at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

            Bug ID: 63387
           Summary: Optimize pairs of isnan() calls into a single
                    isunordered()
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jzwinck at gmail dot com

Whenever a program does (isnan(x) || isnan(y)), GCC 4.7 and 4.9 in the best
case emits code like this on x86-64:

  ucomisd %xmm0, %xmm0 ; set parity flag if x is NAN
  setp    %dl          ; copy parity flag to %edx
  ucomisd %xmm1, %xmm1 ; set parity flag if y is NAN
  setp    %al          ; copy parity flag to %eax
  orl     %edx, %eax   ; OR one byte of each result into a full-width register

This is suboptimal because ucomisd already has the effect of checking if
*either* of its operands is NAN, so this code is equivalent:

  xorl    %eax, %eax
  ucomisd %xmm1, %xmm0
  setp    %al

And indeed that's what you get if you help GCC along by calling isunordered(x,
y) instead.  But no one thinks to do that, because isnan() is much more widely
used and it isn't an obvious thing at the source level to change pairs of
isnan() calls to isunordered().  So the optimizer should do it.

Someone already suggested that in GCC 5 it might be as simple as this (which
seems correct and safe to me):

  (simplify (or (unordered @0 @0) (unordered @1 @1)) (unordered @0 @1))

A discussion of this issue is here:
http://stackoverflow.com/questions/26053934/is-it-feasible-to-add-this-optimization-to-gcc

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Thanks.

The simplify pattern probably needs an extra test that the types of @0 and @1
are compatible, so we don't try to produce unord(float,double). In that case,
it isn't as obvious that converting the first argument to double then using
unord would be better than 2 isnan, but it may still be worth it.

Now we have to wait until the branch that handles those patterns gets merged.

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-29
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I hope to get the branch merged (partially) soon.

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
According to Joseph's explanation at
https://sourceware.org/bugzilla/show_bug.cgi?id=17441 , this transformation
should be conditional to !flag_signaling_nans.

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I am not sure about signalling NAN issues, but doesn't it otherwise also apply
to code like the following? At least in terms of generated assembler, the
result looks the same.

  _Bool foo(float x, float y) { return x != x || y != y; }

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 13 Apr 2015, burnus at gcc dot gnu.org wrote:

> I am not sure about signalling NAN issues, but doesn't it otherwise also apply
> to code like the following? At least in terms of generated assembler, the
> result looks the same.
> 
>   _Bool foo(float x, float y) { return x != x || y != y; }

That's also equivalent in the absence of signaling NaNs (but it won't 
raise invalid if x is a quiet NaN and y signaling, whereas isunordered 
should do so if either is signaling, and the pair of isnan tests shouldn't 
raise invalid at all).  If a non-short-circuit OR were used, it would be 
exactly equivalent to the isunordered call in all cases.

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Tue Apr 14 08:49:16 2015
New Revision: 222077

URL: https://gcc.gnu.org/viewcvs?rev=222077&root=gcc&view=rev
Log:
2015-04-14  Marc Glisse  <marc.glisse@inria.fr>

    PR tree-optimization/63387
gcc/
    * match.pd ((x unord x) | (y unord y) -> (x unord y),
    (x unord x) | (x unord y) -> (x unord y)): New simplifications.
gcc/testsuite/
    * gcc.dg/pr63387.c: New testcase.


Added:
    trunk/gcc/testsuite/gcc.dg/pr63387.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/match.pd
    trunk/gcc/testsuite/ChangeLog

[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

--- Comment #7 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
>   _Bool foo(float x, float y) { return x != x || y != y; }

This testcase is not optimized (even with -fno-trapping-math or with |) because
x != x is not canonicalized to x unord x (or the reverse, but we should not
keep both).