Tracking issue for f32 and f64 methods in libcore

[SimonSapin]

#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]

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]

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]

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

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]

(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]

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

[hellow554]

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

[SimonSapin]

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