[llvm-bugs] [Bug 51921] New: Failure to optimize integer to float conversions that can never fault under -ftrapping-math

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51921

            Bug ID: 51921
           Summary: Failure to optimize integer to float conversions that
                    can never fault under -ftrapping-math
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: gabravier at gmail.com
                CC: llvm-bugs at lists.llvm.org

bool f(float x)
{
    return x == 0;
}

With -O3 -ftrapping-math, this gives:

f(float):                                  # @f(float)
        xor     eax, eax ; eax = 0
        cvtsi2ss        xmm1, eax ; xmm1 = float(eax -> 0)
        ucomiss xmm0, xmm1
        setnp   cl
        sete    al
        and     al, cl
        ret

(though this is not unique to x86 and I can reproduce it on platforms like
powerpc64le)

Conversion of 0 to a float can never be inexact, so it seems to me as though
the conversion is unnecessary here. This should also be possible for all
constants that exactly convert to a float/double/long double in equivalent
situations (though from my reading of the IEEE-754 standard it seems the
conversion should be kept under `-ftrapping-math` if the conversion is
inexact).

As such, it should be possible to optimize this to `return x == 0.f;`. This is
done by GCC, but not by LLVM.

Godbolt comparison here: https://godbolt.org/z/6YPMEGfex
(if someone knows how to do alive2 checks for stuff that involves trapping
floating point operations, I would be glad to know)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210920/73989d0d/attachment.html>