f16 and f128 have non-trivial ABI requirements on some targets

The standard C ABI for f16 and f128 requires particular target features on certain targets, going beyond the baseline that is generally required for those targets:

• on x86-32, f16 needs sse2 (https://github.com/rust-lang/rust/issues/131819)
• on powerpc, f128 needs vsx (https://github.com/rust-lang/rust/issues/125109)

This list is non-exhaustive. More research needs to be done here before these types can be stabilized.

But meanwhile, there's the question of -- how should we handle this?

Broadly speaking we have two hammers we could apply here:

• We mark certain target features as required by the ABI on particular targets. For instance, we already mark x87 as required on targets like i686-unknown-linux-gnu. This might then necessitate creating more target triples so that one can choose another ABI that does not require those target features. I don't know if a standard ABI for f16 without SSE exists on x86-32. We could make one up, like using the softfloat convention for f16 while still passing all other float types like hardfloats, but that does not seem great.
• We consider certain types to require certain target features when being passed via extern "C" functions. For extern "Rust", we need to come up with our own ABI that avoids the use of any non-default target features. This is what we do for SIMD types. However, this is not quite enough on LLVM since some operations on float types are implicitly lowered to libcalls by LLVM and those can use the wrong ABI. (That's not a problem for SIMD as all operations there are intrinsics which we are already manually decorating with the required target features.) LLVM is generally built around the assumption that the compiler just rejects any use of a type if the corresponding target feature is missing, as that's how C works. (EDIT: It's not actually how C works, clang allows using __m128 even without SSE. You just have to be careful or so. But for libcalls that doesn't work...)

The second hammer seems more attractive here, though it is inconsistent with how we handled f32 / f64 requiring particular target features. I guess we didn't want to lose passing those in float registers for "Rust" functions. ;) The other downside of this approach is that it is incomplete as long as LLVM still uses the wrong ABI for the libcalls it generates.

Cc @tgross35

Start by researching the linked issues about x86-32 f16 and PowerPC f128 ABI requirements, then review the LLVM issue on generated libcalls using the wrong ABI. Compare the two proposed approaches for target features and Rust versus C ABIs; done means reaching a well-supported stabilization direction that accounts for the non-exhaustive target research.