more efficient muladd for complex/real operations #15980
Conversation
|
Here's an oddity. If I do Clearly, the optimizer is doing the right thing at the end, as indicated by |
stevengj
force-pushed
the
muladd_complex
branch
from
bacc7fe
to
413ffc7
Compare
| muladd(z::Complex, x::Real, y::Real) = Complex(muladd(real(z),x,y), imag(z)*x) | ||
| muladd(z::Complex, x::Real, w::Complex) = | ||
| Complex(muladd(real(z),x,real(w)), muladd(imag(z),x,imag(w))) | ||
| muladd(x::Real, y::Real, z::Complex) = Complex(muladd(x,y,real(z)), imag(z)) |
There was a problem hiding this comment.
This leaves out the case (Complex, Complex, Real). Is this intentional? If so, a comment might make sense.
There was a problem hiding this comment.
Yes, it was intentional. All of the benefit from the muladd(Complex, Complex, Real) case could be gained by using muladd in Complex*Complex
There was a problem hiding this comment.
Wouldn't this save one addition?
There was a problem hiding this comment.
@eschnett, no, because there is already an addition in both the real and imaginary parts of Complex*Complex that could be fused with one of the multiplications.
Oh wait, you're right; you could save an extra addition.
There was a problem hiding this comment.
Okay, added the Complex*Complex cases
stevengj
force-pushed
the
muladd_complex
branch
from
413ffc7
to
0794ba7
Compare
stevengj
force-pushed
the
muladd_complex
branch
from
0794ba7
to
c833e8e
Compare
| @@ -904,6 +904,11 @@ end | |||
| # issue #10926 | |||
| @test typeof(π - 1im) == Complex{Float64} | |||
|
|
|||
| # issue #15969: specialized muladd for complex types | |||
| for x in (3, 3+13im), y in (2, 2+7im), z in (5, 5+11im) | |||
| @test muladd(x,y,z) == x*y + z | |||
There was a problem hiding this comment.
They are Complex{Int} values, so what does it matter?
There was a problem hiding this comment.
to test that the return type stays that way
Fixes #15969, and corrects some efficiency problems in
@evalpolyintroduced in #9881.