[llvm-dev] how to simplify FP ops with an undef operand?

[Chris Lattner via llvm-dev]

Yes, that would be sensible.  I’d suggest just adding a NaN immediate for type-specific we almost always by default (0x7f800000 for floats).  The rest can use hex notation.

-Chris

> On Mar 2, 2018, at 11:45 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> 
> Well, using ConstantFP to represent NaNs is at least unclear enough that someone claimed that there is no NaN constant in LLVM IR. :-)
> 
> But your point is well made. I guess what I was really asking for is a 'NaN' token in the asm writer/parser. This is obviously a much less important issue, but I can't say that I would look at 0x7f800000 in an ll file and immediately think, "Oh, that's a NaN." I'm not a fan of hexadecimal representation of floating point numbers in general, but I guess it's a necessary evil for exact conversion back to bitcode. The 'NaN' I'm asking for, of course, has something like 4 million possible representations, but I think they are all equivalent.
> 
> In short, never mind.
> 
> -----Original Message-----
> From: Chris Lattner [mailto:clattner at nondot.org] 
> Sent: Thursday, March 01, 2018 8:54 PM
> To: Kaylor, Andrew <andrew.kaylor at intel.com>
> Cc: Nuno Lopes <nunoplopes at sapo.pt>; David Majnemer <david.majnemer at gmail.com>; Matt Arsenault <arsenm2 at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; John Regehr <regehr at cs.utah.edu>
> Subject: Re: [llvm-dev] how to simplify FP ops with an undef operand?
> 
> On Mar 1, 2018, at 2:52 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> Other than finding someone to volunteer for the work required, is there a reason not to add a NaN the IR? I can already ask a ConstantFP if it is a NaN. Why not make that easier to represent?
> 
> ConstantFP  *is* the way to represent a nan constant.  What is hard about it?
> 
> -Chris
>