<div dir="ltr">On Sat, Apr 27, 2013 at 7:26 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/26/2013 04:20 PM, Owen Anderson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Apr 26, 2013, at 3:07 PM, Sergei Larin <<a href="mailto:slarin@codeaurora.org" target="_blank" class="cremed">slarin@codeaurora.org</a><br></div>
<mailto:<a href="mailto:slarin@codeaurora.org" target="_blank" class="cremed">slarin@codeaurora.org</a>><u></u>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Dan,<br>
Thank you for the quick and throughout reply. First paragraph pretty<br>
much sums it up. Unless there is more will to guaranty (or provide<br>
under flag) stricter version of IEEE adherence, I doubt much can be done.<br></div>
So all of you with picky customers out thereJIs there anyone else that<div class="im"><br>
would be concerned about this problem in any of it potential forms?<br>
</div></blockquote><div class="im">
<br>
I have the opposite problem. I have customers who call libm functions<br>
with constants (or their LLVM intrinsic equivalents) are get very angry<br>
if they don't get constant folded, and they're not picky at all about<br>
the precision.<br>
</div></blockquote>
<br>
I just want LLVM to behave the same on whatever platform it's run on. People already accept that depending on iteration order is a bug, but it's been harder to get people to accept that llvm needs bit-exact floating point constant folding, especially given the implementation difficulty.<br>
</blockquote><div><br></div><div style>I'll give a huge +1 to this.</div><div style><br></div><div style>I think that long-term LLVM should, out of the box, support strictly correct (according to IEEE) floating point folding outside of fast-math, and should provide aggressive as hell folding inside of fast-math.</div>
<div style><br></div><div style>As Owen points out rightly, it would be important to provide flags to enable just the amount of folding that users have today and expect to keep, preferably as some rational subset of fast math.</div>
<div><br></div><div style>However, I don't think either aggressive folding in fast-math or conservative behavior by default is nearly as important as what Nick pointed out: we should not under any circumstances expose the output of the optimizer to the whims of the host's FP. Even if we can write code to get deterministic results out of the host's FP unit (maybe, but hard and a huge maintenance burden), and even if the host's FP unit actually gives us deterministic results (questionable on some older chips), I most certainly don't want to assume that the host *compiler* will actually handle LLVM's host FP code correctly, especially given the current quality of LLVM's own optimizer for such code! =/ We should insulate ourselves from such concerns completely.</div>
</div></div></div>