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

[Bruce Hoult]

As I see it:

- float is wanted because often it's too hard to correctly guess the range
of values in advance

- the uses are generally diagnostic or heuristic and the exact
characteristics of rounding in the LSB is unimportant

- it *is* valuable to have the same bit-accurate results (and subsequent
control flow based on it) on different platforms, regardless of whether or
what FP hardware they have.

- higher performance is better, but if you need software FP anywhere then
it's useful to make that software FP as fast as possible.

- if the software FP is fast enough (even if not fully IEEE754 conformant)
then the penalty for not using hardware FP is not all that large.

Therefore: if you're going to transparently use IEEE754 hardware where
available, then you also have to make the software implementation
bit-accurate to IEEE754 standards.

That puts a (perhaps unnecessary) performance penalty on the software FP.

It would be useful to have numbers for how much penalty.

In the presence of fast full result integer multiply, fast shifts by
variable amounts, and (possibly) count-leading-zeroes you can do a
non-IEEE754 software FP add in maybe a dozen clock cycles.


On Wed, Jun 18, 2014 at 4:11 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> If we require the host to have sse2 or other IEEE 754 conformant
>  implementation, would it be possible to use hardware float?
>
> Sent from my iPhone
>
> > On Jun 17, 2014, at 21:34, "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?
> >
> > -- dpnes
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/5f66b9a9/attachment.html>