Remove openlibm

[simonbyrne]

Thanks to @pkofod we're quite close, but there are a couple of places left:

• fastmath.jl still calls the libm in a few places
• cbrt Add Julia port of cbrt from Openlibm. #25948
• exp2 Add exp2 port of Openlibm exp2. #24859
• expm1 Julia port of Openlibm expm1. #25903
• log2 Replace log2 and log10 with Julia ports. #27137
• log10 Replace log2 and log10 with Julia ports. #27137
• rem Implement rem(float, float, RoundNearest) in Julia #42380
• modf Implement modf in Julia #42392
• fma to deal with broken system libms (test/numbers.jl fails on 32-bit platform #9847)
• _ldexp_exp

SpecialFunctions.jl also calls a few. Note however that SpecialFunctions now uses OpenLibm_jll and no longer relies on Julia providing openlibm.

• lgamma
• lgamma_r
• gamma
• erf/erfc
• besselj0/besselj1/bessly0/bessely1
• besselj
• bessely

[vchuravy]

Aren't we also convincing LLVM to call Openlibm instead of the system libm?

[simonbyrne]

Are we? I remember talking about it, but did we ever make that happen?

[vchuravy]

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

[simonbyrne]

Could we get them to resolve to specific Julia methods? That would be ideal.

[Keno]

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.

[vchuravy]

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

[pkofod]

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.

[ararslan]

@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.

[giordano]

Regarding fastmath point, I have this PR still waiting for review: #24031. If it's good, I can add the missing functions

[ViralBShah]

@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?

[pkofod]

What do you mean? If I can pr the remaining, or if the existing can be be finished soon ?

[ViralBShah]

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?

[StefanKarpinski]

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.

[pkofod]

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.

[ViralBShah]

Let's tag folks who could help review and move things along. Perhaps @simonbyrne ?

[pkofod]

I’ll 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.

[pkofod]

The thing I need help with the most is if people agree that the test sets are sufficient (coverage and correctness).

[pkofod]

I can't edit @simonbyrne 's post, but #27137 covers log2 and log10

[ViralBShah]

It would be nice to get the outstanding PRs merged. It seems that we are almost ready to do so in many cases.

[einzigsue]

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.

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?

[ararslan]

Correct. Julia's build system builds and bundles openlibm. It's largely invisible to the user.

[einzigsue]

then it might be better to disable USE_INTEL_LIBM from Make.inc

[ararslan]

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."

[einzigsue]

I thought USE_INTEL_LIBM is to configure intel tools.

[pkofod]

@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’ll be a priority to get out.

[pkofod]

__ldexp_exp can be crossed off the list

[oscardssmith]

I believe your summary is about right. _ldexp_exp no longer exists in Base though. I believe the old exp implementations needed it, but it was removed from 1.6. rem and modf should be pretty easy to port. fma will be harder. I believe that this list is currently missing pow, which I am planning on replacing soon.

[ViralBShah]

fma only uses openlibm on 32-bit I thought.

[oscardssmith]

What about arm architectures that don't have native fma instructions?

[ViralBShah]

Doesn't llvm do something there, like fallback to the non-fma version or something? I mean having openlibm does not solve that problem anyways, right?

[oscardssmith]

I'm not the right person to ask here. I've done pretty much all my work assuming 64 bit x86...

[ViralBShah]

I'll submit a PR that removes openlibm, and we'll see where it goes.

[ViralBShah]

As seen in #42299 Linux32 seems to have a lot of failures when not using openlibm. It seems that we should move remainder, modff and fma to avoid openlibm before we can excise it.

[KristofferC]

The fma bug that is linked to #9847 was fixed in 2014: https://sourceware.org/bugzilla/show_bug.cgi?id=16064. I wonder if it is still relevant.

[ViralBShah]

fma is the last issue to remove openlibm from base. #42299 (comment)

Can we count on llvm to provide the right version always? @vchuravy perhaps may know.

[oscardssmith]

I'll take a look at a native Julia version by next weekend. If we want Julia to do it, we do need to figure out how to do the versioning.

[ararslan]

I started on a native implementation of fma based on msun but haven't got it finished, cleaned up, and/or properly tested. Don't let that stop you though, Oscar, if you wanted to have a go at it.

[simonbyrne]

Or we could tell people to use a glibc that is newer than 6 years old?

[StefanKarpinski]

Can we emulate FMA with compensated arithmetic?

[StefanKarpinski]

[He says, then realizing he has no idea how to do compensated multiplication]

[simonbyrne]

Yes, but FMAs are notoriously difficult to get right for all the edge cases. A simpler idea is to just call the fma function, and manually reset the rounding mode each time (#42961): since this is just to deal with very old 32-bit linux installations, it seems like the simplest option.

[KristofferC]

I thought we already merged FMA though: #42783?

[oscardssmith]

yeah. it is a total pain to get right, but we now have it in Base.

[simonbyrne]

Oh, or we could do that...

[PallHaraldsson]

fma is the last issue to remove openlibm from base. #42299 (comment)

I thought we already merged FMA though: #42783?

Can't we just remove openlibm, and ditch those users, without fma hardware (or force to use LTS or 1.8 for a little longer)? Or use the emulated one? [Or if it matters copy those two C functions from libm?]

FMA3 is supported in AMD processors starting with the Piledriver architecture and Intel starting with Haswell processors and Broadwell processors since 2014.

I think it may be actually CPUs older than June 2013, so 9+ years old.

What about arm architectures that don't have native fma instructions?

https://developer.arm.com/documentation/dui0491/g/Compiler-specific-Features/Fused-Multiply-Add--FMA--intrinsics

They are only supported for the Cortex-A5 and Cortex-M4 processors.

ARM Cortex-A5 with fma was announced in 2009.

EDIT:

fma turns out to just be badly broken on windows without hardware fma, and @oscardssmith will be posting a detailed issue around it. It was also always broken on 1.6.3.

That seems to be an argument for not using (its) libm, rather dropping those users (or copy those C libm functions, as stated above, from Linux libm, should work on Windows?).

I went looking if Python supports fma, and found it planned for 3.7, issue still open, they link to Go implementation and have one in Python too:
smasher164/fma@4e85d23

It has been hand-optimized to benefit from branch prediction, and
outperforms MUSL by ~5ns for RNE.

https://bugs.python.org/issue29282
https://bugs.python.org/file46304/fma_reference.py

The IEEE 754-2008 specification leaves one FMA corner case to the
implementation: namely whether the cases zero * infinity + nan and
infinity * zero + nan return nan or raise an invalid operation FPE.

By default, this implementation follows Intel's x64 FMA3 implementation,
which returns NaN in these cases. If corner_case_raises is True,
then this corner case raise ValueError instead

[StefanKarpinski]

It kind of looks like Base Julia doesn't need to depend on OpenLibm anymore? At least based on the checkmark list at the top. Is that the case now? (@oscardssmith, @simonbyrne)

[oscardssmith]

See #42299