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

[Philip Reames]

In concept, I have no problems with having a soft float implementation 
in tree.  I agree with your points regarding platform independence and 
incrementalism.  If you wanted to use an IEEE compliant implementation 
(possibly with a few restrictions, e.g. rounding mode, trap on bounds 
violations, etc..), I'd be fine with that.

I'm concerned by the proposed semantics mentioned so far.  Without very 
strong justification and a very carefully written specification, I would 
resist any alternate semantics.  My experience has been that floating 
point is already confusing enough and that getting any floating point 
implementation "right" (both implementation *and* usable semantics) is a 
very hard problem.  I don't believe that we have either the resources or 
the interest in solving that problem, and that a partial solution is 
worse than nothing at all.

Purely out of curiosity, for prototyping do we actually want floating 
point?  Or would a rational implementation be better?  I'm not familiar 
with these areas, so I can't really judge.

Philip


On 06/18/2014 08:34 AM, Duncan P. N. Exon Smith wrote:
>> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev