Thanks to @pkofod we're quite close, but there are a couple of places left:
libm
in a few placescbrt
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L247-L253) #25948exp2
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L247-L253) #24859expm1
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L247-L253) #25903log2
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L431-L432) #27137log10
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L431-L432) #27137lgamma
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L431-L432)lgamma_r
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/special/gamma.jl#L13-L22)gamma
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/special/gamma.jl#L3-L4)rem
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L679-L682)modf
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/math.jl#L700-L710)fma
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/floatfuncs.jl#L278-L298) to deal with broken system libms (#9847)_ldexp_exp
](https://github.com/JuliaLang/julia/blob/46dcb35e1b92bf252aee078a90e42557b48376bc/base/special/hyperbolic.jl#L15-L16)SpecialFunctions.jl also calls a few:
erf
/erfc
](https://github.com/JuliaMath/SpecialFunctions.jl/blob/bcd566233c3c6008a23c4937363c7da8eea17fc5/src/erf.jl#L6-L9)besselj0
/besselj1
/bessly0
/bessely1
](https://github.com/JuliaMath/SpecialFunctions.jl/blob/7fd9f334ed89509c7b6bf1467729e5010b6d571c/src/bessel.jl#L152-L172)besselj
](https://github.com/JuliaMath/SpecialFunctions.jl/blob/7fd9f334ed89509c7b6bf1467729e5010b6d571c/src/bessel.jl#L338-L339)bessely
](https://github.com/JuliaMath/SpecialFunctions.jl/blob/7fd9f334ed89509c7b6bf1467729e5010b6d571c/src/bessel.jl#L358-L369)Aren't we also convincing LLVM to call Openlibm instead of the system libm?
Are we? I remember talking about it, but did we ever make that happen?
I can't find any reference to it in the source code so we are probably not doing that and I just remember the same discussion.
We could probably resolve the libcalls llvm will lower them to similar to what I am trying to do in #26381
Could we get them to resolve to specific Julia methods? That would be ideal.
Ideally we should figure out a generic mechanism to have LLVM request a function be constant folded with the implementation we have available in the compiler.
Speculating here, but it looks like it might be possible to use
setAvailableWithName
after using getLibFunc
http://llvm.org/doxygen/TargetLibraryInfo_8h_source.html to force a
particular triple to use a different version of a library function (and it
might even allow us to insert vectorised versions?)
Also see https://github.com/llvm-mirror/llvm/blob/master/tools/llc/llc.cpp#L472-L478
I have code for log2
, log10
, lgamma
and remainder
as well. I think _ldexp_exp
as well, but it is very short either way. I just havn't really prioritized making new PRs given that the existing ones are moving rather slowly, and I have some deadlines outside of OSS.
@pkofod If you get the chance I recommend just opening PRs with your changes, and if you need to be away for a while, someone who knows what they're doing can push to the branch with any necessary changes if applicable.
Regarding fastmath point, I have this PR still waiting for review: https://github.com/JuliaLang/julia/pull/24031. If it's good, I can add the missing functions
@pkofod Would you be able to push through your PRs?
Things like SpecialFunctions should be easy to update, and the fastmath could just fallback to the system libm initially perhaps?
What do you mean? If I can pr the remaining, or if the existing can be be finished soon ?
I was actually referring to bumping the existing ones if someone needs to review or do something about those. How far do you think we are from excising the remaining ones?
The above checklist with no check marks makes it look like none of this is done which I'm fairly sure it not the case at this point. @pkofod, would you mind updating the checkmarks here? Should be very satisfying since everyone knows that getting to check the boxes is why people make check lists.
Well, I think it might actually be quite accurate, as this was made after most of my prs were merged. The three open PRs are quite done as far as I remember, but I'm just waiting for feedback. I guess they have to be rebased by now, but I'd be happy to help get them merged asap to the extent that someone agrees to review. I'm on a quite tight time budget these months, so I can really only justify spending time on something that has a high chance of moving forward.
edit: Maybe I should clarify something. I know the potential people who could review the PRs are also busy, so this was not supposed to be me pointing fingers at anyone.
Let's tag folks who could help review and move things along. Perhaps @simonbyrne ?
I鈥檒l rebase the existing PRs so we have something to work off of
edit: they're rebased. I hope tests go through, and if they do, I suggest we do nanosoldier runs on them.
The thing I need help with the most is if people agree that the test sets are sufficient (coverage and correctness).
I can't edit @simonbyrne 's post, but https://github.com/JuliaLang/julia/pull/27137 covers log2 and log10
It would be nice to get the outstanding PRs merged. It seems that we are almost ready to do so in many cases.
I have code for
log2
,log10
,lgamma
andremainder
as well. I think_ldexp_exp
as well, but it is very short either way. I just havn't really prioritized making new PRs given that the existing ones are moving rather slowly, and I have some deadlines outside of OSS.
I found these two lines in the file base/special/hyperbolic.jl
_ldexp_exp(x::Float64, i::T) where T = ccall(("__ldexp_exp", libm), Float64, (Float64, T), x, i)
_ldexp_exp(x::Float32, i::T) where T = ccall(("__ldexp_expf",libm), Float32, (Float32, T), x, i)
but neither gnu libm.so.6 nor intel/2018.2.199 libimf.so has the functions __ldexp_exp and __ldexp_expf defined.
Does it mean v1.0.0 has to be built with openlibm?
Correct. Julia's build system builds and bundles openlibm. It's largely invisible to the user.
then it might be better to disable USE_INTEL_LIBM from Make.inc
Sorry, I misread. No it doesn't _have_ to be built with openlibm, but we strongly encourage it. Every USE_SYSTEM_*
flag for Make is effectively "use at your own risk."
I thought USE_INTEL_LIBM is to configure intel tools.
@einzigsue ah yes I can see why that would be an issue if you try to swap out the const libm
with some other libm that otherwise have all the functions we are calling using ccall. That鈥檒l be a priority to get out.
__ldexp_exp can be crossed off the list
SpecialFunctions.jl also calls a few
By the magic of BinaryBuilder/BinaryProvider, we can have SpecialFunctions pull in openlibm as needed without needing to assume it lives in Julia.
Most helpful comment
The above checklist with no check marks makes it look like none of this is done which I'm fairly sure it not the case at this point. @pkofod, would you mind updating the checkmarks here? Should be very satisfying since everyone knows that getting to check the boxes is why people make check lists.