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.
Introduce a Cargo feature to enable or disable architecture-specific
features (SIMD, assembly), which is on by default. This allows for more
fine grained control compared to relying on the `force-soft-floats`
feature.
Similar to "unstable-intrinsics", introduce a build.rs config option for
`unstable-intrinsics AND NOT force-soft-floats`, which makes this easier
to work with in code.
Effectively, this allows moving our non-additive Cargo feature
(force-soft-floats) to a positive one by default, allowing for an
override when needed.
`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.
Don't try to generate tests for directories, or for files that contain
`f16` or `f128` (as these types are not provided by musl's math
implementations).
(cherry picked from commit fd7ad36b70d0bbc0f0b9bc7e54d10258423fda29)
Having the default ULP in lib.rs doesn't make much sense when everything
else precision-related is in special_case.rs. Rename `special_case` to
`precision` and move the `*_allowed_ulp` functions there.
Add a way to call MPFR versions of functions in a predictable way, using
the `MpOp` trait.
Everything new here is guarded by the feature `test-multiprecision`
since MPFR cannot easily build on Windows or any cross compiled targets.
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".
CI for aarch64 Linux is significantly slower than the others. Adjust how
iteration selection is done to better handle this case, which also
simplifies things.
Also set the `EMULATED` environment variable in Docker to be more
accurate, and reindents run-docker.sh.
Check our functions against `musl-math-sys`. This is similar to the
existing musl tests that go through binary serialization, but works on
more platforms.
Sometimes we want to be able to xfail specific inputs without changing
the checked ULP for all cases or skipping the tests. There are also some
cases where we need to perform extra checks for only specific functions.
Add a trait that provides a hook for providing extra checks or skipping
existing checks on a per-function or per-input basis.
Create a new test that checks `for_each_fn` against `ALL_FUNCTIONS`,
i.e. the manually entered function list against the automatically
collected list. If any are missing (e.g. new symbol added), then this
will produce an error.
Use a build script for `libm-test` to enumerate all symbols provided by
`libm` and provide this list in a variable. This will allow us to make
sure no functions are missed anytime they must be manually listed.
Additionally, introduce some helper config options.
Introduce `libm_test::for_each_function`. which macro takes a callback
macro and invokes it once per function signature. This provides an
easier way of registering various tests and benchmarks without
duplicating the function names and signatures each time.
This crate builds math symbols from a musl checkout and provides a Rust
interface. The intent is that we will be able to compare our
implementations against musl on more than just linux (which are the only
currently the only targets we run `*-musl` targets against for
comparison).
Musl libc can't compile on anything other than Linux; however, the
routines in `src/math` are cross platform enough to build on MacOS and
windows-gnu with only minor adjustments. We take advantage of this and
build only needed files using `cc`.
The build script also performs remapping (via defines) so that e.g.
`cos` gets defined as `musl_cos`. This gives us more certainty that we
are actually testing against the intended symbol; without it, it is easy
to unknowingly link to system libraries or even Rust's `libm` itself and
wind up with an ineffective test. There is also a small procedure to
verify remapping worked correctly by checking symbols in object files.
* 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.
Currently everything we have runs with nightly Rust. Add a stable test
to make sure we don't accidentally make use of behavior that isn't yet
stable without gating it.
Duplicate the settings from rust-lang/rust to this repository. This is
mostly for consistency, but `use_small_heuristics = "Max"` does make a
large difference with lookup tables.
Also apply the needed CI changes to run nightly rustfmt.
