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

[Neil Booth]

Dale Johannesen wrote:-

> > Dale and I discussed this today and basically came to the conclusion
> > that keeping APFloat as close to IEEE semantics is goodness.  The
> > issue is that we don't really know what we're doing here :), and IEEE
> > is common currency among numericists.  I think that it's best to
> > change the clients of these functions to be implemented in different
> > ways (e.g. fptrunc then fpextend and see if we have the same bit
> > pattern) or add new methods that do crazy things that are somehow
> > different than what IEEE says.
> 
> I'd put it a little differently.  What consumers of APFloat  
> conversions need is not IEEE754-compatible exception codes, and I  
> think it's unfortunate that we need to add some new mechanism to get  
> the information that's actually needed, while the IEEE codes are  
> currently useless.   But the argument that IEEE compatibility might be  
> useful in the future has merit, so I'm OK with doing it this way. I'll  
> take care of this over the next day or two.

Thanks.

The current return codes are not useless.  In several places APFloat
makes use of the IEEE return values of other parts of APFloat in
order to get the right answer.  Also the fact that clang doesn't
use the return values for diagnostics, and LLVM doesn't use them
to facilitate optimization, is no fault of APFloat.

Neil.