llvm dev - Aug 2013 - [LLVMdev] Ordered / Unordered FP compare are not handled properly on X86

On 29 Aug 2013, at 08:19, Tim Northover <t.p.northover at gmail.com>
wrote:
> If so, a compare that used that instruction would have to become more
> like an "invoke" with a landingpad for the exception and so on,
> wouldn't it? The current fcmp can already distinguish between ordered
> and unordered, because ucomiss provides that information.
There are currently lots of limitations in the expressiveness of LLVM IR for
floating point operations (e.g. distinguishing between trapping and non-trapping
cases and representing the floating point environment).  If anyone wants to
fully implement the floating point part of C99 (or Fortran!) then they will
quickly hit problems.  I believe that this kind of thing is usually implemented
on-demand, and so until someone (maybe those nice folks at Argonne National
Laboratory) who cares about numerical accuracy makes it a priority.

David

But this is another case. LLVM IR distinguishes between ordered and unordered
compare and X86 backend has appropriate instructions.
But during DAG selection we just lose this information and always generate
unordered fcmp.
I.e. in case of ordered fcmp the vcomiss should be generated, and in case of
unordered - vucomiss.

-  Elena


-----Original Message-----
From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
Chisnall
Sent: Thursday, August 29, 2013 10:50
To: Tim Northover
Cc: Demikhovsky, Elena; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Ordered / Unordered FP compare are not handled properly
on X86

On 29 Aug 2013, at 08:19, Tim Northover <t.p.northover at gmail.com>
wrote:
> If so, a compare that used that instruction would have to become more 
> like an "invoke" with a landingpad for the exception and so on, 
> wouldn't it? The current fcmp can already distinguish between ordered 
> and unordered, because ucomiss provides that information.
There are currently lots of limitations in the expressiveness of LLVM IR for
floating point operations (e.g. distinguishing between trapping and non-trapping
cases and representing the floating point environment).  If anyone wants to
fully implement the floating point part of C99 (or Fortran!) then they will
quickly hit problems.  I believe that this kind of thing is usually implemented
on-demand, and so until someone (maybe those nice folks at Argonne National
Laboratory) who cares about numerical accuracy makes it a priority.

David

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

On 29 August 2013 10:12, Demikhovsky, Elena <elena.demikhovsky at
intel.com> wrote:
> But this is another case. LLVM IR distinguishes between ordered and
unordered compare and X86 backend has appropriate instructions.
I think LLVM uses ordered/unordered compare to mean something
different to what the x86 instructions do. For example, "not equal":

    fcmp une == unordered not equal == A is NaN, B is NaN, or A != B
    fcmp one == ordered and equal == A is not NaN, B is not NaN, and A != B

Both of these can be implemented with the x86 unordered comparison
instruction by performing certain tests on the EFLAGS result. But if
we used the comiss instruction (and exceptions weren't masked) then
we'd take an exception if either A or B was a NaN.

Look at the C file I've attached, where I start by unmasking
exceptions and then perform what's essentially an "one"
comparison.
LLVM implements this with ucomiss, and gets the result correct. If you
change this to "comiss" then instead the program terminates with a
floating point exception.

So there seem to be 2 cases:
1. Exception is masked. ucomiss is identical to comiss, why bother
complicating things by emitting comiss?
2. Exception is not masked: they're different and LLVM's IR has
specifically asked for the ucomiss behaviour: fcmp wants to know that
they're ordered, not abort if they're unordered.

Of course, as David says, we may need more intrinsics or instructions
to implement the stricter parts of IEEE-754 that C can expose, but
normal fcmp instructions aren't the place for that.

Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.c
Type: text/x-csrc
Size: 344 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/dbf52d89/attachment.c>