[LLVMdev] Ordered / Unordered FP compare are not handled properly on X86
Demikhovsky, Elena
elena.demikhovsky at intel.com
Sat Aug 31 10:44:48 PDT 2013
Hi Tim,
I checked again, you are right. Ordered / unordered of X86 arch and LLVM fcmp have the different meaning.
Thank you for the detailed explanation.
- Elena
-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com]
Sent: Thursday, August 29, 2013 13:07
To: Demikhovsky, Elena
Cc: David Chisnall; Eli Friedman (eli.friedman at gmail.com); llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Ordered / Unordered FP compare are not handled properly on X86
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.
---------------------------------------------------------------------
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.
More information about the llvm-dev
mailing list