PowerPC platforms use `kf` rather than `tf` for `f128`. Add a way to
alias this in the macro to make the code cleaner.
This also fixes the names of `fixunstf*` and `fixtf*` on Power PC
(`fixunskf*` and `fixkf*` are correct).
Currently, tests of the same kind are grouped together across all types
into a single function. This makes it difficult to understand exactly
what failed in CI.
Change test macros to create separate functions for separate types so
failures are more fine grained.
Change float test macros to fall back to testing against `rustc_apfloat`
when system implementations are not available, rather than just skipping
tests.
This allows for easier debugging where operations may not be supported.
Trying to run testcrate on non-linux aarch64 currently hits a
compilation error. Make this test linux-only, to be consistent with the
`aarch64_linux` module that it depends on.
Additionally, enable the `aarch64_linux` module for `target_arch =
"arm64ec"` to be the same as these tests.
This has a very long history, summarized in
https://github.com/rust-lang/rust/issues/109064. This port is a very
minimal subset of `aarch64/lse.S` from LLVM's compiler-rt. In
particular, it is missing the following:
1. Any form of runtime dispatch between LL/SC and LSE.
Determining which version of the intrinsics to use
requires one of the following:
i) `getauxval` from glibc. It's unclear whether `compiler_builtins` is
allowed to depend on libc at all, and musl doesn't even support
getauxval. Don't enshrine the requirement "de-facto" by making it
required for outline-atomics.
ii) kernel support. Linux and FreeBSD have limited support, but it
requires an extremely recent kernel version and doesn't work at all under QEMU (https://github.com/rust-lang/rust/issues/109064#issuecomment-1494939904).
Instead, we hard-code LL/SC intrinsics. Users who want LSE support
should use the LLVM compiler-rt (if you're building from source in
rust-lang/rust, make sure you have `src/llvm-project` checked out
locally. the goal is to soon add a new `optimized-compiler-builtins`
option so this is easier to discover).
2. The global `___aarch64_have_lse_atomics` CTOR, required to do runtime
dispatch. Thom Chiviolani has this to say about global CTORs:
> static ctors are problems because we are pretty eager about dead code elim
> in general if you have a module that isnt directly reference we will probably not have its static ctors
> also, while llvm has a super robust way to have a static ctor (theres s special "appending global" to use for c++), we dont use that and just have people make a #[used] static in a special section
> 1. the robust way kinda requires rust knowing that the argument is a static ctor (maybe a #[rustc_static_ctor] attribute). it also would be... finnicky, since on windows we actually care beyond being a static ctor, that we run as part in a specific group of ctors, which means a very specific section (one for TLS and the other for, uh, i dont remember)
> 2. we still actually have to codegen the cgu that isn't referenced. but maybe we could remember that it has that attribute and use that
So while this is possible in theory, it's decidedly non-trivial, and
needs invasive changes to rust itself. In any case, it doesn't matter
until we decide the story around libc.
3. The 16-byte (i128) version of compare_and_swap. This wouldn't be
*too* hard to add, but it would be hard to test. The way I tested the
existing code was not just with unit tests but also by loading it as a
path dependency and running `x test core` - the latter caught several
bugs the unit tests didn't catch (because I originally wrote the tests
wrong). So I am slightly nervous about adding a 16-byte version that is
much more poorly tested than the other intrinsics.
x86_64 can load unaligned words in a single cache line as fast as
aligned words. Even when crossing cache or page boundaries it is just as
fast to do an unaligned word read instead of multiple byte reads.
Also add a couple more tests & benchmarks.
This adds the truncdfsf2 intrinsic and a corresponding fuzz test case. The
implementation of trunc is generic to make it easy to add truncdfhs2 and
truncsfhf2 if rust ever gets `f16` support.
* mem: Move mem* functions to separate directory
Signed-off-by: Joe Richey <joerichey@google.com>
* memcpy: Create separate memcpy.rs file
Signed-off-by: Joe Richey <joerichey@google.com>
* benches: Add benchmarks for mem* functions
This allows comparing the "normal" implementations to the
implementations provided by this crate.
Signed-off-by: Joe Richey <joerichey@google.com>
* mem: Add REP MOVSB/STOSB implementations
The assembly generated seems correct:
https://rust.godbolt.org/z/GGnec8
Signed-off-by: Joe Richey <joerichey@google.com>
* mem: Add documentations for REP string insturctions
Signed-off-by: Joe Richey <joerichey@google.com>
* Use quad-word rep string instructions
Signed-off-by: Joe Richey <joerichey@google.com>
* Prevent panic when compiled in debug mode
Signed-off-by: Joe Richey <joerichey@google.com>
* Add tests for mem* functions
Signed-off-by: Joe Richey <joerichey@google.com>
* Add build/test with the "asm" feature
Signed-off-by: Joe Richey <joerichey@google.com>
* Add byte length to Bencher
Signed-off-by: Joe Richey <joerichey@google.com>
* Allow FFI-unsafe warnings for u128/i128
Handle new warnings on nightly, and we shouldn't need to worry about
these with compiler-builtins since this is tied to a particular compiler.
* Clean up crate attributes
* No need for stability marker
* Rustdoc docs not used for this crate
* Remove old build-system related cruft from rustc itself.
* Run `cargo fmt`
All tests are moved to a separate crate in this repository to enable features by
default. Additionally the test generation is moved to a seprate build script and
simplified to reduce the amount of boilerplate needed per test.
Overall this should still be testing everything, just in a different location!
