This commit tweaks the implementation of the synthetic
`#[use_c_shim_if]` attribute, renaming it to
`#[maybe_use_optimized_c_shim]` in the process. This no longer requires
specifying a `#[cfg]` clause indicating when the optimized intrinsic
should be used, but rather this is inferred and printed from the build
script.
The build script will now print out appropriate `#[cfg]` directives for
rustc to indicate what intrinsics it's compiling. This should remove the
need for us to keep the build script and the source in sync, but rather
the build script can simply take care of everything.
Adds generic conversion from a wider to a narrower IEEE-754
floating-point type.
Implement `__truncdfsf2` and `__truncdfsf2vfp` and associated test-cases.
This was an accidental regression introduced in #252 by removing compilation of
C files without adjusting the `#[use_c_shim_if]` directives. This restores the
compilation of the assembly files and updates the `#[use_c_shim_if]` directives.
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.
Be sure to do not mix hard-float and soft-float calls.
Disassembled code show exactly this.
So replace add with an explicit call to __addsf3/__adddf3
This seems the root cause of some sporadic failures.
I was able to trigger an issue extending f32::MAX or f32::MIN to a f64.
Issue was not triggered by `testcrate` mainly because f32::MAX/MIN are
not in the list of special values to generate.
This PR fix the issue and improve `testcrate` adding MAX/MIN/MIN_POSITIVE
in the list of special values.
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
* I believe `__gtdf2` erroneously used `f32` instead of `f64`
* Most of these needed `#[arm_aeabi_alias]` to ensure they're correctly called
through the alias
* Some existing aliases were corrected with the right names
Note that this changes semantics:
pub extern "C" fn __eqsf2(a: f32, b: f32) -> bool {
cmp(a, b).to_le_abi() != 0
}
is not the same as
pub extern "C" fn __eqsf2(a: f32, b: f32) -> i32 {
cmp(a, b).to_le_abi()
}
However, compiler-rt does the latter, so this is actually
an improvement.
