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

Kaylor, Andrew via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 2 11:45:38 PST 2018


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



More information about the llvm-dev mailing list