Distribute everything from `libm/` to better locations in the repo.
`libm/libm/*` has not moved yet to avoid Git seeing the move as an edit
to `Cargo.toml`.
Files that remain to be merged somehow are in `etc/libm`.
Absorb the libm repository into `compiler-builtins`.
This was done using `git-filter-repo` to ensure hashes mentioned in
commit messages were correctly rewritten, I used the same strategy to
merge `ctest` into `libc` [1] and it worked quite well. Approximately:
# `git filter-repo` requires a clean clone
git clone https://github.com/rust-lang/libm.git
# Move all code to a `libm` subdirectory for all history
git filter-repo --to-subdirectory-filter libm
# The default merge messages are "merge pull request #nnn from
# user/branch". GH links these incorrectly in the new repo, so
# rewrite messages from `#nnn` to `rust-lang/libm#nnn`.
echo 'regex:(^|\s)(#\d+)==>\1rust-lang/libm\2' > messages.txt
git filter-repo --replace-message messages.txt
# Re-add a remote and push as a new branch
git remote add upstream https://github.com/rust-lang/libm.git
git switch -c merge-into-builtins-prep
git push --set-upstream upstream merge-into-builtins-prep
# Now in a compiler-builtins, add `libm` as a remote
git remote add libm https://github.com/rust-lang/libm.git
git fetch libm
# Do the merge that creates this commit
git merge libm/merge-into-builtins-prep --allow-unrelated-histories
The result should be correct git history and blame for all files, with
messages that use correct rewritten hashes when they are referenced.
There is some reorganization and CI work needed, but that will be a
follow up.
After this merges I will need to push tags from `libm`, which I have
already rewritten to include a `libm-` prefix. Old tags in
compiler-builtins should likely also be rewritten to add a prefix (we
already have this for newer tags), but this can be done at any point.
* Original remote: https://github.com/rust-lang/libm.git
* Default HEAD: c94017af75c3ec4616d5b7f9b6b1b3826b934469 ("Migrate all
crates except `libm` to edition 2024")
* HEAD after rewriting history: 15fb6307f6dc295fb965d1c4f486571cc18ab6b3
("Migrate all crates except `libm` to edition 2024")
[1]: https://github.com/rust-lang/libc/pull/4283#issuecomment-2773986492
Prepare for having the repositories combined by ensuring EMULATED,
RUST_BACKTRACE, and CI are set or forwarded as applicable. Also
re-indent the file to four spaces and do some reorganization.
Apply a handful of changes to reduce the diff between the two:
* Cancel running jobs on new pushes
* Enable log color and backtraces
* Add timeouts
* Specify CI runner versions
* Add an armv7 job
* Replace the name NO_STD with BUILD_ONLY
* Update the extension to the canonical .yaml
* Set AR_ and CC_ environments in docker
* Install requirements to build MPFR
Unfortunately this means we lose use of the convenient name `gen`, so
this includes a handful of renaming.
We can't increase the edition for `libm` yet due to MSRV, but we can
enable `unsafe_op_in_unsafe_fn` to help make that change smoother in the
future.
Move the workspace configuration to a virtual manifest. This
reorganization makes a more clear separation between package contents
and support files that don't get distributed. It will also make it
easier to merge this repository with `compiler-builtins` which is
planned (builtins had a similar update done in [1]).
LICENSE.txt and README.md are symlinkedinto the new directory to ensure
they get included in the package.
[1]: https://github.com/rust-lang/compiler-builtins/pull/702
In preparation for switching to a virtual manifest, move the `libm`
crate into a subdirectory and update paths to match.
Updating `Cargo.toml` is done in the next commit so git tracks the moved
file correctly.
Benchmarks for [1] seemed to indicate that repository organization for
some reason had an effect on performance, even though the exact same
rustc commands were running (though some with a different order). After
investigating more, it appears that dependencies may have an affect on
inlining thresholds for generic functions.
It is surprising that this happens, we more or less expect that public
functions will be standalone but everything they call will be inlined.
To help ensure this, mark all generic functions `#[inline]` if they
should be merged into the public function.
Zulip discussion at [2].
[1]: https://github.com/rust-lang/libm/pull/533
[2]: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Dependencies.20affecting.20codegen/with/513079387
Since `fmod` is generic, there isn't any need to have the small wrappers
in separate files. Most operations was done in [1] but `fmod` was
omitted until now.
[1]: https://github.com/rust-lang/libm/pull/537
The reorganization PR has caused this to fail once before because every
file shows up as changed. Increase the timeout so this doesn't happen.
We now cancel the job if too many extensive tests are run unless `ci:
allow-many-extensive` is in the PR description, so this helps prevent
the limit being hit by accident.
Error out when too many extensive tests would be run unless `ci:
allow-many-extensive` is in the PR description. This allows us to set a
much higher CI timeout with less risk that a 4+ hour job gets started by
accident.
Sometimes we do refactoring that moves things around and triggers an
extensive test, even though the implementation didn't change. There
isn't any need to run full extensive CI in these cases, so add a way to
skip it from the PR message.
Jobs should just cancel automatically, it isn't ideal that extensive
jobs can continue running for multiple hours after code has been
updated. Use a solution from [1] to do this.
[1]: https://stackoverflow.com/a/72408109/5380651
Splitting into different source files by float size doesn't have any
benefit when the only content is a small function that forwards to the
generic implementation. Combine the source files for all width versions
of:
* ceil
* copysign
* fabs
* fdim
* floor
* fmaximum
* fmaximum_num
* fminimum
* fminimum_num
* ldexp
* scalbn
* sqrt
* truc
fmod is excluded to avoid conflicts with an open PR.
As part of this change move unit tests out of the generic module,
instead testing the type-specific functions (e.g. `ceilf16` rather than
`ceil::<f16>()`). This ensures that unit tests are validating whatever
we expose, such as arch-specific implementations via
`select_implementation!`, which would otherwise be skipped. (They are
still covered by integration tests).
Introduce a constant representing NaN with a negative sign bit for use
with testing. There isn't really any guarantee that `F::NAN` is positive
but in practice it always is, which is good enough for testing purposes.
`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.
Discussed at [1], there was an off-by-one mistake when converting from
the loop routine to using `leading_zeros` for normalization.
Currently, using `EXP_BITS` has the effect that `ix` after the branch
has its MSB _one bit to the left_ of the implicit bit's position,
whereas a shift by `EXP_BITS + 1` ensures that the MSB is exactly at the
implicit bit's position, matching what is done for normals (where the
implicit bit is set to be explicit). This doesn't seem to have any
effect in our implementation since the failing test cases from [1]
appear to still have correct results.
Since the result of using `EXP_BITS + 1` is more consistent with what is
done for normals, apply this here.
[1]: https://github.com/rust-lang/libm/pull/469#discussion_r2012473920
Parsing errors are now bubbled up part of the way, but that needs some
more work.
Rounding should be correct, and the `Status` returned by `parse_any`
should have the correct bits set. These are used for the current (unchanged)
behavior of the surface level functions like `hf64`: panic on invalid inputs, or
values that aren't exactly representable.
Replace `core::arch` versions of the following with handwritten
assembly, which avoids recursion issues (cg_gcc using `rint` as a
fallback) as well as problems with `aarch64be`.
* `rint`
* `rintf`
Additionally, add assembly versions of the following:
* `fma`
* `fmaf`
* `sqrt`
* `sqrtf`
If the `fp16` target feature is available, which implies `neon`, also
include the following:
* `rintf16`
* `sqrtf16`
`sqrt` is added to match the implementation for `x86`. `fma` is included
since it is used by many other routines.
There are a handful of other operations that have assembly
implementations. They are omitted here because we should have basic
float math routines available in `core` in the near future, which will
allow us to defer to LLVM for assembly lowering rather than implementing
these ourselves.
Some backends may replace calls to `core::arch` with multiple calls to
`sqrt` [1], which becomes recursive. Help mitigate this by replacing the
call with assembly.
Results in the same assembly as the current implementation when built
with optimizations.
[1]: https://github.com/rust-lang/compiler-builtins/issues/649
`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
