<div dir="ltr"><div class="gmail_extra">For the long term...</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 21, 2014 at 9:39 AM, 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"><div id=":10o" class="a3s" style="overflow:hidden"> 3. Redesign spill weights to use integers.<br></div></blockquote><div>
<br></div><div>This is far and away my preferred approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":10o" class="a3s" style="overflow:hidden">

<br>
 4. Change spill weights to use a soft-float.  I happen to have a<br>
    soft-float implementation lying around here somewhere...</div></blockquote></div><br>With this as a somewhat distant second.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
While I'm sympathetic to Hal's comment, I just don't want to debug LLVM's behavior on systems with buggy floating point. This will keep coming up, time and again. What happens when we start forming FMAs in *just* the right way? No one writing LLVM code is attending to the contraction domains which avoid unwanted higher precision results, etc.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>