Page MenuHomePhabricator

[ARM] Add __bf16 as new Bfloat16 C Type
Needs ReviewPublic

Authored by LukeGeeson on Thu, Mar 12, 9:59 AM.

Details

Summary

This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with the Bfloat16 extension of the Armv8.6-a architecture, as
detailed here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

The bfloat type, and its properties is specified in the Arm C language
extension specification:

https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture

In detail this patch:

  • introduces an opaque, storage-only C-type __bf16, which does not introduce a new LLVM IR type, but maps it to either i16 or half type.

This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.

Based on work by:

  • Luke Cheeseman
  • Momchil Velikov
  • labrinea

Diff Detail

Event Timeline

LukeGeeson created this revision.Thu, Mar 12, 9:59 AM
craig.topper added inline comments.Thu, Mar 12, 10:56 AM
clang/lib/Basic/Targets/AArch64.cpp
69

Doesn't Bfloat16 have a different number of mantissa and exponent bits than IEEEhalf?

clang/test/CodeGen/arm-mangle-16bit-float.cpp
5

How can bfloat16 be passed as half? Don't they have a different format?

I don't understand why you wouldn't add a new IR type for this; doing so should be totally mechanical.

jfb added a reviewer: jfb.Thu, Mar 12, 11:16 AM

Note that we have an IR type for the PPC double-double format, which isn't even hardware-supported. This is literally just an IEEE floating-point format with non-standard parameters, right?

Note that we have an IR type for the PPC double-double format, which isn't even hardware-supported. This is literally just an IEEE floating-point format with non-standard parameters, right?

Indeed yeah, the details are laid out in a blog post here: https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a

I don't understand why you wouldn't add a new IR type for this; doing so should be totally mechanical.

We had a few reasons for doing it this way.

By adding a new IR type we would need to consider calling conventions, and IR optimizations for what is essentially an opaque storage-only type.

Bfloat has no soft ABI, and all the supported operations can be handled through intrinsics (in a later patch, removed here due to bloat). If we were to add a new IR type, then we would need to handle many operations which would extend beyond what the type is supported for. For instance in GCC we had to add a new mode in RTL to handle inline memcopy.

LukeGeeson marked an inline comment as done.Fri, Mar 13, 6:12 AM
LukeGeeson added inline comments.
clang/test/CodeGen/arm-mangle-16bit-float.cpp
5

see the above comment about soft-abis

I don't understand why you wouldn't add a new IR type for this; doing so should be totally mechanical.

We had a few reasons for doing it this way.

By adding a new IR type we would need to consider calling conventions, and IR optimizations for what is essentially an opaque storage-only type.

IR optimizations should just fall out; the code in APFloat should work for arbitrary FP semantics.

Calling something a "storage-only" type does not get you out of worrying about calling conventions at the ABI level. You can forbid passing your type as an argument or result directly, but structs containing your type as a field can still be passed around, and the behavior for that needs to be defined.

Bfloat has no soft ABI, and all the supported operations can be handled through intrinsics (in a later patch, removed here due to bloat). If we were to add a new IR type, then we would need to handle many operations which would extend beyond what the type is supported for. For instance in GCC we had to add a new mode in RTL to handle inline memcopy.

I don't know why having a soft ABI makes a difference. If the type only works on certain platforms, then it can't be used on other platforms.

Added a file from a downstream cleanup of the branch.

jfb added a comment.Fri, Mar 13, 11:57 AM

I don't understand why you wouldn't add a new IR type for this; doing so should be totally mechanical.

We had a few reasons for doing it this way.

By adding a new IR type we would need to consider calling conventions, and IR optimizations for what is essentially an opaque storage-only type.

IR optimizations should just fall out; the code in APFloat should work for arbitrary FP semantics.

Calling something a "storage-only" type does not get you out of worrying about calling conventions at the ABI level. You can forbid passing your type as an argument or result directly, but structs containing your type as a field can still be passed around, and the behavior for that needs to be defined.

Bfloat has no soft ABI, and all the supported operations can be handled through intrinsics (in a later patch, removed here due to bloat). If we were to add a new IR type, then we would need to handle many operations which would extend beyond what the type is supported for. For instance in GCC we had to add a new mode in RTL to handle inline memcopy.

I don't know why having a soft ABI makes a difference. If the type only works on certain platforms, then it can't be used on other platforms.

Having an IR type sounds like the right thing to do here.

stuij added a comment.Wed, Mar 18, 4:54 AM

Thanks for the feedback. We'll work on implementing a bfloat IR type.

SjoerdMeijer added a comment.EditedWed, Mar 18, 5:29 AM

That sounds good and that seems to address the feedback given here, which I agree with. Just wanted to briefly add that while it already looks like most interested people are on this ticket, perhaps it good to also share the plan and design on the cfe dev list for visibility.