<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Oct 18, 2014, at 11:52 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 11:41 PM, Stephen 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>What I'm saying is that in the long-term, we'd like to support two modes for these operations:</div><div><br></div><div>limited-range: In this mode, we use the simple "usual" mathematical formulations for multiplication and division (no careful handling of overflow or underflow or invalid cases). This is like finite-math restricted to <span class="il">complex</span> arithmetic expressions (in particular, we don't want to require users enable finite-math to get this behavior; we may want this behavior to be the default).</div><div><br></div><div>no-limited-range: We unconditionally call to compiler-rt for <span class="il">complex</span> mul and div operations, and make the compiler-rt implementations correct w.r.t. flags.</div><div><br></div><div>The current state of affairs is similar to supporting only no-limited-range, except that the compiler-rt implementations may need to be fixed up (I'm happy to do that work). This patch puts us somewhere in between the two modes, which is a better place for most users, but still slightly worse than where I'd really like to be headed.</div></blockquote><div><br></div><div>Thanks, I understand better where you're asking to go.</div><div><br></div><div>I think what I would suggest is that whatever fixes are needed for flags in the compiler-rt implementation are also applied to the "inlined" bit of code, and that we still generate a little bet of inline code in no-limited-range and branch to the library call only when complex logic will be required. My hope is that both the compiler-rt implementation and this inlined bit of logic can be fixed w.r.t. flags and we can allow the common case to not go through an actual libcall in no-limited-range.</div><div><br></div><div>Does that make sense or seem achievable? If so, then I think this patch is an OK first step, and whenever we start pushing on fixes for flags, we apply them to both compiler-rt and this code.</div><div><br></div><div>If that doesn't seem achievable, then I agree, this patch may just be pushing us in the wrong direction.</div></div></div></div>
</blockquote></div><br><div>Sounds reasonable to me. Let's continue with this patch.</div></body></html>