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

[Duncan P. N. Exon Smith]

> On 2014 Jun 17, at 21:59, Owen Anderson <resistor at mac.com> wrote:
> 
> Hi Duncan,
> 
> Some of these don’t make a lot of sense:

Sorry -- I think I was assuming too much knowledge about what I committed as
part of the BlockFrequencyInfo rewrite.

What's committed there is a class called UnsignedFloat that wraps the
following with a bunch of API:

    template <class UIntT> struct UnsignedFloat {
        UIntT Digits;
        uint16_t Exponent;
    };

There are some static asserts to restrict UIntT to either `uint32_t` or
`uint64_t`.  I have tests that are out of tree.  The `uint32_t` version uses
64-bit math for divide and multiply while the `uint64_t` version uses long
division etc. -- otherwise they share implementation.  They both defer to
APFloat for non-trivial string conversion.

I don't think it will be much work to clean this up and create a SignedFloat
variant that adds a `bool` for the sign (and shares most of the impl).

I'll respond to your specific points inline.

> 
>>  - Easy to use and reason about (unlike `APFloat`).
>>      - Uses operators.
>>      - No special numbers.
> 
> What semantics do you propose to use instead?  At some point, people will hit the boundaries of their range, and you need to do something sensible there.

Simple saturation.

>>      - Every operation well-defined (even divide-by-zero).
> 
> Divide-by-zero is actually well-defined in IEEE 754:
> 	x / +0.0 == +Inf
> 	x / -0.0 == -Inf
> 	(-)0.0 / (-)0.0 ==  NaN

Point taken!

>>      - No rounding modes.
> 
> You can’t implement a finite precision floating point representation without any rounding.  I assume what you mean here is only one rounding mode, i.e. round-nearest-ties-to-even.

Yes.  I was emphasizing that rounding modes aren't part of the API.

>>      - Digits represented simply as a 32-bit or 64-bit integer.
> 
> Isn’t this the same as the significand of an IEEE float?  If you go with 64-bit, it sounds like you’re defining something very close to Intel’s FP80.

Yup.  The `uint64_t` version is similar to a non-conforming and slow FP80
that's always in denormal mode, but the *same* non-conforming on every
platform.