[PATCH] Short-term workaround for hidden x86 float precision in calculateSpillWeightAndHint()

[Duncan P. N. Exon Smith]

On 2014 Apr 21, at 11:27, Chandler Carruth <chandlerc at google.com> wrote:

> For the long term...
> 
> On Mon, Apr 21, 2014 at 9:39 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>  3. Redesign spill weights to use integers.
> 
> This is far and away my preferred approach.
>  
> 
>  4. Change spill weights to use a soft-float.  I happen to have a
>     soft-float implementation lying around here somewhere...
> 
> With this as a somewhat distant second.

[snip]

> To address why I prefer to just design spill weights to use integers from the beginning rather than leverage a soft-float implementation, I genuinely believe that the design will be simpler and faster as a result. And my memory is that Jakob had some clear idea of how to map the spill weights into integers anyways. I'm holding out hope that this is not another place where we actually *have* to have a floating point representation rather than a fixed point representation due to massively varying scales.

I agree that the design will be faster with integers (I've hardly looked
at the algorithm, so I can't comment on simplicity).  64-bit integer
arithmetic is the right end goal for (almost) all such algorithms.

But the design is already done with floats, and an integer-based design
is likely a major rewrite.  It's pragmatic to use a soft-float until
someone can dedicate time to rewriting it.  (In particular, *I'm* not
volunteering to redesign spill weights right now.)

More generally, it's not unusual for initial algorithms to use floats,
since they're easy to reason about.  It's not always straightforward to
find the right way to use integers.  What's the guidance here?  Use
`float` anyway?  Don't commit until you find a way to use plain integers?