`bl!` is being used to add a leading underscore on Apple targets.
`asm_sym` has been around since 2022 and handles platform-specific
symbol names automatically, so make use of this instead.
I have verified that `armv7s-apple-ios` still builds correctly.
`libm` no longer uses this directly in `cfg`, it is only for setting
other configuration in the `libm` `build.rs`. Clean up this
configuration in `compiler-builtins` since it is unused.
* Delete some memcpy tests that were a bit excessive
* Always use the same offset of 65
* Add a memmove test with aligned source and destination
* Improve printing output and add more comments
* Use a constant for 1 MiB so it shows up in the benchmark logs
This crate [1] makes it reasonably easy to get instruction count
performance metrics that are stable enough to run in CI, and has worked
out well since integrating it with `libm`. Add new benchmarks for `mem`
functions using `iai-callgrind`, modeling them off of the existing
benchmarks.
[1]: https://github.com/iai-callgrind/iai-callgrind
The current setup has the `Cargo.toml` for `compiler-builtins` at the
repository root, which means all support crates and other files are
located within the package root. This works for now but is not the
cleanest setup since files that should or shouldn't be included in the
package need to be configured in `Cargo.toml`. If we eventually merge
`libm` development into this repository, it would be nice to make this
separation more straightforward.
Begin cleaning things up by moving the crate source to a new
`compiler-builtins` directory and adding a virtual manifest. For now the
`libm` submodule is also moved, but in the future it can likely move
back to the top level (ideally `compiler-builtins/src` would contain a
symlink to `libm/src/math`, but unfortunately it seems like Cargo does
not like something about the submodule + symlink combination).
Currently there is an interesting situation with the way features get
enabled; `testcrate` enables `mangled-names`, but the `intrinsics.rs`
example requires this feature be disabled (otherwise the test fails with
missing symbols, as expected). This is also the reason that `testcrate`
is not a default workspace member, meaning `cargo test` doesn't actually
run `testcrate`'s tests; making it a default member would mean that
`compiler-builtins/mangled-names` gets enabled when
`examples/intrinsics.rs` gets built, due to the way features get
unified.
Simplify the situation by making moving the example to its own crate as
`builtins-test-intrinsics`. This also means `testcrate` can become a
default member so it is included in `cargo check` or `cargo test` when
run at the workspace root.
`testcrate` and `builtins-test-intrinsics` still can't be built at the
same time since there isn't a straightforward way to have Cargo build
`compiler-builtins` twice with different features. This is a side effect
of us using non-additive features, but there isn't really a better
option since enabling both mangled and unmangled names would render
`builtins-test-intrinsics` useless.
It seems like "sign" was used as a shortened version of "significand",
but that is easy to confuse with "sign". Update these to use "sig" like
most other places.
The fix to this issue was synced in [1] so we should no longer need to
keep aarch64 pinned.
This reverts commit b2bcfc838e2a4b72fa62b333e3eb91f250aa4539.
[1]: https://github.com/rust-lang/rust/pull/137661
Since we have a handful of different float-related configuration in
testcrate, track a list of which are implied by others rather than
repeating the config.
LLVM doesn't seem to emit this intrinsic but it probably should, in some
cases it lowers f16->f64 conversions as f16->f32->f64 with two libcalls.
GCC provides this intrinsic so it is good to have anyway.
Additionally, add a test for f64->f16 which was missing.
[1]: https://rust.godbolt.org/z/xezM9PEnz
There is an LLVM regression that breaks some `f16`-related code when
`fp-armv8` is disabled [1]. Since Rust ties that feature to `neon`,
disable `f16` if `neon` is not available.
[1]: https://github.com/llvm/llvm-project/issues/129394
018616e78b ("Always have math functions but with `weak` linking
attribute if we can") made all math symbols available on platforms that
support weak linkage. This caused some unexpected regressions, however,
because our less accurate and sometimes slow routines were being
selected over the system `libm`, which also tends to be weak [1]. Thus,
0fab77e8d7 ("Don't include `math` for `unix` and `wasi` targets") was
applied to undo these changes on many platforms.
Now that some improvements have been made to `libm`, add back a subset
of these functions:
* cbrt
* ceil
* copysign
* fabs
* fdim
* floor
* fma
* fmax
* fmaximum
* fmin
* fminimum
* fmod
* rint
* round
* roundeven
* sqrt
* trunc
This list includes only functions that produce exact results (verified
with exhaustive / extensive tests, and also required by IEEE in most
cases), and for which benchmarks indicate performance similar to or
better than Musl's soft float math routines [^1]. All except `cbrt` also
have `f16` and `f128` implementations. Once more routines meet these
criteria, we can move them from platform-specific availability to always
available.
Once this change makes it to rust-lang/rust, we will also be able to
move the relevant functions from `std` to `core`.
[^1]: We still rely on the backend to provide optimized assmebly
routines when available.
[1]: https://github.com/rust-lang/rust/issues/128386
This requires privately reexporting `libm`'s `support` module at crate
root, where it is expected for macros. Once `libm` is made always
available, the reexport can be simplified.
This delta adds a lot of routines to `f16` and `f128`:
* ceil
* floor
* fma (f128 only)
* fmax
* fmin
* fmod
* ldexp
* rint
* round
* scalbn
* sqrt
Additionally, the following new API was added for all four float types:
* fmaximum
* fmaximum_num
* fminimum
* fminimum_num
* roundeven
There are also some significant performance improvements for `sqrt` and
`sqrtf`, as well as precision improvements for `cbrt` (both `f32` and
`f64` versions of this function are now always correctly rounded).
Replace `public_test_dep!` by placing optionally public items into new
modules, then controlling what is exported with the `public-test-deps`
feature.
This is nicer for automatic formatting and diagnostics.
This is a reland of 2e2a9255 ("Eliminate the use of
`public_test_dep!`"), which was reverted in 47e50fd2 ('Revert "Eliminate
the use of..."') due to a bug exposed at [1], reapplied in d4abaf4efa
because the issue should have been fixed in [2], then reverted again in
f6eef07f53 because [2] did not actually fix the issue.
[3] has landed in rust-lang/rust since then, which should resolve the
last problem remaining after [2]. So, apply this change for what is
hopefully the final time.
[1]: https://github.com/rust-lang/rust/pull/128691
[2]: https://github.com/rust-lang/rust/pull/135278
[3]: https://github.com/rust-lang/rust/pull/135501
