-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
more efficient muladd for complex/real operations #15980
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -74,15 +74,15 @@ macro evalpoly(z, p...) | |
ai = symbol("a", i) | ||
push!(as, :($ai = $a)) | ||
a = :(muladd(r, $ai, $b)) | ||
b = :(muladd(-s, $ai, $(esc(p[i])))) | ||
b = :($(esc(p[i])) - s * $ai) # see issue #15985 on fused mul-subtract | ||
end | ||
ai = :a0 | ||
push!(as, :($ai = $a)) | ||
C = Expr(:block, | ||
:(x = real(tt)), | ||
:(y = imag(tt)), | ||
:(r = x + x), | ||
:(s = x*x + y*y), | ||
:(s = muladd(x, x, y*y)), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This breaks the symmetry between There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. (Note that we are already rearranging the computation quite a bit compared to, say, Horner's rule. And |
||
as..., | ||
:(muladd($ai, tt, $b))) | ||
R = Expr(:macrocall, symbol("@horner"), :tt, map(esc, p)...) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should probably be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They are There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. to test that the return type stays that way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in de6468b |
||
end | ||
|
||
# issue #11839: type stability for Complex{Int64} | ||
let x = 1+im | ||
@inferred sin(x) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it was intentional. All of the benefit from the
muladd(Complex, Complex, Real)
case could be gained by usingmuladd
inComplex*Complex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this save one addition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eschnett, no, because there is already an addition in both the real and imaginary parts ofComplex*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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, added the
Complex*Complex
cases