Stabilizing `f16`

[tomassedovic]

Metadata
Point of contact	@folkertdev
Team(s)	compiler, lang, libs-api
Goal document	2026/stabilizing-f16

Summary

In recent years we've seen increasing hardware support for the f16 float type. Support was originally motivated by machine learning/AI, but f16 has since also found applications in other domains like graphics and physics simulations.

With LLVM 22, the remaining blockers in the backends have been cleared for f16, and therefore stabilizing this type in 2026 is realistic.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@folkertdev
Team(s)	compiler, lang, libs-api
Goal document	2026/stabilizing-f16

Summary

In recent years we've seen increasing hardware support for the f16 and f128 float types. Especially for f16 support was originally motivated by machine learning/AI, but these types have since also found applications in other domains like graphics and physics simulations.

With LLVM 22, the remaining blockers in the backends have been cleared for f16, and therefore stabilizing this type in 2026 is realistic.

Needs funding: This goal needs funding to proceed.

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[folkertdev]

We've done a bunch of work improving support so far, e.g.

• add f16 support miri#4895
• implement sqrt and add fixme for f128 miri#4902
• Add f16 vector support portable-simd#513

We finally merged a PR that resolves the From<f16> for f32 issues

• Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32 rust#139087
• unstable impl of From<{i64, u64}> for f128 rust#154012

And some various other work

• Resolve Clippy f16 and f128 unimplemented!/FIXMEs  rust#126636
• Enable f16 and f128 on targets that were fixed in LLVM21 rust#144987

[folkertdev]

Not much to report this time. We're waiting for LLVM 23 (and hence dropping LLVM 21) to unblock some cleanup work.

We have made some changes to the goal itself to shift focus away from f128 and rustc_codegen_gcc to rustc_codegen_cranelift . In particular we want to get rid of some of the custom patches that the cranelift backend currently needs to compile.

[folkertdev]

Key developments

The main achievement is merging this PR. It adds fallbacks to many float libcalls via libm, so backends don't need to implement them and target don't need to provide the libcalls.

• intrinsics: Add a fallback for non-const libm float functions rust#150946

Merging that PR required some additional testing infrastructure

• add -Zforce-intrinsic-fallback flag rust#158377
• add core test run with -Zforce-intrinsic-fallback rust#158927

And meant that a maintenance-heavy patch could be removed from rustc_codegen_cranelift:

• remove f16-math patch rustc_codegen_cranelift#1674

Also we've done some work in LLVM to improve f16 support

• [MIPS] soft-promote f16 also when using +msa llvm/llvm-project#204158
• [MIPS] int <-> half conversions with +msa llvm/llvm-project#201897
• [X86] promote f16 frexp llvm/llvm-project#208530

Work in progress

By adding additional fallbacks we can remove another cranelift patch:

• add a fallback for more f16 intrinsics  rust#159175

Blockers

We've failed to get a response on the main blocker for this feature: libcalls assuming target features that are not part of the baseline. For f128 the main offender is powerpc, whose libcalls use vector registers (from the vsx target feature) for libcalls, but the baseline target does not have those registers. Hence libcalls miscompile.

Help wanted

Not at the moment.