Re: [llvm-dev] [PATCH 0/2] Initial support for AVX512FP16

2021-07-14 Thread Craig Topper via Gcc-patches
On Wed, Jul 14, 2021 at 12:45 AM Hongtao Liu via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> > >
> > Set excess_precision_type to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 to
> > round after each operation could keep semantics right.
> > And I'll document the behavior difference between soft-fp and
> > AVX512FP16 instruction for exceptions.
> I got some feedback from my colleague who's working on supporting
> _Float16 for llvm.
> The LLVM side wants to set  FLT_EVAL_METHOD_PROMOTE_TO_FLOAT for
> soft-fp so that codes can be more efficient.
> i.e.
> _Float16 a, b, c, d;
> d = a + b + c;
>
> would be transformed to
> float tmp, tmp1, a1, b1, c1;
> a1 = (float) a;
> b1 = (float) b;
> c1 = (float) c;
> tmp = a1 + b1;
> tmp1 = tmp + c1;
> d = (_Float16) tmp;
>
> so there's only 1 truncation in the end.
>
> if users want to round back after every operation. codes should be
> explicitly written as
> _Float16 a, b, c, d, e;
> e = a + b;
> d = e + c;
>
> That's what Clang does, quote from [1]
>  _Float16 arithmetic will be performed using native half-precision
> support when available on the target (e.g. on ARMv8.2a); otherwise it
> will be performed at a higher precision (currently always float) and
> then truncated down to _Float16. Note that C and C++ allow
> intermediate floating-point operands of an expression to be computed
> with greater precision than is expressible in their type, so Clang may
> avoid intermediate truncations in certain cases; this may lead to
> results that are inconsistent with native arithmetic.
>

Clang for AArch64 promotes each individual operation and rounds immediately
afterwards. https://godbolt.org/z/qzGfv6nvo note the fcvts between the two
fadd operations. It's implemented in the LLVM backend where we can't see
what was originally a single expression.


>
> and so does arm gcc
> quote from arm.c
>
> /* We can calculate either in 16-bit range and precision or
>32-bit range and precision.  Make that decision based on whether
>we have native support for the ARMv8.2-A 16-bit floating-point
>instructions or not.  */
> return (TARGET_VFP_FP16INST
> ? FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
> : FLT_EVAL_METHOD_PROMOTE_TO_FLOAT);
>
>
> [1]https://clang.llvm.org/docs/LanguageExtensions.html
> > > --
> > > Joseph S. Myers
> > > jos...@codesourcery.com
> >
> >
> >
> > --
> > BR,
> > Hongtao
>
>
>
> --
> BR,
> Hongtao
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


Re: [llvm-dev] [PATCH] Add optional _Float16 support

2021-07-01 Thread Craig Topper via Gcc-patches
On Thu, Jul 1, 2021 at 4:02 PM H.J. Lu via llvm-dev 
wrote:

> On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers 
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu wrote:
> >
> > > BTW, _Float16 software emulation may require more than just SSE
> > > since we need to do _Float16 load and store with XMM registers.
> > > There is no 16bit load/store for XMM registers without AVX512FP16.
> >
> > You should be able to make the move go via general-purpose registers (for
> > example) if you can't do a direct 16-bit load/store for XMM registers.
> >
>
> There is no 16bit move between GPRs and XMM registers without
> AVX512FP16.
>
>
Isn't PINSRW supported since SSE1?


>
> --
> H.J.
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>