Skip to content

core::num::f16b Rust's 16bit Brain Float - #160859

Open
Jamesbarford wants to merge 10 commits into
rust-lang:mainfrom
Jamesbarford:feat/fb16-pt1
Open

core::num::f16b Rust's 16bit Brain Float#160859
Jamesbarford wants to merge 10 commits into
rust-lang:mainfrom
Jamesbarford:feat/fb16-pt1

Conversation

@Jamesbarford

@Jamesbarford Jamesbarford commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

View all comments

Implements the RFC: f16b type. Best reviewed commit by commit, happy to split into separate PRs if that is deemed easier to review. However the line count and surface area is, in my opinion, reasonably small.

Adds;

  • ABI plumbing for the f16b along with bfloat lang item to work with LLVM, GCC is explicitly unimplemented!(...)
  • f16b feature gate, page for f16b on libruscdoc and a struct bf16 in core::num
  • Tests
  • Treat f16b as a scalar primitive for scalable vectors

Issues;

@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 10, 2026
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 10, 2026
@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 18 candidates

@rust-log-analyzer

This comment has been minimized.

@jieyouxu

Copy link
Copy Markdown
Member

@rustbot reroll

@rustbot rustbot assigned mati865 and unassigned jieyouxu Aug 10, 2026
Comment thread compiler/rustc_codegen_gcc/src/type_.rs Outdated
}

fn type_f16b(&self) -> Type<'gcc> {
bug!("f16b is not supported by the GCC codegen backend")

@antoyo antoyo Aug 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 😄, I will aim to add it in a follow up PR 👍

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, as @folkertdev pointed out, it was a doddle. So I've included the implementation in the PR 👍

@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

Comment thread compiler/rustc_ty_utils/src/layout.rs

@bjorn3 bjorn3 Aug 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the calling convention of other targets?

View changes since the review

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe only these files were changed because they have an exhaustive match on Float.

However, my version of abi-cafe found two interesting failures: GCC and Clang are inconsistent on aarch64 and armv7

// callee, compiled with GCC 12
#include <inttypes.h>
#include <string.h>
#include <stdio.h>
#include <stdbool.h>

typedef struct Many1 {
    __bf16 f0;
} Many1;

void struct_in_1(Many1 arg0) {
    printf("%d", arg0.f0);
}
// caller, compiled with clang 23
#include <inttypes.h>
#include <string.h>
#include <stdio.h>
#include <stdbool.h>

typedef struct Many1 {
    __bf16 f0;
} Many1;

void struct_in_1(Many1 arg0);

void do_test(void) {
    {
        Many1 arg0 = { .f0 = (((union { uint16_t bits; __bf16 value; }){ .bits = 49600 }).value) };

        printf("%d", arg0.f0);
        struct_in_1(arg0);

    }
}

hits

    func struct_in_1's values differed
      values (native-endian hex bytes):
        expect: C0 C1
        caller: C0 C1
        callee: 04 00
      the value was arg0.f0: rustarithmeticty(f16b)
      whose arg was arg0: Many1

The current Rust implementation matches clang, and is hence incompatible with GCC


armv7 with hardware floats also runs into incompatibilities

[target.armv7-unknown-linux-gnueabihf."f16::conv_c::repr_c::clang-nightly_calls_distro-gcc"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16::conv_c::repr_c::distro-gcc_calls_clang-nightly"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16b::conv_c::repr_c::clang-nightly_calls_distro-gcc"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16b::conv_c::repr_c::distro-gcc_calls_clang-nightly"]
busted = "check"

Finally, you can let this ICE on many targets, e.g. mips, powerpc, s390x, sparc

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also (e.g. on loongarch64 https://godbolt.org/z/Y3hdhG4e6) emit a __truncsfbf2 libcall that is not provided (probably needs to be added to compiler-builtins).


I think the ICEs are probably a blocker? That needs a mechanism similar to has_reliable_f128.

@Jamesbarford Jamesbarford Aug 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I added it because of the exhaustive match statement in mips64.rs and sparc64.rs I've removed it; 40d3f6e and put in a panic!(...).

With regard to has_reliable_f128, are you envisaging a has_reliable_f16b entry on TargetConfig?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With regard to has_reliable_f128, are you envisaging a has_reliable_f16b entry on TargetConfig?

Exactly

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's your take on those ABI mismatches? We should track that somewhere.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not particularly certain what mips64 should do.

It doesn't, at least to my knowledge, have hardware support. Given we aren't implementing scalar arithmetic and an f16b can only be created through a bit pattern or vendor intrinsics, I can't immediately see a practical application? Hence a panic! seems like a pragmatic choice for the time being.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No comment on whether this is the right approach, but always use span_bug! or at least bug! where possible in the compiler, rather than panic. It gives much more useful info.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use those custom macros in rustc_target because they are defined in rustc_middle, and that crate depends on rustc_target.

@Jamesbarford Jamesbarford Aug 19, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem possible to use in compiler/rustc_target, however elsewhere I have strived to use it when available.

@rust-log-analyzer

This comment has been minimized.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe only these files were changed because they have an exhaustive match on Float.

However, my version of abi-cafe found two interesting failures: GCC and Clang are inconsistent on aarch64 and armv7

// callee, compiled with GCC 12
#include <inttypes.h>
#include <string.h>
#include <stdio.h>
#include <stdbool.h>

typedef struct Many1 {
    __bf16 f0;
} Many1;

void struct_in_1(Many1 arg0) {
    printf("%d", arg0.f0);
}
// caller, compiled with clang 23
#include <inttypes.h>
#include <string.h>
#include <stdio.h>
#include <stdbool.h>

typedef struct Many1 {
    __bf16 f0;
} Many1;

void struct_in_1(Many1 arg0);

void do_test(void) {
    {
        Many1 arg0 = { .f0 = (((union { uint16_t bits; __bf16 value; }){ .bits = 49600 }).value) };

        printf("%d", arg0.f0);
        struct_in_1(arg0);

    }
}

hits

    func struct_in_1's values differed
      values (native-endian hex bytes):
        expect: C0 C1
        caller: C0 C1
        callee: 04 00
      the value was arg0.f0: rustarithmeticty(f16b)
      whose arg was arg0: Many1

The current Rust implementation matches clang, and is hence incompatible with GCC


armv7 with hardware floats also runs into incompatibilities

[target.armv7-unknown-linux-gnueabihf."f16::conv_c::repr_c::clang-nightly_calls_distro-gcc"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16::conv_c::repr_c::distro-gcc_calls_clang-nightly"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16b::conv_c::repr_c::clang-nightly_calls_distro-gcc"]
busted = "check"

[target.armv7-unknown-linux-gnueabihf."f16b::conv_c::repr_c::distro-gcc_calls_clang-nightly"]
busted = "check"

Finally, you can let this ICE on many targets, e.g. mips, powerpc, s390x, sparc

Comment thread library/core/src/num/f16b.rs Outdated
Comment thread compiler/rustc_codegen_ssa/src/mir/naked_asm.rs Outdated
Comment thread library/core/src/num/f16b.rs Outdated
Comment thread library/core/src/num/bfloat.rs
Comment thread tests/codegen-llvm/float/f16b.rs Outdated
@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the A-test-infra-minicore Area: `minicore` test auxiliary and `//@ add-core-stubs` label Aug 12, 2026
@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot

rustbot commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

@rust-log-analyzer

This comment has been minimized.

@mati865

mati865 commented Aug 12, 2026

Copy link
Copy Markdown
Member

I'm not a good reviewer for this change. Can somebody here pick it up rather than blindly rerolling?

@folkertdev

Copy link
Copy Markdown
Contributor

r? me

@tgross35

tgross35 commented Sep 1, 2026

Copy link
Copy Markdown
Member

Guess some jobs got renamed...

@bors try jobs=test-various,aarch64-apple-,-gnu-nopt-,x86_64-mingw-,aarch64-msvc-*,arm-android

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Sep 1, 2026
`core::num::f16b` Rust's 16bit Brain Float


try-job: test-various
try-job: aarch64-apple-*
try-job: *-gnu-nopt-*
try-job: x86_64-mingw-*
try-job: aarch64-msvc-*
try-job: arm-android
@rust-log-analyzer

This comment has been minimized.

Comment thread tests/assembly-llvm/f16b.rs
@folkertdev folkertdev mentioned this pull request Sep 1, 2026
@rust-bors

This comment was marked as outdated.

@folkertdev

Copy link
Copy Markdown
Contributor

Oh fun I hit https://triage.rust-lang.org/gha-logs/rust-lang/rust/99996805056 before, the issue is some symbol being bumped and now being 3 digits instead of 2, causing formatting changes.

@rustbot rustbot added A-tidy Area: The tidy tool T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Sep 2, 2026
@rust-log-analyzer

This comment has been minimized.

@tgross35

tgross35 commented Sep 2, 2026

Copy link
Copy Markdown
Member

@bors try jobs=test-various,aarch64-apple-,-gnu-nopt-,x86_64-mingw-,aarch64-msvc-*,arm-android

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Sep 2, 2026
`core::num::f16b` Rust's 16bit Brain Float


try-job: test-various
try-job: aarch64-apple-*
try-job: *-gnu-nopt-*
try-job: x86_64-mingw-*
try-job: aarch64-msvc-*
try-job: arm-android
@rust-log-analyzer

This comment has been minimized.

@rust-bors

rust-bors Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

💔 Test for f6d6327 failed: CI. Failed jobs:

pull Bot pushed a commit to LeeeeeeM/miri that referenced this pull request Sep 2, 2026
…lkertdev

Make sin, cos, exp, exp2, log, log2, log10 generic

Rebased and smaller version of rust-lang/rust#153934

Following `fabs`, make the `sin`, `cos`, `exp`, `exp2`, `log`, `log2` and `log10` intrinsics generic over the float type, rather than having four variants per float type.

The first two commits are purely stylistic:
- reorganised Cranelift code to make following changes simpler
- moved a misplaced comment in `compiler/rustc_codegen_llvm/src/intrinsic.rs` that caused `x fmt` to give up

The last commit actually makes them generic! Most code is a bit simpler, ~~and this will also hopefully simplify adding support for these intrinsics for the future [`bf16` type](rust-lang/rust#160859 :)

Unfortunately both GCC and Cranelift backend changes are a bit churny. Their code is a bit, opaque, to put it kindly, and I didn't want to refactor those here.

r? @folkertdev
cc @RalfJung
@rust-log-analyzer

This comment has been minimized.

@rustbot

rustbot commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-test-infra-minicore Area: `minicore` test auxiliary and `//@ add-core-stubs` A-tidy Area: The tidy tool S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.