<div dir="ltr"><div><div><div>This may be a stupid question, but I didn't see it addressed anywhere.<br><br></div>Why not just use APFloat? (maybe even APInt would be sufficient for the desired semantics?)<br><br></div>
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).<br>
<br></div>-- Sean Silva<br><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 7:34 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
</blockquote></div><br></div>