<div dir="ltr">On some platforms designed for tasks of machine learning `bfloat16` is full-fledged type, it is supported in the same extent as `float`.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 6:45 AM Ties Stuij via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If I remember correctly, __fp16 is a "storage only" type and we don't allow it as an argument unless some native half setting is enabled. Could we just not allow __bf16 as an argument and treat it as an i16 everywhere else? I think that matches what we do for __fp16 when half isn't native.<br>
<br>
I'm not sure the solution addresses John McCall's general ABI argument, and if adding an IR type is indeed 'totally mechanical', I think it'd be nicer to not restrict bfloat and just have an explicit type.<br>
<br>
Cheers,<br>
/Ties<br>
<br>
________________________________________<br>
From: Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>><br>
Sent: 21 March 2020 06:11<br>
To: Ties Stuij<br>
Cc: Anton Korobeynikov; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
Subject: Re: [cfe-dev] new bfloat IR type for C bfloat type mapping<br>
<br>
If I remember correctly, __fp16 is a "storage only" type and we don't allow it as an argument unless some native half setting is enabled. Could we just not allow __bf16 as an argument and treat it as an i16 everywhere else? I think that matches what we do for __fp16 when half isn't native.<br>
<br>
~Craig<br>
<br>
<br>
On Fri, Mar 20, 2020 at 11:37 AM Ties Stuij via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
> If this is a storage-only type, why you need new IR type at all? Why<br>
can't you simply use i16 everywhere?<br>
<br>
John McCall had a succinct answer to that on the review:<br>
'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.'<br>
<br>
To fill that in in a way, we're using half in some cases to make sure the bfloat goes to an FPR instead of a GPR.<br>
<br>
Cheers,<br>
/Ties<br>
<br>
<br>
On Fri, Mar 20, 2020 at 7:07 PM Ties Stuij via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
><br>
> Hi all,<br>
><br>
> At Arm we have started upstreaming support for various Armv8.6-a features [1]. As part of this effort we are upstreaming support for the Brain floating point format (bfloat16) C type [2].<br>
><br>
> As the name suggests it's a 16-bit floating point format, but with the same amount of exponent bits as an IEEE 754 float32, which are taken from the mantissa which is now only 7 bits. It also behaves much like an IEEE 754 type. For more info, see [3] and [4].<br>
><br>
> In our original patch [2], we mapped the C bfloat type to either float or int32 llvm type, just like we do for _Float16 and __fp16. However Craig Topper was quite surprised we would pass as half, and John McCall and JF Bastien suggested to map it to a new bfloat IR type, as again bfloat is distinct from float16, and doing so should be straightforward. Sjoerd Meijer also concurred, but suggested we poll the mailing list before forging ahead.<br>
><br>
> Our initial thought was that a separate IR type isn't needed. There's no support in the architecture for naked bfloat operations and bfloat would only be used in an ML context through intrinsics. But it is a separate type, and it does make sense to treat it as such. Also several architectures have or have announced support for bf16 and there are proposals in flight to add it to the C++ standard.<br>
><br>
> Thoughts?<br>
><br>
><br>
> Best regards,<br>
> /Ties Stuij<br>
><br>
><br>
> links:<br>
> [1] <a href="https://reviews.llvm.org/D76062" rel="noreferrer" target="_blank">https://reviews.llvm.org/D76062</a><br>
> [2] <a href="https://reviews.llvm.org/D76077" rel="noreferrer" target="_blank">https://reviews.llvm.org/D76077</a><br>
> [3] <a href="https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a" rel="noreferrer" target="_blank">https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a</a><br>
> [4] <a href="https://static.docs.arm.com/ddi0487/fa/DDI0487F_a_armv8_arm.pdf" rel="noreferrer" target="_blank">https://static.docs.arm.com/ddi0487/fa/DDI0487F_a_armv8_arm.pdf</a><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
--<br>
With best regards, Anton Korobeynikov<br>
Department of Statistical Modelling, Saint Petersburg State University<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>