[LLVMdev] Ordered / Unordered FP compare are not handled properly on X86

Tim Northover t.p.northover at gmail.com
Thu Aug 29 03:07:21 PDT 2013


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>


More information about the llvm-dev mailing list