Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for f32 and f64 methods in libcore #50145

Open
SimonSapin opened this issue Apr 21, 2018 · 11 comments

Comments

Projects
None yet
7 participants
@SimonSapin
Copy link
Contributor

commented Apr 21, 2018

#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

This comment has been minimized.

Copy link
Member

commented Apr 22, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 22, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

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,
@rkruppe

This comment has been minimized.

Copy link
Member

commented Apr 22, 2018

(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

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2018

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

@hellow554

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2019

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

@SimonSapin

This comment has been minimized.

Copy link
Contributor Author

commented Jan 17, 2019

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

@rkruppe

This comment has been minimized.

Copy link
Member

commented Jan 17, 2019

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

This comment has been minimized.

Copy link
Member

commented May 31, 2019

I believe this is also a problem for using the LLVM intrinsics for min and max on f32/f64 too (#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?

bors added a commit that referenced this issue Jun 2, 2019

Auto merge of #61384 - varkor:fmin-fmax-llvm-opt, r=alexcrichton
Update LLVM to include fmin/fmax optimisations

This will enable us to test if the optimisation issues mentioned in #18384 really are fixed. Unfortunately, using the intrinsics immediately is problematic due to the libcore/libstd split (see #50145).

bors added a commit that referenced this issue Jun 7, 2019

Auto merge of #61408 - varkor:fmin-fmax-llvm-intrinsics, r=alexcrichton
Use LLVM intrinsics for floating-point min/max

Resurrection of #46926, now that the optimisation issues are fixed. I've confirmed locally that #61384 solves the issues.

I'm not sure if we're allowed to move the `min`/`max` methods from libcore to libstd: I can't quite tell what the status is from #50145. However, this is necessary to use the intrinsics.

Fixes #18384.

r? @SimonSapin
cc @rkruppe @nikic
@varkor

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

As per #61408, we should be able to use LLVM intrinsics provided we make sure they're properly supported.

  1. Ensure the LLVM intrinsic lowers to a suitable libm call.
  2. Make sure Rust libm supports the function (add it if not).
  3. Make sure compiler-builtins uses a version of libm that supports the function (update it if not).
  4. Make sure the version of compiler-builtins in rustc supports it (update it if not).
    compiler_builtins = { version = "0.1.16" }
  5. Use the intrinsic in libcore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.