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

[Duncan P. N. Exon Smith]

> On 2014 Jun 18, at 13:29, Owen Anderson <resistor at mac.com> wrote:
> 
> Numerical analysis is hard.  Every numerics expert I have ever worked with considers trying to re-invent floating point a cardinal sin of numerical analysis.  Just don’t do it.  You will miss important considerations, and you will pay the price for it later.  Plus, anyone in the future who wants to modify your code has to learn a new set of non-standard floating point numerics, and without a well-defined specification it’s not always clear what the correct semantics in a particular case are.

Okay.  To me this sounds like dogma, but I'll defer to your judgement.

> I don’t think we should let expedience get in the way of Doing The Right Thing.

FWIW, we also balance idealism with pragmatism.

> IMO, there are two real issues with APFloat today:
> 
> 1) The interface is really clunky.  We can fix this by fixing/extending the interface, or by adding a convenience wrapper.
> 
> 2) It *may* be too slow for this use case.  Assuming this is actually true, there’s a lot of room for improvement in APFloat’s performance by special-casing common paths (default rounding mode, normal formats).  We could even conceivably detect if we’re compiled for a platform that has sane hard float support and fall back to that transparently.
> 
> None of these seem particularly difficult to me, and saves us from a future world of pain.  I know Michael Gottesman has some WIP code for cleaning up APFloat.  Perhaps he could share it with you?

When working on BFI, I considered (1).  However, for that use case, I
needed simple saturation of unsigned quantities.  The wrapper seemed to be
heading somewhere more bug prone than a simple hand-rolled implementation
(and with as many lines of code), so I switched gears.

You're saying that these semantics were wrong-headed from the get-go.
They were useful for modeling block frequency, but I'm not a numerics
expert.

> Making our existing soft float implementation (APFloat) more convenient and faster is a win-win.  It solves this particular use case without introducing risk of defining the representation wrong, AND it makes it easier and more convenient to use for other clients within the compiler.

Yup.  That'd be good work to do even if UnsignedFloat *were* a good idea.
It's fairly tangential to cleaning up BFI, though, so I won't be tackling
it right now (anyone motivated should go ahead!).

I'll continue with the post-commit plan for BFI that Chandler, Andy and I
mapped out, which was/is something like this:

  - Model the "bias" metric.
  - Approximate loop scales by their lg (with a special case for 3) and
    reorganize calculations to avoid quantities less than 1/UINT64_MAX.
  - Factor out the useful parts of UnsignedFloat into helper functions
    that actually have tests in tree.
  - Replace uses of UnsignedFloat with helpers (and delete its shell).
  - Look at sharing float-like helper algorithms with APFloat.

-- dpnes