public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Jason Merrill <jason@redhat.com>,
	"Joseph S. Myers" <joseph@codesourcery.com>,
	Richard Biener <rguenther@suse.de>,
	Jeff Law <jeffreyalaw@gmail.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] middle-end, c++, i386, libgcc, v2: std::bfloat16_t and __bf16 arithmetic support
Date: Thu, 13 Oct 2022 23:35:01 +0200	[thread overview]
Message-ID: <Y0iEheHa081cFEKW@tucnak> (raw)
In-Reply-To: <CAFULd4bEc3v64wXJcYL0-NMED0P48K98j_mQjSuiVYp+PrKK2Q@mail.gmail.com>

On Thu, Oct 13, 2022 at 11:11:53PM +0200, Uros Bizjak wrote:
> > > +  do_compare_rtx_and_jump (op1, op2, GET_CODE (operands[0]), 0,
> > > +                        SFmode, NULL_RTX, NULL,
> > > +                        as_a <rtx_code_label *> (operands[3]),
> > > +                        /* Unfortunately this isn't propagated.  */
> > > +                        profile_probability::even ());
> 
> You could use ix86_expand_branch instead of do_compare_rtx_and_jump
> here. This would expand in SFmode, so insn condition from cbranchsf4
> should be copied here:
> 
>   "TARGET_80387 || (SSE_FLOAT_MODE_P (SFmode) && TARGET_SSE_MATH)"
> 
> Additionally, ix86_fp_comparison_operator predicate should be used for
> operator0. Basically, just copy predicates from cbranchsf4 as we are
> effectively expanding the SFmode compare & branch.

The reason why I've used there the generic routine was exactly to handle
not just ix86_fp_comparison_operator, but also comparisons that are more
complex than that (need 2 comparisons).

While for ix86_fp_comparison_operator cases the optabs wouldn't be actually
strictly needed, the generic code would see e.g. cbranchbf4 isn't supported
and try cbranchsf4, succeed on that and the only disadvantage would be
that the BFmode -> SFmode extensions would be performed using library
functions unless -ffast-math while they can be handled by left shifting
the 16 BFmode bits to most significant 16 bits of SFmode even when honoring
NaNs, for the non-ix86_fp_comparison_operator cases the generic behavior
is actually that neither cbranchbf4, nor cbranchsf4, nor cbranchdf4, nor
cbranchxf4, nor cbranchtf4 works out and generic code emits a libcall
(__{eq,ne}bf2).  I bet that is the reason why libgcc contains __{eq,ne}hf2
entrypoints.
I wanted to avoid adding __{eq,ne}bf2 and the addition of
cbranchbf4/cstorebf4 was how I managed to do that; by telling the
generic code that it can handle those by the faster BFmode to SFmode
conversions of the operands and then perform one or two bit checks.

I guess another possibility would be to call ix86_expand_branch there
once or twice and repeat what the generic code does, or add the
libgcc entrypoints which would perhaps bypass soft-fp and just do the
shifts + SFmode comparison.

> > > +  else
> > > +    {
> > > +      rtx t2 = gen_reg_rtx (SImode);
> > > +      emit_insn (gen_zero_extendhisi2 (t2, op2));
> > > +      emit_insn (gen_ashlsi3 (t2, t2, GEN_INT (16)));
> > > +      op2 = gen_lowpart (SFmode, t2);
> > > +    }
> 
> Similar to cbranch above, use ix86_expand_setcc and copy predicates
> from cstoresf4.

Ditto here, cstore was actually quite required by the generic code when
cbranch is implemented.

	Jakub


  reply	other threads:[~2022-10-13 21:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 15:55 [RFC PATCH] c++, i386, arm, aarch64, libgcc: " Jakub Jelinek
2022-09-30 13:49 ` Jason Merrill
2022-09-30 14:08   ` Jakub Jelinek
2022-09-30 18:21     ` Joseph Myers
2022-09-30 18:38       ` Jakub Jelinek
2022-09-30 19:27         ` Jonathan Wakely
2022-10-04  9:06     ` [PATCH] middle-end, c++, i386, " Jakub Jelinek
2022-10-04 15:54       ` Joseph Myers
2022-10-04 21:50       ` Jason Merrill
2022-10-05 13:47         ` Jakub Jelinek
2022-10-05 20:02           ` Jason Merrill
2022-10-12  8:23             ` [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE Jakub Jelinek
2022-10-12 10:15               ` Richard Sandiford
2022-10-12 11:07                 ` [PATCH] machmode, v2: " Jakub Jelinek
2022-10-12 11:49                   ` Richard Sandiford
2022-10-12 10:37               ` [PATCH] machmode: " Eric Botcazou
2022-10-12 10:57                 ` Jakub Jelinek
2022-10-13 16:50             ` [PATCH] middle-end, c++, i386, libgcc, v2: std::bfloat16_t and __bf16 arithmetic support Jakub Jelinek
2022-10-13 19:37               ` Jason Merrill
2022-10-13 21:11                 ` Uros Bizjak
2022-10-13 21:35                   ` Jakub Jelinek [this message]
2022-10-13 21:46                     ` Uros Bizjak

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=Y0iEheHa081cFEKW@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=joseph@codesourcery.com \
    --cc=rguenther@suse.de \
    --cc=ubizjak@gmail.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).