llvm dev - Mar 2018 - how to simplify FP ops with an undef operand?

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?

-----Original Message-----
From: Nuno Lopes [mailto:nunoplopes at sapo.pt] 
Sent: Thursday, March 01, 2018 2:31 PM
To: David Majnemer <david.majnemer at gmail.com>
Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; Friedman, Eli
<efriedma at codeaurora.org>; Sanjay Patel <spatel at
rotateright.com>; llvm-dev <llvm-dev at lists.llvm.org>; Stephen Canon
<scanon at apple.com>; John Regehr <regehr at cs.utah.edu>; Sanjoy
Das <sanjoy at playingwithpointers.com>; Matt Arsenault <arsenm2 at
gmail.com>; Kreitzer, David L <david.l.kreitzer at intel.com>
Subject: Re: how to simplify FP ops with an undef operand?
>> On Thu, Mar 1, 2018 at 2:08 AM, Nuno Lopes <nunoplopes at
sapo.pt> wrote:
>> We can do "add %x, undef" => "undef" because for
any value of %x, we
>> can always find a value that when added to %x produces any value in 
>> the domain of integers.
>>
>> This is not the case with floats since with some inputs, e.g., NaNs, 
>> we are not able to produce some values in the domain (e.g., there's
>> no value of %x that makes "fadd NaN, %x" return 42.0).
>>
>> In summary, since there's no NaN constant in the IR
>
> Isn't "float 0x7FF8000000000000" a NaN constant?
Ok, my bad, you can use the binary value directly. There are several NaN values,
but I guess we could canonicalize on one of them.

Nuno

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

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