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.
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.
Adds generic conversion from a wider to a narrower IEEE-754
floating-point type.
Implement `__truncdfsf2` and `__truncdfsf2vfp` and associated test-cases.
Now that `73884ae` is in some nightly release We can add ledf2vfp/leds2vfp
and so these two functions be aliased to aeabi_fcmple/aeabi_dcmple on soft-float targets.
Add `extend` module to implement conversion from a narrower to a wider
floating-point type.
This implementation is only intended to support *widening* operations.
Module to convert a *narrower* floating-point will be added in the future.
Here using `"C"` the compiler will use `"aapcs"` or `"aapcs-vfp"`
depending on target configuration.
Of course this translates in a call to `__aeabi_fdiv` / `__aeabi_fmul`
on non-HF targets.
On `eabi` targets with +vfpv2/vfpv3 LLVM generate:
vmov s0, r1
vmov s2, r0
vdiv.f32 s0, s2, s0
vmov r0, s0
bx lr
On `eabihf` targets with +vfpv3-d16/d32/f32 +fp-only-sp LLVM generate:
vdiv.f32 s0, s0, s1
bx lr
That's exactly what We need for [div/mul][s/d]f3vfp.S
E.g. take a look at the assembly output for:
pub fn comparesf2(a: f32, b: f32) -> bool { a > b }
pub fn comparedf2(a: f64, b: f64) -> bool { a > b }
which will include calls to __gtsf2 and __gtdf2.
