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

[Sean Silva]

On Thu, Jun 19, 2014 at 5: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.
>
> *enable-bikeshed-mode* [All the names are wrong.  Paint them?]
>

my 2c: describe it as "an approximate, high-dynamic-range unsigned integer".

That doesn't lend itself to something easy to type, but "ApproxHDRUint"
might be doable. Plus, it sounds sort of scary.

Having something in the name that suggests that it is an integer should
ward off any attempt to use it for numerics.

-- Sean Silva


> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/3bed23d1/attachment.html>