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

[Duncan P. N. Exon Smith]

> On 2014 Jun 18, at 09:59, Philip Reames <listmail at philipreames.com> wrote:
> 
> 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.

Something IEEE-compliant would be doable by wrapping APFloat.  I prefer
something simpler.

> 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.

The specification is simple, though.  For UnsignedFloat, you have digits and
an exponent that represent digits*2^exponent.  Exceeding bounds saturates at
min or max.  Divide-by-zero gives you the max.  Rounding is round-half-away-
from-zero.  Overloaded operators +-*/ do what you expect.  Overloaded
comparison operators do the right thing.  Conversion to/from integers works
as expected.  That's it.

Justification is that it's better for compilers than a hard float, it has a
large dynamic range, it's simple to use, and its implementation is
straightforward.

Encouraging floating point-based code in the compiler is a non-goal.  But
given the use of hard-floats already, having a simple way to talk about
numbers with a large dynamic range appears to be valuable.

> 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.

Probably depends on the problem.  I wrote UnsignedFloat since it was the
simplest way to encapsulate the dynamic range in block frequency info.  In
particular, the order of operations in calculating block frequency can
exhaust precision of a `uint64_t`-based rational at either end before
returning back.

Incidentally, we already have a (limited) version of a rational in
BranchProbability -- also used in block frequency info.  The rational part
could be extracted out, I'm sure.