core::num::f16b Rust's 16bit Brain Float - #160859
Conversation
|
Some changes occurred in compiler/rustc_attr_ir cc @jdonszelmann, @JonathanBrouwer This PR changes rustc_public cc @oli-obk, @celinval, @ouz-a, @makai410
|
|
r? @jieyouxu rustbot has assigned @jieyouxu. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
… and backend handling. GCC and Cranelift explicitly unsupported
|
@rustbot reroll |
…long with traits agreed on in the RFC
…6b` to be treated as a primitive scalar
| } | ||
|
|
||
| fn type_f16b(&self) -> Type<'gcc> { | ||
| bug!("f16b is not supported by the GCC codegen backend") |
There was a problem hiding this comment.
I believe GCC actually supports this type: https://github.com/rust-lang/gccjit.rs/blob/master/src/context.rs#L1482
There was a problem hiding this comment.
Thanks 😄, I will aim to add it in a follow up PR 👍
bf10f8a to
01c5c1b
Compare
|
cc @bjorn3 |
| let bfloat = scalar_unit(Primitive::Float(abi::Float::F16B)); | ||
| assert_eq!(layout.size, abi::Float::F16B.size()); | ||
| assert_eq!(layout.align, abi::Float::F16B.align(cx)); | ||
| layout.backend_repr = BackendRepr::Scalar(bfloat); |
There was a problem hiding this comment.
You probably also want to add a check that you can't take a reference to the inner field just like for #[repr(simd)].
There was a problem hiding this comment.
What is the calling convention of other targets?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
With regard to
has_reliable_f128, are you envisaging ahas_reliable_f16bentry onTargetConfig?
Exactly
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
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
| #[lang = "bfloat"] | ||
| #[allow(non_camel_case_types)] | ||
| #[repr(transparent)] | ||
| #[unstable(feature = "f16b", issue = "160630")] | ||
| pub struct f16b(u16); |
There was a problem hiding this comment.
can you also add this to minicore.rs?
| }, | ||
| Primitive::Float(float) => match float { | ||
| Float::F16 | Float::F32 => "f32", | ||
| Float::F16 | Float::F16B | Float::F32 => "f32", |
There was a problem hiding this comment.
is that right? LLVM just crashes on bf16 right now, so it's probably at least untested?
There was a problem hiding this comment.
I could be mistaken, however I don't think WASM supports bf16? I've made it panic!(...) for now; 40d3f6e
- Add documentation aliases to `f16b` - Add Wikipedia link to `bfloat16` - Remove `@ only-x86_64` flag from test
- ICE on `sparc64`, `mips64` & WASM
53d3660 to
40d3f6e
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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;
f16balong withbfloatlang item to work with LLVM, GCC is explicitlyunimplemented!(...)f16bfeature gate, page forf16bon libruscdoc and astruct bf16incore::numf16bas a scalar primitive for scalable vectorsIssues;