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

[Neil Booth]

Dale Johannesen wrote:-

> 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?

That seems reasonable.  However LLVM may also be interested in
simulating the target CPU, in a JIT or run-time library, or asking
"does this operation raise any hardware exceptions, and which ones",
this question being important for optimization?  This was the
original intent of the code and should be preserved.  I'd like to
preserve that.  So could you add an extra flag for this case?

> 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.

This one should be special-cased at the call site.  I think the loss
of IEEE semantics, which are there for good reason and may even be
being relied on elsewhere in APFloat, is a very bad idea here.

Chris, what do you think?

Neil.