<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 17, 2014 at 2:23 AM, Steve Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@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=":624" class="a3s" style="overflow:hidden">Apologies for delay in looking at this, I'm on vacation this week.<br></div></blockquote><div><br></div><div>Not a problem. =] </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":624" class="a3s" style="overflow:hidden">I don't love this approach because (a) it doesn't get us fully to where we want to be in performance, and (b) it's going to trash the floating-point flag state.  The performance issue is that we still have two comparisons and one or two branches for every <span class="il">complex</span> op outside of no-nans, and the flags issue is as follows:<br>
<br>
The intention of IEEE-754 is that anything that is conceptually a single "operation" should raise at most one of divide-by-zero, invalid, overflow, or underflow.  A <span class="il">complex</span> multiplication implemented with lazy checking may cause two of these to be raised:<br>
<br>
    (tiny, huge) * (tiny, huge) --> underflow + overflow<br>
    (0, huge) * (inf, huge) --> invalid + overflow, no flags<br>
<br>
My preferred approach would be to implement limited-range semantics as an option (via either pragma or flag), and have it implied by fast-math.<br></div></blockquote><div><br></div><div>I don't really understand what you want here.</div><div><br></div><div>In the case of fast-math, the comparisons should vanish and I think we're left with a minimal amount of math. If there is some more minimal way to compute the result in the case of fast-math, please let me know?</div><div><br></div><div>In the case of *not* have fast-math and needing to be correct, I'm just not in a position to come up with a more efficient but still numerically correct implementation. I have no idea how to do it. And I'm not really willing to sign up to do it because I don't have the time. =/ I don't think that hoping for a future better world should obstruct getting this into the tree as it (to the extent I'm aware) is a strict improvement on the status quo.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":624" class="a3s" style="overflow:hidden">
<br>
Now, all that being said, I haven't checked if today's compiler-rt implementations are even correct w.r.t. flags in this sense,</div></blockquote><div><br></div><div>So, the code I am generating here is *exactly* the code we have in compiler-rt. I don't know the first thing about actually implementing this stuff and am completely leveraging the compiler-rt implementation. I'm also not a numerics expert and not setting out to improve that implementation, but if you or anyone else have a better implementation, I'm all ears.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":624" class="a3s" style="overflow:hidden"> so it's not immediately obvious that this change makes anything worse today, and it will address //some// of the performance concerns of the earlier patch.</div></blockquote><div><br></div><div>I'm pretty sure this is essentially just inlining the code from compiler-rt around the call to the library function. =]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":624" class="a3s" style="overflow:hidden">It just seems contrary to the direction that we really want to be going in the longer-term w.r.t. numerical correctness.</div></blockquote></div><br>I don't really know that why this is less *correct*... but I'll take your word on it. However, I also think that this future you're describing is somewhat hypothetical really. Is there any hope of getting there? Is anyone working on it?</div></div>