rustc’s introduction of f128 breaks powerpc builds

[barracuda156]

This is just to track the matter. Hopefully, a simple exclusion of related routines will do. As of now, it seems to work.

Related threads:
rust-lang/rust#116909
rust-lang/rust#151557

[tgross35]

What exactly breaks here? I don't know much about mrustc but may be able to suggest a solution.

[tgross35]

Note that f16 and f128 are disabled on a handful of targets, PPC being one of them. See https://github.com/rust-lang/rust/blob/67bcaa9c4b1b1015efae3d591155c79760b1e0a5/compiler/rustc_codegen_llvm/src/llvm_util.rs#L365-L432.

Eventually that list will go away though, so you may need a soft float fallback on targets where C doesn't support the types. This looks like:

1. Treat the types as u16 / u128 for ABI purposes
2. Turn all operations into libcalls. E.g. f16 + f16 should turn into a C call u16 __addhf3(u16, u16), f128 * f128 -> __int128 __multf3(__int128, __int128), fma(f16, f16, f16) -> u16 fmaf16(u16, u16, u16)

[barracuda156]

@tgross35 In practice linking fails with a bunch of undefined symbols in cmath.rs, since stdlib code seems to assume those functions are provided by libm, while they are not.

PowerPC uses a different format of long double, non-IEEE. And it does not have __int128. I don’t know what exactly Rust’s f128 stands for, but quite likely it was designed without considering implications for non-x86/non-arm archs.
I am not sure if any work in gcc upstream is done re emulating IEEE long double.

[tgross35]

@tgross35 In practice linking fails with a bunch of undefined symbols in cmath.rs, since stdlib code seems to assume those functions are provided by libm, while they are not.

Control this by setting cfg(target_has_reliable_f128_math), see cfg.has_reliable_f128 toward the bottom of what I linked.

PowerPC uses a different format of long double, non-IEEE. And it does not have __int128. I don’t know what exactly Rust’s f128 stands for, but quite likely it was designed without considering implications for non-x86/non-arm archs. I am not sure if any work in gcc upstream is done re emulating IEEE long double.

What is being done with i128 now if __int128 doesn't exist? Whatever it is, it would be fine to use the same for f128, at least for ABI purposes.

f128 is not long double , it is IEEE binary128 (i.e. _Float128 / __float128 on supported platforms). I don't know what you mean about implications for non-x86/non-arm arches, there are a number of considerations for those. The fallback is to use soft float via the integer ABI if the target doesn't support it.

[barracuda156]

What is being done with i128 now if __int128 doesn't exist?

mrustc emulates it, I believe. I have no idea what rustc does, since it is broken for other reasons.

I don't know what you mean about implications for non-x86/non-arm arches

I have seen multiple times, in different software, assumptions being made which hold only for x86 or x86 and arm (while software in question is supposed, or explicitly claims, to be portable). Developers may not care or may not be even aware of other platforms.

Re __float128, it looks rather messy:
https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
__ibm128 seems to be available on PowerPC, but I never seen it being used as a type explicitly in the code.

[tgross35]

What is being done with i128 now if __int128 doesn't exist?

mrustc emulates it, I believe. I have no idea what rustc does, since it is broken for other reasons.

Emulating is fine, most platforms don't have i128 ops in their base feature sets (ditto for f128). What's broken?

I don't know what you mean about implications for non-x86/non-arm arches

I have seen multiple times, in different software, assumptions being made which hold only for x86 or x86 and arm (while software in question is supposed, or explicitly claims, to be portable). Developers may not care or may not be even aware of other platforms.

If we only cared about x86 and arm64, f16 and f128 would have been stable a year ago...

Re __float128, it looks rather messy: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html __ibm128 seems to be available on PowerPC, but I never seen it being used as a type explicitly in the code.

Unfortunately there are many targets where it won't be possible to get away with lowering to a C type. Where __float128 or _Float128 exist then of course that's fine, but GCC tends to only expose those on platforms where the ABI specifies it. Our types are meant to be usable on all platforms, so they need to treat them extension via the integer ABI.

[barracuda156]

@iains @pinskia Could you please tell us what’s the status and possible solution for PowerPC in this case (when using GCC)?

[iains]

@iains @pinskia Could you please tell us what’s the status and possible solution for PowerPC in this case (when using GCC)?

using the existing emulation for powerpc-darwin is not immediately possible (it requires VSX). So we'd need to define an ABI that makes use of VMX (altivec) only and then re-implement the soft support.
AFAIU, from one of the power maintainers - this ought to be possible. However, it is not on my radar to do this - or anything else on rust until it is possible to build it without cargo. I am also limited to rosetta (1) these days - since I have not been able to replace the quad g5 ..

[barracuda156]

until it is possible to build it without cargo

Iain, was it considered to use mrustc for bootstrap? I know of complications, but maybe we could solve that. I have mrustc 1.90 working now on powerpc-darwin. (There may be some mismatches in ABI implementation, which I hope you could help reviewing and fixing, but I can build some rust apps and they actually work.)

[barracuda156]

@tgross35

What's broken?

Generally: rust-lang/rfcs#1312

Specifically re rustc build via mrustc (version is constrained on supported LLVM, which is 7.1 until @iains releases 11.x): #300 (this may be something trivial to fix, but I could not figure out the solution).

[tgross35]

@iains @pinskia Could you please tell us what’s the status and possible solution for PowerPC in this case (when using GCC)?

I wouldn't bother trying to support f128 on any PPC target in mrustc while rustc doesn't support it: you can just set #[cfg(target_has_reliable_f128)] to false. PPC is a bit extra special because it's the only target we currently support where f128 needs a non-baseline CPU feature, so we still need to figure out what to do there.

Eventually we'll figure out a solution (different libcalls and error on extern "C" depending on whether VSX is available?) but I don't think there's anything concrete enough to try emulating at this point.