don't inline float64^float64 #42966
don't inline float64^float64 #42966
Conversation
|
Seems like there's similar issues for the other methods of |
|
the float16 and float64 methods can be inlined since exp2 and log2 don't inline. float64 to integer is the other that I'm unsure about. |
|
I also think all of these forced inlines should be removed. There no way that is beneficial on the whole. You can always call site inline then if you really need. |
|
Any ideas how removing the inlining is causing tests to fail? That seems really weird to me. |
|
Inlineability is used as a constant-propagation heuristic. So I guess the same precision problem as reported in #41450 happens here as well ? |
|
theoretically, this should fix test failures and make |
|
@stevengj can you look at the |
Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
|
Remember the other |
base/intfuncs.jl
Outdated
| @@ -328,7 +331,11 @@ const HWNumber = Union{HWReal, Complex{<:HWReal}, Rational{<:HWReal}} | |||
| # be computed in a type-stable way even for e.g. integers. | |||
| @inline function literal_pow(f::typeof(^), x, ::Val{p}) where {p} | |||
| if p < 0 | |||
| literal_pow(^, inv(x), Val(-p)) | |||
| if x isa BitInteger64 | |||
| f(Float64(x), p) | |||
There was a problem hiding this comment.
Maybe add some comment on this? Is this to improve performance, accuracy, or both?
There was a problem hiding this comment.
Good idea. The reasoning is that computing inv(x)^(-p) rounds twice. Once to compute inv(x) and once to compute the power. Since the Float64^Float64 code works to half an ULP (even for negative numbers), we want to let that code handle the negative powers since it does so better.
|
I believe this is finally working correctly. This was a shockingly annoying change for something that should have been trivial. |
|
I'm going to merge this tonight if there aren't objections. |
Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
It was leading to too much code bloat. This code is slow enough that no noticeable slowdown is expected.