[PATCH] [complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function.

[Stephen Canon]

On Oct 18, 2014, at 11:52 PM, Chandler Carruth <chandlerc at gmail.com> wrote:

> 
> On Fri, Oct 17, 2014 at 11:41 PM, Stephen Canon <scanon at apple.com> wrote:
> What I'm saying is that in the long-term, we'd like to support two modes for these operations:
> 
> 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 complex 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).
> 
> no-limited-range: We unconditionally call to compiler-rt for complex mul and div operations, and make the compiler-rt implementations correct w.r.t. flags.
> 
> 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.
> 
> Thanks, I understand better where you're asking to go.
> 
> 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.
> 
> 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.
> 
> If that doesn't seem achievable, then I agree, this patch may just be pushing us in the wrong direction.

Sounds reasonable to me.  Let's continue with this patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141019/97eb5d78/attachment.html>