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

[Chandler Carruth]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141018/3d5d4f69/attachment.html>