llvm dev - Jun 2014 - [LLVMdev] [RFC] Add a simple soft-float class

On Tue, Jun 17, 2014 at 10: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?
>
I don't think that IEEE 754 actually guarantees bit-exact results in all
cases.

-- Sean Silva

>
> 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/8313737e/attachment.html>

On Jun 18, 2014, at 9:30 AM, Sean Silva <chisophugis at gmail.com> wrote:
> On Tue, Jun 17, 2014 at 10: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?
> 
> I don't think that IEEE 754 actually guarantees bit-exact results in
all cases.

IEEE 754 accuracy guarantees are expressed in terms of ULPs:
Units-in-the-Last-Place.  Most of the primitive operations are accurate to +/-
0.5 ULPs, which is equivalent to saying that there is a single bit-accurate
result (for a given rounding mode).  Once you get into transcendentals, you
start getting operations with much wider ULP bounds.

—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/17a63d8d/attachment.html>

On Wed, Jun 18, 2014 at 11:12 AM, Owen Anderson <resistor at mac.com>
wrote:
>
> On Jun 18, 2014, at 9:30 AM, Sean Silva <chisophugis at gmail.com>
wrote:
>
> On Tue, Jun 17, 2014 at 10: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?
>>
>
> I don't think that IEEE 754 actually guarantees bit-exact results in
all
> cases.
>
>
>
> IEEE 754 accuracy guarantees are expressed in terms of ULPs:
> Units-in-the-Last-Place.
>
Yeah, that's what I was thinking of, but...

 Most of the primitive operations are accurate to +/- 0.5 ULPs, which
is
> equivalent to saying that there is a single bit-accurate result (for a
> given rounding mode).
>
... I wasn't aware that the primitives were spec'd with sufficiently
tight
ULP bounds for bit-exact results. Good to know!

>  Once you get into transcendentals, you start getting operations with much
> wider ULP bounds.
>
Yeah, this was the specific counter-example that I was aware of.

>
> —Owen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/3a2e43fa/attachment.html>