Configure which platforms have f16 and f128 enabled by default

[tgross35]

By moving the logic for which platforms get symbols to compiler_builtins rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in 1.

This will help resolve errors like 2.

[beetrees]

For reference, I've locally tested compiling on every target Rust currently supports, and the only architectures/targets that I couldn't compile compiler-builtins with both f16 and f128 enabled are:

• Tier 2:

  • arm64ec: both f16 and f128 fail due to Can't pass or return half or fp128 on arm64ec llvm/llvm-project#94434
  • s390x: f128 compiles; f16 fails due to SystemZ Backend: Add support for operations such as FP16_TO_FP and FP_TO_FP16 llvm/llvm-project#50374

• Tier 3:

  • mips64/mips64r6: f16 compiles; f128 fails when compiling in debug mode (but not release mode) due to Compiler crash when targeting mips64 when returning fp128 after calling a function returning { i8, i128 } llvm/llvm-project#96432
  • powerpc64-ibm-aix: f16 compiles; f128 fails due to fp128 arguments cause a compiler error on powerpc64-ibm-aix llvm/llvm-project#101545
  • 32-bit sparc: f16 compiles; f128 fails due to Passing long double args on 32-bit SPARC violates ABI llvm/llvm-project#41838

The only targets I wasn't able to compile (even with the no-f16-f128 feature enabled) were all tier 3:

• m68k-unknown-linux-gnu (always broken tier 3 targets rust#126349 (comment))
• xtensa targets (currently requires a LLVM fork: Tracking Issue for merging to upstream (LLVM-57) espressif/llvm-project#4)

I was able to build testcrate on all tier 1/2 targets that aren't listed as having issues above (I haven't checked tier 3 targets for testcrate), but I haven't run testcrate on all of them so it's possible CI could fail on a target not listed above.

[tgross35]

I was going to ping you once I figured this out but you beat me to it. Thanks, that is incredibly helpful.

Do you think it is reasonable to configure disabling those targets here? As I mentioned in the diff I think it would be better in rust-lang/rust, but I can't come up with a good way to do it that doesn't rely on cargo features.

[tgross35]

Are you testing on a version with LLVM19? I know llvm/llvm-project#93894 caused a problem when we were updating builtins but that has since been resolved. I am pleasantly surprised if that was the only selection failure for interfaces.

[beetrees]

I think doing it here is probably the best solution at this point, given the issues with switching to the v2 resolver in rust-lang/rust#128359. Ultimately, as compiler-builtins is an internal crate for use in rust-lang/rust, I don't think it matters whether the workaround for LLVM bugs to make compiler-builtins compile on all targets is in rust-lang/rust or rust-lang/compiler-builtins: the end result is (apart from Cargo resolver issues) the same.

rustc --version -v:

rustc 1.82.0-nightly (28a58f2fa 2024-07-31)
binary: rustc
commit-hash: 28a58f2fa7f0c46b8fab8237c02471a915924fe5
commit-date: 2024-07-31
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

[tgross35]

I don't think it matters whether the workaround for LLVM bugs to make compiler-builtins compile on all targets is in rust-lang/rust or rust-lang/compiler-builtins: the end result is (apart from Cargo resolver issues) the same.

Agreed. I am just not looking forward to the cycle of PR here -> release -> Rust PR -> Rust CI, if there are failures. But maybe this won't be much of an issue if there aren't too many completely broken targets.

I think the 7-31 nightly is the first one since rust-lang/rust#127513, so I guess that was all. Awesome.

[tgross35]

• 32-bit sparc: f16 compiles; f128 fails due to Passing long double args on 32-bit SPARC violates ABI llvm/llvm-project#41838

Does this one actually crash or does it just have runtime issues?

[beetrees]

It fails to compile with rustc-LLVM ERROR: SPARCv8 does not handle f128 in calls; pass indirectly; I'll post an update on the issue to make the current state of affairs clearer.

[tgross35]

Alright, I think this should be good to go. There were a handful of small changes needed to get CI passing again after the builtins update in rustc, there are more details in the commit messages.

[tgross35]

Thanks. @Amanieu could you do a release? #657

[kleisauke]

I noticed that wasm32 is missing from this switch case:

compiler-builtins/build.rs

Lines 275 to 288 in 3ad4d9c

	let (f16_ok, f128_ok) = match target.arch.as_str() {
	// `f16` and `f128` both crash <https://github.com/llvm/llvm-project/issues/94434>
	"arm64ec" => (false, false),
	// `f16` crashes <https://github.com/llvm/llvm-project/issues/50374>
	"s390x" => (false, true),
	// `f128` crashes <https://github.com/llvm/llvm-project/issues/96432>
	"mips64" | "mips64r6" => (true, false),
	// `f128` crashes <https://github.com/llvm/llvm-project/issues/101545>
	"powerpc64" if &target.os == "aix" => (true, false),
	// `f128` crashes <https://github.com/llvm/llvm-project/issues/41838>
	"sparc" | "sparcv9" => (true, false),
	// Most everything else works as of LLVM 19
	_ => (true, true),
	};

Was this omission intentional? I'm encountering the same build failures described here:

compiler-builtins/testcrate/build.rs

Lines 56 to 58 in 3ad4d9c

	// Linking says "error: function signature mismatch: __extendhfsf2" and seems to
	// think the signature is either `(i32) -> f32` or `(f32) -> f32`
	|| target.starts_with("wasm32-")

when building for wasm32-unknown-emscripten and using -Zbuild-std. However, I was able to work around the issue by also including -Zbuild-std-features=compiler-builtins-no-f16-f128.

[tgross35]

We do seem to build successfully in rust-lang/rust for this target so I’m not sure what the difference is. But it makes sense to omit wasm32 for now if it is causing failures, mind putting up a PR?

[kleisauke]

I just opened (draft) PR #665 for this.