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

Dale Johannesen dalej at apple.com
Tue Oct 7 10:41:35 PDT 2008


On Oct 7, 2008, at 6:19 AMPDT, Neil Booth wrote:
> Dale Johannesen wrote:-
>> 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.


Good to hear from you on this one.

What the rest of the compiler wants to know is whether a conversion  
can be done without loss of information.  I.e. if you convert type A  
to type B, then back to type A, you get the original value.  Right now  
it's using the return value == fsOK check
to figure that out.  I suppose the various call sites could be taught  
about NaNs but it really seems better to keep those details buried in  
APFloat somehow.

I guess we could add a separate "conversion doesn't lose information"  
return value to the conversion routines, or even convert back and  
compare at the call sites, although that seems silly when the first  
conversion has all the needed information.  I'm not so sure it's worth  
preserving strict IEEE behavior in all these edge cases, though,  
what's the value of that in LLVM?  How would you approach the problem?

When I implemented the -0.0 conversion to int, I thought that was what  
IEEE754 calls for, but I missed the definition of inexact, obscurely  
placed in 7.4(4).  6.3 is clear that the result should have a negative  
sign, and that's not implementable on a twos complement machine, yet  
none of the exceptions seems to apply; I guess the standard calls for  
quietly producing an answer known to be wrong.  This one really seems  
like a bug in the standard.




More information about the llvm-commits mailing list