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

[Sean Silva]

This may be a stupid question, but I didn't see it addressed anywhere.

Why not just use APFloat? (maybe even APInt would be sufficient for the
desired semantics?)

Is it purely a performance concern? Because it seems like you (and Andy)
are supporting this as a suboptimal but convenient replacement for a proper
integer-based representation. On the other hand, if it's just a performance
optimization over APFloat/APInt, then this soft-float thing becomes quick
hack + optimization which is a combination that gives me a pretty bad gut
feeling (but may still be warranted, of course).

-- Sean Silva




On Tue, Jun 17, 2014 at 7: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?
>
> -- dpnes
> _______________________________________________
> 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/8769919e/attachment.html>