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

Should I open a ticket for this?

-           Elena

From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: Wednesday, August 28, 2013 19:51
To: Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Ordered / Unordered FP compare are not handled properly
on X86

On Wed, Aug 28, 2013 at 2:16 AM, Demikhovsky, Elena <elena.demikhovsky at
intel.com<mailto:elena.demikhovsky at intel.com>> wrote:
I found that there is no diff in code generator for Ordered / Unordered FP
compare instructions.
FUCOMISS, FUCOMISD are generated in the both cases.

Yes.  That's how fcmp is defined in LangRef.
-Eli
---------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/0334985b/attachment.html>

On 29 August 2013 06:31, Demikhovsky, Elena <elena.demikhovsky at
intel.com> wrote:
> Should I open a ticket for this?
I think he was saying this is intended behaviour. Isn't the difference
between ucomiss and comiss just whether an exception is raised for
NaN?

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.

Tim.

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