[llvm-bugs] [Bug 33467] New: Floating point to integer conversion for Java-like languages

[via llvm-bugs]

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

            Bug ID: 33467
           Summary: Floating point to integer conversion for Java-like
                    languages
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: serguei.katkov at azul.com
                CC: llvm-bugs at lists.llvm.org

There are languages like Java where the floating pointer conversion to integer
is strictly defined in case fp value does not fit int range.

Specifically Java semantic can be represented by the following C++ function:
int test1(float f) {
  if (f != f) // NaN
    return 0;
  if (f > (float)std::numeric_limits<int>::max())
    return std::numeric_limits<int>::max();
  if (f < (float)std::numeric_limits<int>::min())
    return std::numeric_limits<int>::min();
  return (int)f;
}

Currently this results in the following X86 assembler code:
0000000000000000 <_Z5test1f>:
   0:   0f 2e c0                ucomiss %xmm0,%xmm0
   3:   7a 25                   jp     2a <_Z5test1f+0x2a>
   5:   b8 ff ff ff 7f          mov    $0x7fffffff,%eax
   a:   0f 2e 05 00 00 00 00    ucomiss 0x0(%rip),%xmm0        # 11
<_Z5test1f+0x11>
  11:   77 16                   ja     29 <_Z5test1f+0x29>
  13:   b8 00 00 00 80          mov    $0x80000000,%eax
  18:   f3 0f 10 0d 00 00 00    movss  0x0(%rip),%xmm1        # 20
<_Z5test1f+0x20>
  1f:   00
  20:   0f 2e c8                ucomiss %xmm0,%xmm1
  23:   77 04                   ja     29 <_Z5test1f+0x29>
  25:   f3 0f 2c c0             cvttss2si %xmm0,%eax
  29:   c3                      retq
  2a:   31 c0                   xor    %eax,%eax
  2c:   c3                      retq

So to do a fp conversion to int we should execute 3 checks for conversion
really happens while all checks actually are for corner cases when fp value is
NaN or does not fit int range.

However X86 instruction cvttss2si has an additional property. It returns
INT_MIN in case fp value does not fit the int range.

So the better generated code would be something like this:
0000000000000000 <_Z4testf>:
   0:   f3 0f 2c c0             cvttss2si %xmm0,%eax
   4:   3d 00 00 00 80          cmp    $0x80000000,%eax
   9:   75 17                   jne    22 <_Z4testf+0x22>
   b:   0f 2e c0                ucomiss %xmm0,%xmm0
   e:   7a 13                   jp     23 <_Z4testf+0x23>
  10:   b8 00 00 00 80          mov    $0x80000000,%eax
  15:   0f 57 c9                xorps  %xmm1,%xmm1
  18:   0f 2e c1                ucomiss %xmm1,%xmm0
  1b:   76 05                   jbe    22 <_Z4testf+0x22>
  1d:   b8 ff ff ff 7f          mov    $0x7fffffff,%eax
  22:   c3                      retq
  23:   31 c0                   xor    %eax,%eax
  25:   c3                      retq
where we need only one check to generate the most common case.
Or even better if we could put the fast pass right after first conversion.

It would be nice if X86 backend could catch this pattern to utilize the
addition property of conversion instruction.

-- 
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/20170615/747410d6/attachment-0001.html>