<div dir="ltr">As I see it:<div><br></div><div>- float is wanted because often it's too hard to correctly guess the range of values in advance</div><div><br></div><div>- the uses are generally diagnostic or heuristic and the exact characteristics of rounding in the LSB is unimportant</div>
<div><br></div><div>- 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.</div><div><br></div><div>
- higher performance is better, but if you need software FP anywhere then it's useful to make that software FP as fast as possible.</div><div><br></div><div>- 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.</div>
<div><br></div><div>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.</div><div><br></div><div>
That puts a (perhaps unnecessary) performance penalty on the software FP.</div><div><br></div><div>It would be useful to have numbers for how much penalty.</div><div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 4: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>
<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>