[LLVMdev] [RFC] Add a scaled number class (was: Add a simple soft-float class)

[Evan Cheng]

On Jun 19, 2014, at 4:56 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

> 
>> On 2014-Jun-18, at 21:14, Andrew Trick <atrick at apple.com> wrote:
>> 
>> 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.
>> 
>> I think calling it a “soft-float” implementation was a mistake (even though that’s what it is), and has completely derailed this thread.
>> 
>> 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.
>> 
>> 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.
> 
> Thanks Andy for refocusing the discussion.
> 
> This is not a float.  This is not a replacement for a APFloat, and it is not a
> numerics library (or the start of one).  It's a number with a scale that has simple
> integer-like semantics, useful for extending the dynamic range of cost metrics.
> 
> Owen and I talked off-line, and he's okay with this going in the tree with a couple
> of conditions:
> 
> 1. The name matters.  The biggest danger here is that someone sees this and thinks
>    it's appropriate for general numerics, or otherwise "bigger than it is".
> 
>    A couple of ideas are "UnsignedScalar" (too generic?) and "CostMetric" (too
>    specific?).
> 
> 2. Header docs should clearly describe the restricted problem domain appropriate
>    to this class, and should forward those looking for a soft-float to `APFloat`.
> 
> For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` and
> `lib/Support/CostMetric.cpp`.  I'll start by extracting helper functions into the
> same files in the `llvm::CostMetrics` namespace, and then eventually rename the class
> to `llvm::CostMetric` and move it over.

I agree with taking a pragmatic approach on this. Making APFloat sucking less so we can eventually replacing this UnsignedFloat package should be a longer term goal. But it should not block short term progress. 

Evan

> 
> *enable-bikeshed-mode* [All the names are wrong.  Paint them?]
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev