<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 5:56 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
> On 2014-Jun-18, at 21:14, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br>
><br>
> Is there any way we have this utility and just not claim that it is for use with a numerics package? The only claim we’re making is that it is a useful utility for writing compiler heuristics. We can do that without waking any Dragons, and Duncan’s design is quite straightforward.<br>
><br>
> I think calling it a “soft-float” implementation was a mistake (even though that’s what it is), and has completely derailed this thread.<br>
><br>
> The goal is to factor and reuse the code that we need to reinvent every time we need to extend the dynamic range of some of cost metric. The question here is whether that in itself a worthwhile goal, independent of how the compiler models language level floats. I have nothing *against* repurposing APFloat. After all, we only have a couple metrics in tree that need this new utility. But let’s be clear that APFloat's purpose is completely different, so it’s not like we’re reinventing any existing utility.<br>
><br>
> I honestly think we should consider not calling this a Float at all just to avoid the obvious confusion. I’m fine calling it a ScaledNumber or something.<br>
<br>
Thanks Andy for refocusing the discussion.<br>
<br>
This is not a float. This is not a replacement for a APFloat, and it is not a<br>
numerics library (or the start of one). It's a number with a scale that has simple<br>
integer-like semantics, useful for extending the dynamic range of cost metrics.<br>
<br>
Owen and I talked off-line, and he's okay with this going in the tree with a couple<br>
of conditions:<br>
<br>
1. The name matters. The biggest danger here is that someone sees this and thinks<br>
it's appropriate for general numerics, or otherwise "bigger than it is".<br>
<br>
A couple of ideas are "UnsignedScalar" (too generic?) and "CostMetric" (too<br>
specific?).<br>
<br>
2. Header docs should clearly describe the restricted problem domain appropriate<br>
to this class, and should forward those looking for a soft-float to `APFloat`.<br>
<br>
For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` and<br>
`lib/Support/CostMetric.cpp`. I'll start by extracting helper functions into the<br>
same files in the `llvm::CostMetrics` namespace, and then eventually rename the class<br>
to `llvm::CostMetric` and move it over.<br>
<br>
*enable-bikeshed-mode* [All the names are wrong. Paint them?]<br></blockquote><div><br></div><div>my 2c: describe it as "an approximate, high-dynamic-range unsigned integer".</div><div><br></div><div>That doesn't lend itself to something easy to type, but "ApproxHDRUint" might be doable. Plus, it sounds sort of scary.</div>
<div><br></div><div>Having something in the name that suggests that it is an integer should ward off any attempt to use it for numerics.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<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></div>