Implement {add,sub,mul,neg,div} vfp

[mattico]

No description provided.

[parched]

Why do these need to be implemented in assembly?

[mattico]

@parched I think there are two questions here:

Why do we need functions that are just wrappers around single assembly instructions?

I'm not sure. LLVM should be capable of just emitting the instructions, surely?

Why can't these be implemented in Rust?

If LLVM lowers float operations to these functions, that using Rust to implement them would cause an infinite loop because the functions would end up calling themselves.

Also, these functions have a special calling convention so they can't be implemented in Rust, if the comment at the top of this file is to be believed. The compiler-rt comments mention a "Darwin calling convention" which is presumably different than aapcs otherwise we'd just use that.

I think both points can be attributed to "Apple weirdness." At the end of the day, we need these to be defined otherwise things don't compile and that's good enough for me.

[parched]

I'm not sure. LLVM should be capable of just emitting the instructions, surely?

Yeah, I bet it probably does in release mode but this has be written to always work so you a right, it needs to be in assembly. It could be worth adding a note, these are written in assembly not Rust to avoid infinite recursion.

The compiler-rt comments mention a "Darwin calling convention" which is presumably different than aapcs otherwise we'd just use that.

That is strange because they are just using AAPCS or AAPCS_VFP depending on whether it's hard float or not. It also says arg passing only using general purpose registers but it clearly isn't for hard float

[Amanieu]

I think that these builtins are only used when generating Thumb1 code (pre-ARMv6). Before ARMv6, Thumb code can't encode floating-point instructions and the compiler must therefore emit a call to an external function (which uses the ARM encoding instead of Thumb) instead.

[mattico]

Some googling seems to corroborate @Amanieu's idea, so I'll add a comment about that.

[parched]

I think that these builtins are only used when generating Thumb1 code ... Thumb code can't encode floating-point instructions

Interesting, so these might fail to build on the target that needs them.

At the end of the day, we need these to be defined otherwise things don't compile

What target have you found that needs them? Do they build correctly for it?

[mattico]

Interesting, so these might fail to build on the target that needs them.

Most (all?) ARM code has thumb code mixed in. EABI in particular requires function-level granularity between thumb and ARM code. thumb*- targets don't support ARM though, unsurprisingly.

What target have you found that needs them? Do they build correctly for it?

I was hoping that travis would answer this question since I borked my linux partition, but nightly cargo broke travis. So I set up a VM to test and it turns out there are two issues:

1. thumb*- targets are included in cfg(target_arch = "arm")
2. Some ARM targets don't support VFP2.

I guess it's time to split up the arm module so we don't end up in cfg hell. I'll have to look at the compiler-rt build system to really know how to partition it, but I'm thinking arm/common.rs arm/thumb.rs arm/vfp.rs.

[mattico]

I'm going to close this PR for now. I want to rethink the way we build ARM stuff to be split with more granularity based on target features. That's the tough part, porting the intrinsics is little more than copy-paste.

Thanks @parched, your questions helped me get to this conclusion faster than I would have otherwise.