[llvm-commits] [llvm] r57185 - /llvm/trunk/lib/Support/APFloat.cpp

[Neil Booth]

Neil Booth wrote:-

> > For converting a QNan, what it says is:
> > "Every operation involving one or two input NaNs, none of them  
> > signaling, shall signal no exception but, if a FP result is to be  
> > delivered, shall deliver as its result a QNaN, which should be one of  
> > the input NaNs.  Note that format conversions might be unable to  
> > deliver the same NaN."
> > 
> > The last sentence applies here, and I'm not sure of its intent.   At  
> > face value it's a statement that it may be impossible to implement the  
> > standard in this case, which seems unlikely.   IMO an Inexact result  
> > seems compatible with the way things work otherwise.
> > 
> > To confuse things further, the value in the PR is not even an IEEE  
> > NaN, but a pseudo-NaN in Intel jargon.  It is outside all standards.
> 
> The intent of APFloat as I wrote it was to replicate a conforming
> IEEE-754 CPU's results in software, with the return result indicating
> those exceptions that would occur under IEEE-754.  IBM double double
> was later hacked on in an incomplete way.
> 
> The paragraph you quote is unambiguous; these NaN to NaN conversions
> should always return fsOK because it "shall signal no exception".
> This is how the code worked before your change.
> 
> Perhaps LLVM needs APFloat to evolve beyond IEEE-754; I'm not sure.
> But I suggest you think hard about that, and if you decide to go that
> way you at least use a new flag for your extensions.  You should
> also update the comments in the .cpp and .h files appropriately,
> and review what other changes, if any, to other operations are needed
> to accomdate your new semantics.

I missed your bit about this being some Intel 80-bit format extension
thing.  If so, we should replicate the exceptions done by a real
Intel / AMD CPU.  I don't believe they define extra exceptions.
What exceptions do they raise and what result do they give in this
case?   Do we match both?

Neil.