Add support for sub*f3vfp and add*f3vfp
As done before for `mul` and `div` let's use extern "C" to generate `"aapcs"` or `"aapcs-vfp"` depending on target configuration.
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!
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
First of all aeabi_cdcmp and aeabi_cfcmp are never called LLVM.
Second are little-endian only, so build fail on big-endian targets.
Temporally workaround: exclude these files for big-endian targets.
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.
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.
Fix nightly CI
Currently we're getting lots of errors about duplicate lang items so deal with
this by `#[cfg_attr]`'ing off the lang item attribute in tests.
Remove mulsf3.c and muldf3.c from compiler-rt.
mulsf3 and muldf3 have Rust implementations since 8970485. This PR removes the C implementations to avoid conflicts.
Without this I wasn't able to compile the crate with the "c" feature enabled, the errors being
`multiple definition of '__muldf3'` and `multiple definition of '__mulsf3'`.
Use the "volatile" option and the "memory" clobber on inline asm that does
things like return directly, to reduce the chances of compilers rearranging
the code.
bors
Paolo Teti
Alex Crichton
whitequark
Marco A L Barbosa
Amanieu d'Antras
Tamir Duberstein
Jan Teske
Scott McMurray
Dan Gohman