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

[Andrew Trick]

On Jun 17, 2014, at 6:34 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

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

I would just like to preemptively reject any argument that having a convenient soft-float is bad because it discourages moving to a more efficient fixed-point representation. The evidence shows otherwise. It took two years to get a working fixed point representation for block frequency and still don’t have one for spill weight. We should have been using a convenient and relatively efficient soft-float, as you have implemented, all this time. In the case of block frequency we would have been able to focus on design and fixing the algorithm instead of representational problems from the beginning. In the case of spill weight, I believe it would have made it more apparent and obvious that we still need to develop a better representation, and we wouldn’t have wasted time debugging buildbot unpredictability.

I think it should be easy to develop new passes incrementally without setting up barriers. Your soft-float will help. Beyond that I have absolutely no opinion on its naming or location.

-Andy