From: Jakub Jelinek <jakub@redhat.com>
To: Richard Earnshaw <richard.earnshaw@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
Jason Merrill <jason@redhat.com>,
gcc-patches@gcc.gnu.org, richard.sandiford@arm.com
Subject: Re: AArch64 bfloat16 mangling
Date: Fri, 10 Mar 2023 16:35:49 +0100 [thread overview]
Message-ID: <ZAtOVR25mfwtY6+r@tucnak> (raw)
In-Reply-To: <mpto7p0ygds.fsf@arm.com>
On Fri, Mar 10, 2023 at 11:50:39AM +0000, Richard Sandiford wrote:
> > Will test it momentarily (including the patch it depends on):
Note, testing still pending, I'm testing in a Fedora scratch build
and that is quite slow (lto bootstrap and the like).
> A naive question:
>
> > --- libgcc/config/aarch64/t-softfp.jj 2022-11-14 13:35:34.527155682 +0100
> > +++ libgcc/config/aarch64/t-softfp 2023-03-10 12:19:58.668882041 +0100
> > @@ -1,9 +1,10 @@
> > softfp_float_modes := tf
> > softfp_int_modes := si di ti
> > -softfp_extensions := sftf dftf hftf
> > -softfp_truncations := tfsf tfdf tfhf
> > +softfp_extensions := sftf dftf hftf bfsf
> > +softfp_truncations := tfsf tfdf tfhf tfbf dfbf sfbf hfbf
>
> Is bfsf used for conversions in which sf is the ultimate target,
> as opposed to operations that convert bf to sf and then do something
> with the sf? And so the libfunc is needed to raise exceptions, which in
> more complex operations can be left to the following sf operation?
>
> Do we still optimise to a shift for -ffinite-math-only?
Reminds me I should have added testcase coverage for PR107703, will post
it momentarily.
But, consider say:
template <typename T, typename F>
[[gnu::noipa]] T cvt (F f)
{
return T (F (f));
}
void
foo ()
{
cvt <_Float32, __bf16> (0.0bf16);
cvt <_Float64, __bf16> (0.0bf16);
cvt <_Float128, __bf16> (0.0bf16);
cvt <signed char, __bf16> (0.0bf16);
cvt <signed short, __bf16> (0.0bf16);
cvt <int, __bf16> (0.0bf16);
cvt <long long, __bf16> (0.0bf16);
cvt <__int128, __bf16> (0.0bf16);
}
This emits on x86_64 -O2:
/usr/src/gcc/obj/gcc/cc1plus -quiet -O2 1111.C; grep call.*__ 1111.s
call __extendbfsf2
call __extendbfsf2
call __extendbfsf2
call __extendsftf2
call __fixsfti
where the first call is in cvt <_Float32, __bf16> is really needed,
admittedly the second 2 calls could be replaced by shifts but aren't right
now (we expand BF -> DF as BF -> SF -> DF and because sNaN would be already
diagnosed on the SF -> DF conversion if BF -> SF is done with shift, I think
it would be ok; similarly for BF -> TF). All the others (BF -> ?I) are
expanded as BF -> SF using shift and then SF -> ?I. With -O2 -ffast-math
/usr/src/gcc/obj/gcc/cc1plus -quiet -O2 -ffast-math 1111.C; grep call.*__ 1111.s
call __extendsftf2
call __fixsfti
so all the BF -> SF conversions are then done using shifts.
And aarch64 is exactly the same:
./cc1plus -quiet -nostdinc -O2 1111.C; grep bl.*__[ef] 1111.s
bl __extendbfsf2
bl __extendbfsf2
bl __extendbfsf2
bl __extendsftf2
bl __fixsfti
./cc1plus -quiet -nostdinc -O2 -ffast-math 1111.C; grep bl.*__[ef] 1111.s
bl __extendsftf2
bl __fixsfti
> Assuming so, the patch LGTM. I'm not familiar enough with softfloat
> to do a meaningful review of those parts, and I'm taking the versioning
> changes on faith. :)
The soft-fp new files (in both patches) are fairly mechanical:
for i in float{,un}{d,t}isf.c; do \
sed 's/IEEE single/bfloat16/;s/single/brain/;s/SFtype/BFtype/;s/_S /_B /;s/sf /bf /' \
$i `echo $i | sed 's/sf.c/bf.c/'`
done
(well, I've created them by hand, so the Copyright lines differ, but
otherwise they are identical to what the above script would create).
So, there are no smarts in those, the soft-fp library already can handle
those formats.
Jakub
next prev parent reply other threads:[~2023-03-10 15:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 9:50 Patch ping Jakub Jelinek
2023-01-30 23:07 ` Richard Sandiford
2023-02-01 10:27 ` AArch64 bfloat16 mangling Jakub Jelinek
2023-03-09 17:14 ` Richard Sandiford
2023-03-10 8:37 ` Jakub Jelinek
2023-03-10 8:43 ` Richard Sandiford
2023-03-10 11:30 ` Jakub Jelinek
2023-03-10 11:50 ` Richard Sandiford
2023-03-10 15:35 ` Jakub Jelinek [this message]
2023-03-10 16:25 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZAtOVR25mfwtY6+r@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=kyrylo.tkachov@arm.com \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).