[LLVMdev] [RFC] Add a simple soft-float class

[Duncan P. N. Exon Smith]

> On 2014 Jun 17, at 22:17, Bruce Hoult <bruce at hoult.org> wrote:
> 
> As I see it:
> 
> - float is wanted because often it's too hard to correctly guess the range of values in advance
> 
> - the uses are generally diagnostic or heuristic and the exact characteristics of rounding in the LSB is unimportant
> 
> - it *is* valuable to have the same bit-accurate results (and subsequent control flow based on it) on different platforms, regardless of whether or what FP hardware they have.
> 
> - higher performance is better, but if you need software FP anywhere then it's useful to make that software FP as fast as possible.

Right.

> - if the software FP is fast enough (even if not fully IEEE754 conformant) then the penalty for not using hardware FP is not all that large.

Also, given the assumption that hardware FP is off-limits, then when the
penalty is too high, someone should work out the range of values and use
integers.

> Therefore: if you're going to transparently use IEEE754 hardware where available, then you also have to make the software implementation bit-accurate to IEEE754 standards.
> 
> That puts a (perhaps unnecessary) performance penalty on the software FP.
> 
> It would be useful to have numbers for how much penalty.
> 
> In the presence of fast full result integer multiply, fast shifts by variable amounts, and (possibly) count-leading-zeroes you can do a non-IEEE754 software FP add in maybe a dozen clock cycles.

FYI, APFloat is bit-accurate.  Someone could wrap APFloat to give it the
same API, and compare them to see the speed difference.  But I think the
simplicity of UnsignedFloat has other benefits.