In preparation of adding generic algorithms to `libm`, add the traits
from `compiler-builtins`.
Eventually we should be able to unify the two crates so we don't have
duplicate implementations.
`cfg_if` is helpful for applying `cfg` attributes to groups of items,
like we will need to do with architecture-specific modules of `f16` and
`f128`. However, `libm` can't have dependencies.
The `cfg_if` macro is complex but small, so just vendor it here.
Currently there is a macro called `llvm_intrinsically_optimized` that
uses an intrinsic rather than the function implementation if the
configuration is correct. Add a new macro `select_implementation` that
is somewhat cleaner to use.
In the future, we can update this macro with more fields to specify
other implementations that may be selected, such as something
architecture-specific or e.g. using a generic implementation for `f32`
routines, rather than those that convert to `f64`.
This introduces a `macros` module within `math/support`. We will be able
to move more things here later.
This module provides implementations of basic functions that defer to
LLVM for what to do, rather than either using a builtin operation or
calling another function in this library.
`math::arch` will become the home of anything architecture-specific in
the future.
We currently have a non-additive feature, "force-soft-floats", and we
will need to gain another "no-f16-f128". This makes `cfg` usage in code
somewhat confusing and redundant.
Use `build.rs` to figure out if "unstable-intrinsics" is enabled while
"force-soft-floats" is not enabled and if so, emit a cfg
`intrinsics_enabled`. This is cleaner to use and should make adding more
features easier to reason about.
Also use this as an opportunity to eliminate the build.rs from the
compiler-builtins test crate, replaced with the `[lints]` table in
Cargo.toml.
Currently there is a single feature called "unstable" that is used to
control whether intrinsics may be called. In anticipation of adding
other unstable features that we will want to control separately, create
a new feature called "unstable-intrinsics" that is enabled by
"unstable". Then move everything gated by "unstable" to
"unstable-intrinsics".
* Add docstring to Bessel functions
* Add docstrings to logarithm functions
* Add docstrings to pow functions
* Specify argument bit-size of the Bessel functions
* Specify argument bit-size for pow functions
* Specify argument bit-size for logarithms
* Add docstrings to sin, cos, sincos and sinh functions
* Add docstrings to sqrt
* Add docstrings to tan and tanh functions
* Add an inline link to https://en.wikipedia.org/wiki/Bessel_function to the docstrings of all Bessel functions.
Having `#![deny(warnings)]` for the entire crate is a bit of a
development annoyance. We already run CI with `RUSTFLAGS=-Dwarnings` so
there isn't much of a reason to check this locally. Thus, remove the
attribute.
Additionally, sort the clippy allows.
There isn't any reason for this feature to be exposed or part of the
build script. Move it to a separate crate.
We will also want more tests that require some support functions; this
will create a place for them.
Using to_bits/from_bits to force conversion to storage format
apparently doesn't work in release mode. Also add an architecture
conditional to avoid pessimising other architectures.
