Add f16/f128 support

[beetrees]

This PR adds full support for f16 and f128. As Cranelift backends only fully support basic operations such as load, store and bitcast at the moment, operations are polyfilled to allow full support for everything currently implemented in rustc.

Fixes #1461

[tgross35]

LGTM for the non cranelift-specific parts, LLVM also does promote/demote for f16 powi and fmod.

[bjorn3]

Is Cranelift ABI compatible with LLVM for f16 and f128 across all targets Cranelift supports?

[beetrees]

By architecture/platform:

• Non-Windows x86-64 - f16/f128 are passed/returned in XMM registers as per specification.
• Windows x86-64 - f16/f128 are not supported by the Windows x86-64 ABI, but are available in Cranelift with enable_llvm_abi_extensions which currently matches LLVM 21 (passing/returning both types in XMM registers, except for passing f128 indirectly). Note that LLVM 20, the current LLVM version used by Rust, always passes f128 in XMM registers (see [windows] Always pass fp128 arguments indirectly llvm/llvm-project#128848).
• Non-Apple AArch64 - f16/f128 are passed/returned in floating-point registers as per specification.
• Apple AArch64 - the Apple ARM ABI is a variant of the standard AAPCS64, and Apple targets only support f16 in C (where it is passed/returned in floating-point registers). f128 is available in Cranelift with enable_llvm_abi_extensions, matching LLVM by passing/returning in floating-point registers like on non-Apple AArch64.
• 64-bit RISC-V - f16 is passed/returned in floating-point registers, f128 is passed/returned as a pair of integer registers, both as per the LP64D ABI in the specification (Cranelift does not currently support any other standard RISC-V ABIs).
• s390x - f128 is passed/returned indirectly as per specification, f16 is only supported as an LLVM/Clang extension in the upcoming LLVM 21 (see [SystemZ] Add support for half (fp16) llvm/llvm-project#109164), where it is passed/returned in floating-point registers.

Summary: All Cranelift f16/f128 support currently matches the standard ABIs, with enable_llvm_abi_extensions enabling extensions that match LLVM 21. Cranelift's Windows x86-64 f128 ABI (only available via enable_llvm_abi_extensions) isn't compatible with the f128 ABI used by LLVM 20.

[beetrees]

Update: basic load/store/bitcast support is now available for all 4 architectures. Combined with the emit_zero fix, this should all be available in the Cranelift release scheduled for 20th May. Once that happens, it should be theoretically possible to have full f16/f128 support in rustc_codegen_cranelift by lowering math operations to directly calling the relevant functions from compiler-builtins instead of using the not-yet-implemented CLIF instructions. The partial exception to this is f128 on x86-64 Windows, which won't be usable with a Rust sysroot compiled with LLVM 20 (the current version used by Rust) as the f128 ABI has only been fixed in LLVM 21+ (see llvm/llvm-project#128848).

[tgross35]

As a note, once the above lowering to compiler-builtins is available, the recently added config at

rustc_codegen_cranelift/src/lib.rs

Lines 200 to 208 in dfe7636

	TargetConfig {
	target_features,
	unstable_target_features,
	// Cranelift does not yet support f16 or f128
	has_reliable_f16: false,
	has_reliable_f16_math: false,
	has_reliable_f128: false,
	has_reliable_f128_math: false,
	}

could likely be updated to start running tests. (Hopefully rust-lang/rust#138087 will merge first to avoid racing on any possible new test failures in r-l/rust).

[beetrees]

This PR now implements full support for f16 and f128, and should be ready for review.

[beetrees]

I've discovered a pre-existing bug: when rustc_codegen_cranelift calls __powi*f2, it doesn't currently apply the correct ArgumentExtension required by the platform C ABI (this only affects riscv64 and s390x, as x86_64 and aarch64 both don't have any argument extension for 32-bit integers). This PR fixes the issue.

[bjorn3]

Would you mind splitting this into multiple commits? That would make it easier for me to review this. For example lib_call_arg_param can be a commit, adding fconst and basic float operations could be another one and implementing all the float intrinsics could be a third commit. And finally actually enabling support in CodegenBackend, the build system and the test code could be a final commit.

[beetrees]

Done. I've split it into 7 commits, but let me know if that's too many and I can squash some back together.

[bjorn3]

Can you add these all new libcalls to the builtin_functions! invocation in compiler_builtins.rs?

[beetrees]

Done. Not all currently used libcalls seem to be in there (e.g. fmod, __powisf2), so I've only added ones that seemed similar to the ones already there. Is this correct, or should every possible libcall be listed?

[bjorn3]

The missing ones are just an oversight.