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

[Duncan P. N. Exon Smith]

I'm currently working on stripping usage of `UnsignedFloat` out of
`-block-freq`.  Before I finish...

I propose adding a soft-float class to llvm/Support/ or llvm/Analysis/.

  - Portable (unlike hard-floats).
      - Well-defined for all platforms and safe to use in code.

  - Easy to use and reason about (unlike `APFloat`).
      - Uses operators.
      - No special numbers.
      - Every operation well-defined (even divide-by-zero).
      - No rounding modes.
      - Digits represented simply as a 32-bit or 64-bit integer.

  - Lowers barrier to entry for writing passes with weight-like logic
    (and other uses of numbers).
      - Mapping to `uint64_t` is often a hard problem in itself.
      - First iteration can focus on the pass logic; second iteration
        can remove the floats.

  - Already written and (mostly) tested.
      - There's currently one in `-block-freq` called `UnsignedFloat`.
        Tests are out of tree, though.

IIUC, the consensus here is:  hard-floats are worse than soft-floats,
and both are worse integers.  However, we have passes in the tree (e.g.,
spill placement) that use hard-floats anyway.

With a small amount of effort, I can finish testing `UnsignedFloat`
(and/or `SignedFloat`) and we can remove hard-floats entirely by using
these classes as drop-in replacements.  The long-term answer (for most
passes) is mapping to `uint64_t`, but this gets rid of undefined
behaviour *now*, and provides a simple and practical alternative to
hard-floats going forward.

Thoughts?

-- dpnes