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

[Dale Johannesen]

On Oct 8, 2008, at 9:48 PMPDT, Chris Lattner wrote:

> On Oct 7, 2008, at 3:19 PM, Neil Booth wrote:
>>> 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?
>
> 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.