This adds comparisons among the compiler-builtins function, system
functions if available, and optionally handwritten assembly.
These also help us identify inconsistencies between this crate and
system functions, which may otherwise go unnoticed if intrinsics get
lowered to inline operations rather than library calls.
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).
`as` casts are only allowed for primitives, doing the same operations
with `rustc_apfloat` requires using functions. Add a way to specify
these separately.
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.
`MinInt` contains the basic methods that are only needed by integers
involved in widening operations, i.e. big integers. `Int` retains all
other operations and convenience methods.
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.
