<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 10:11 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we require the host to have sse2 or other IEEE 754 conformant  implementation, would it be possible to use hardware float?<br>
</blockquote><div><br></div><div>I don't think that IEEE 754 actually guarantees bit-exact results in all cases.<br><br></div><div>-- Sean Silva<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
> On Jun 17, 2014, at 21:34, "Duncan P. N. Exon Smith" <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
><br>
> I'm currently working on stripping usage of `UnsignedFloat` out of<br>
> `-block-freq`.  Before I finish...<br>
><br>
> I propose adding a soft-float class to llvm/Support/ or llvm/Analysis/.<br>
><br>
>  - Portable (unlike hard-floats).<br>
>      - Well-defined for all platforms and safe to use in code.<br>
><br>
>  - Easy to use and reason about (unlike `APFloat`).<br>
>      - Uses operators.<br>
>      - No special numbers.<br>
>      - Every operation well-defined (even divide-by-zero).<br>
>      - No rounding modes.<br>
>      - Digits represented simply as a 32-bit or 64-bit integer.<br>
><br>
>  - Lowers barrier to entry for writing passes with weight-like logic<br>
>    (and other uses of numbers).<br>
>      - Mapping to `uint64_t` is often a hard problem in itself.<br>
>      - First iteration can focus on the pass logic; second iteration<br>
>        can remove the floats.<br>
><br>
>  - Already written and (mostly) tested.<br>
>      - There's currently one in `-block-freq` called `UnsignedFloat`.<br>
>        Tests are out of tree, though.<br>
><br>
> IIUC, the consensus here is:  hard-floats are worse than soft-floats,<br>
> and both are worse integers.  However, we have passes in the tree (e.g.,<br>
> spill placement) that use hard-floats anyway.<br>
><br>
> With a small amount of effort, I can finish testing `UnsignedFloat`<br>
> (and/or `SignedFloat`) and we can remove hard-floats entirely by using<br>
> these classes as drop-in replacements.  The long-term answer (for most<br>
> passes) is mapping to `uint64_t`, but this gets rid of undefined<br>
> behaviour *now*, and provides a simple and practical alternative to<br>
> hard-floats going forward.<br>
><br>
> Thoughts?<br>
><br>
> -- dpnes<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>