Tracking issue for f32 and f64 methods in libcore

SimonSapin commented 6 years ago

https://github.com/rust-lang/rust/pull/49896 removes from libcore (and moves to libstd) three methods of f32 and f64 (that were only usable through the unstable trait core::num::Float) because they’re implemented by calling LLVM intrinsics, and it’s not clear whether those intrinsics are lowered on any platform to calls to C’s libm or something else that requires runtime support that we don’t want in libcore:

abs: calls llvm.fabs.f32 or llvm.fabs.f64
signum: calls llvm.copysign.f32 or llvm.copysign.f64
powi: calls llvm.powi.f32 or llvm.powi.f32

The first two seem like they’d be easy to implement in a small number of lower-level instructions (such as a couple lines with if, or even bit twiddling based on IEEE 754). abs in particular seems like a rather common operation, and it’s unfortunate not to have it in libcore.

The compiler-builtins crate has Rust implementations of __powisf2 and __powidf2, but in LLVM code those are only mentioned in lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp so I haven’t found evidence that llvm.powi.f32 and llvm.powi.f32 call those functions.

PR #27823 “Remove dependencies on libm functions from libcore” similarly moved a number of other f32 and f64 methods to libstd, but left these three behind specifically. (And unfortunately doesn’t discuss why.)

Maybe it’s fine to move them back in libcore? (As inherent methods, assuming #49896 lands.)

CC @alexcrichton

alexcrichton commented 6 years ago

If we provide the fallback implementations in compiler-builtins I'd be fine moving these to libcore, but otherwise I'd personally prefer that they remain in std. I think the implementations in compiler-builtins may not be too bad though?

Amanieu commented 6 years ago

We could consider supporting all the math functions in compiler-builtins by essentially treating them the same way as memcpy: it's a required symbol, and we will provide a default implementation if you don't have one.

There no reason any of these functions (cos, tanh, etc) require anything outside of core, and it would eliminate the std/core split for floating-point types.

SimonSapin commented 6 years ago

@Amanieu We certainly can consider that, but what I had in mind for this issue is starting for example with with powi where it looks like we already have an implementation in compiler-builtins. I just couldn’t figure out so far if/how we end up actually using it.

Amanieu commented 6 years ago

Regarding __powisf2, here is what I got from a grep of LLVM:

include/llvm/CodeGen/RuntimeLibcalls.def
118:HANDLE_LIBCALL(POWI_F32, "__powisf2")

lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
4141:    Results.push_back(ExpandFPLibCall(Node, RTLIB::POWI_F32, RTLIB::POWI_F64,

hanna-kruppe commented 6 years ago

(Most) trigonometric and transcendental functions are far from trivial, especially if you want at all reasonable accuracy and performance (if not, people would -- rightly! -- avoid the libcore implementations or use them and find them unsatisfactory, defeating the purpose of providing them). They can be supported in a core-only environment in principle, but unless and until someone puts in the work to actually implement them, that's pie in the sky.

vks commented 6 years ago

The three functions mentioned here (abs, signum, powi) are almost trivial to implement in pure Rust though (see num_traits).

hellow554 commented 5 years ago

9 months gone. Any reason why it hasn't implemented yet for those three functions?

SimonSapin commented 5 years ago

@vks Only having Rust implementations of those functions is certainly a possibility. But since LLVM intrinsics exist, should we try to use them? Maybe some architecture have dedicated instructions that can be faster?

On the other hand, can we rely on those intrinsics to be available for all targets, even when libm is not linked?

@hellow554 The reasons is that (as far as I know) we don’t yet have a clear answer to the questions above. Counting months is irrelevant, answers/solutions do now grow by themselves.

hanna-kruppe commented 5 years ago

The LLVM intrinsics exist on every target, but many (all?) targets lower them to libm function calls. They are intrinsics mostly to facilitate optimizations, I believe.

Which leads to another potential problem: if we implement these in Rust, might LLVM optimizations canonicalize them to calls to the intrinsics? This is certainly a problem for other functions/intrinsics like memcpy, memset, etc. and although those problems can be solved with #![no_builtins], AFAIK that situation is subtly different than with the libm functions.

varkor commented 5 years ago

I believe this is also a problem for using the LLVM intrinsics for min and max on f32/f64 too (https://github.com/rust-lang/rust/issues/18384), as they reside in libcore.

Edit: though am I understanding correctly that it's non-breaking to move a floating-point method from libcore to libstd?

varkor commented 5 years ago

As per https://github.com/rust-lang/rust/pull/61408, we should be able to use LLVM intrinsics provided we make sure they're properly supported.

Ensure the LLVM intrinsic lowers to a suitable libm call.
Make sure Rust libm supports the function (add it if not).
Make sure compiler-builtins uses a version of libm that supports the function (update it if not).
Make sure the version of compiler-builtins in rustc supports it (update it if not). https://github.com/rust-lang/rust/blob/a73ecb3d9c432f8f53117b1a6b6c209dc802dee7/src/libstd/Cargo.toml#L22
Use the intrinsic in libcore.

Lokathor commented 5 years ago

@varkor So I've been working on sqrt the past day or two.

1) lowers to sqrt / sqrtf 2) supported by libm 3) not 100% exposed by compiler-builtins

But once the compiler-builtins issue gets resolved can we put sqrt in core?

Lokathor commented 5 years ago

Update (see the above issue that references here): compiler-builtins needs no adjustment to support sqrt in core since LLVM will never itself emit a call to sqrt, so compiler-builtins and/or libm already has all bases covered.

How shall we proceed? Is this an RFC level change, or do we just PR to libcore and have T-libs approve it?

varkor commented 5 years ago

You should be able to simply open a PR, now that precedent has been set. I'd cc @alexcrichton in the PR.

Lokathor commented 5 years ago

I suspect this will be much trickier than the small PRs I've done in the past, but I will attempt to get us started today or tomorrow.

frewsxcv commented 4 years ago

For those that need to work around this issue, you may be interested in the ieee754 crate which offers no_std floating point operations. https://crates.io/crates/ieee754

Urgau commented 2 years ago

To help this issue I've conduct a little experiment with compiler-explorer (godbolt) which consist of compiling the llvm intrinsics for every target that rust supports:

core::intrinsics::fabsf64: No calls to libm or any another functions.
core::intrinsics::copysignf64: No calls to libm or any another functions.
core::intrinsics::powf64: Always call libm, :-(

I think it's pretty safe to say that given the current situation fabsf64 and copysignf64 never call's libm.

Given this I would be willing to make a PR to move those functions back to core but I'm not sure this proves anything or that it will be usefull.

Amanieu commented 2 years ago

I don't think such a PR would be accepted. A better solution would be to properly support all math functions in core by providing them in compiler-builtins as weak functions.

cc @Lokathor who may have some thoughts on this.

Lokathor commented 2 years ago

my understanding is that compiler-builtins is a deliberately minimal and "as needed" type of crate right now, rather than exhaustively providing all things.

Well it's trivial to copy the sign bit or clear the sign bit. LLVM can seemingly do that much on its own without ever asking for help. This assumes IEEE floats, but Rust already assumes that.

powf, not so much, I suspect that llvm will always need to call a libm here.

So I'm not against putting all functions into compiler-builtins all the time as float support in core is expanded, just so long as we're willing to recognize and document that llvm is exceedingly unlikely to ever call particular functions (and we provide them anyway just in case).

Amanieu commented 2 years ago

I just reviewed the past issues in compiler-builtins regarding support for weak functions, and here is what I propose we do:

Only provide libm functions and mem* functions on platforms that support weak symbols. Currently this is all ELF platforms. Non-ELF platforms must provide these functions from the OS libc. Currently non-ELF platforms are windows and darwin, so this shouldn't be a problem in practice.
Expose a libm Cargo feature (similar to the existing mem feature) to always export these functions as non-weak symbols, on all targets.

Once this is done, we should have the necessary symbols available on all targets which would allow moving the f32 and f64 methods into libcore.

mati865 commented 2 years ago

Technically LLVM supports using weak symbols on Windows, at least in mingw-w64 mode it works good. The problem is it requires whole comdat.

lvella commented 1 year ago

Do we need an RFC for this or a PR is sufficient?

RalfJung commented 2 weeks ago

Cc @eduardosm

RalfJung commented 2 weeks ago

abs and copy_sign have pretty trivial implementations, so it seems odd that LLVM would even require a compiler-builtins implementation for them -- and from the experiments conducted above, it seems like indeed it does not require a compiler-builtins implementation. So what's preventing us from moving them to core?

I think they should be considered separately from other functions that actually require a non-trivial implementation, like pow or sqrt.

tgross35 commented 2 weeks ago

I think it is also okay to move powi at this time since it is an intrinsic provided by libgcc or compiler-rt that we provide as a fallback via compiler-builtins - all of this is pretty well tested with no_std. The other math functions require some more work in our libm (something I am working on).

scottmcm commented 2 weeks ago

I think they should be considered separately from other functions that actually require a non-trivial implementation, like pow or sqrt.

IEEE 754 has a separate section "5.5.1 Sign bit operations" for copy/negate/abs/copySign, and they have extra freedom:

These operations may propagate non-canonical encodings.

Similarly, B.3 notes that negate, abs, and copySign are generally silent even on signalling NaNs.

So very much agreed for everything in that section, Ralf. It's like those ones are written intentionally to not need to think about most of the float complications, and to allow us to just do the integer implementation.

I think the "well we wrote it already" cases should be considered separately, Trevor. I think the sign-bit operations are fundamentally different from the others, in more than them already-working.

RalfJung commented 2 weeks ago

It's like those ones are written intentionally to not need to think about most of the float complications, and to allow us to just to the integer implementation.

Yes, exactly. They are also called out in the docs as "non-arithmetic operations", and they are the only non-arithmetic operations that are not in core.

tgross35 commented 2 weeks ago

I think the "well we wrote it already" cases should be considered separately, Trevor. I think the sign-bit operations are fundamentally different from the others, in more than them already-working.

Well not literally the exact same PR :) just as far as how powi winds up being made available, it is more similar to softfloat mul/div than it is to most of the other math functions.

RalfJung commented 2 weeks ago

I made a PR to move abs, copysign, signum to libcore: https://github.com/rust-lang/rust/pull/131304.

rust-lang / rust

Tracking issue for f32 and f64 methods in libcore #50145