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

Demikhovsky, Elena elena.demikhovsky at intel.com
Thu Aug 29 02:12:20 PDT 2013


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.





More information about the llvm-dev mailing list