public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: "Pengxuan Zheng (QUIC)" <quic_pzheng@quicinc.com>
Cc: Richard Sandiford <richard.sandiford@arm.com>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH] aarch64: Add fix_truncv4sfv4hi2 pattern [PR113882]
Date: Tue, 18 Jun 2024 07:55:51 +0200 (CEST)	[thread overview]
Message-ID: <16qr4350-8278-n18q-53o8-47r209o5099o@fhfr.qr> (raw)
In-Reply-To: <BYAPR02MB48212FE13B64510C3F7A1B1FD1CE2@BYAPR02MB4821.namprd02.prod.outlook.com>

On Tue, 18 Jun 2024, Pengxuan Zheng (QUIC) wrote:

> > Pengxuan Zheng <quic_pzheng@quicinc.com> writes:
> > > This patch adds the fix_truncv4sfv4hi2 (V4SF->V4HI) pattern which is
> > > implemented using fix_truncv4sfv4si2 (V4SF->V4SI) and then truncv4siv4hi2
> > (V4SI->V4HI).
> > >
> > > 	PR target/113882
> > >
> > > gcc/ChangeLog:
> > >
> > > 	* config/aarch64/aarch64-simd.md (fix_truncv4sfv4hi2): New pattern.
> > 
> > Could we handle this by extending the target-independent code instead?
> > Richard mentioned in comment 1 that the current set of intermediate
> > conversions is hard-coded, but it didn't sound like he was implying that the
> > set shouldn't change.
> 
> Yes, Richard. I checked the target-independent code. In fact, SLP already 
> handles this type of intermediate conversions. However, the logic is guarded by 
> "!flag_trapping_math". Therefore, if we pass -fno-trapping-math , SLP actually 
> generates the right vectorized code. Also, looks like the check for 
> "!flag_trapping_math" was added intentionally in r14-2085-g77a50c772771f6 to fix 
> some PRs. So, I'm not sure what we should do here. Thoughts?
> 
>       if (GET_MODE_SIZE (lhs_mode) != GET_MODE_SIZE (rhs_mode)
>           && (code == FLOAT_EXPR ||
>               (code == FIX_TRUNC_EXPR && !flag_trapping_math)))

That is because of missing FE_INVALID(?) when say float -> signed char
doesn't fit but float -> int does and the remaining converts are done
as int -> {short,char}.

There has been multiple rounds of discussion whether flag_trapping_math
should be off by default.

Richard.

> Thanks,
> Pengxuan
> > 
> > Thanks,
> > Richard
> > 
> > > gcc/testsuite/ChangeLog:
> > >
> > > 	* gcc.target/aarch64/fix_trunc2.c: New test.
> > >
> > > Signed-off-by: Pengxuan Zheng <quic_pzheng@quicinc.com>
> > > ---
> > >  gcc/config/aarch64/aarch64-simd.md            | 13 +++++++++++++
> > >  gcc/testsuite/gcc.target/aarch64/fix_trunc2.c | 14 ++++++++++++++
> > >  2 files changed, 27 insertions(+)
> > >  create mode 100644 gcc/testsuite/gcc.target/aarch64/fix_trunc2.c
> > >
> > > diff --git a/gcc/config/aarch64/aarch64-simd.md
> > > b/gcc/config/aarch64/aarch64-simd.md
> > > index 868f4486218..096f7b56a27 100644
> > > --- a/gcc/config/aarch64/aarch64-simd.md
> > > +++ b/gcc/config/aarch64/aarch64-simd.md
> > > @@ -3032,6 +3032,19 @@ (define_expand
> > "<fix_trunc_optab><VHSDF:mode><fcvt_target>2"
> > >    "TARGET_SIMD"
> > >    {})
> > >
> > > +
> > > +(define_expand "fix_truncv4sfv4hi2"
> > > +  [(match_operand:V4HI 0 "register_operand")
> > > +   (match_operand:V4SF 1 "register_operand")]
> > > +  "TARGET_SIMD"
> > > +  {
> > > +    rtx tmp = gen_reg_rtx (V4SImode);
> > > +    emit_insn (gen_fix_truncv4sfv4si2 (tmp, operands[1]));
> > > +    emit_insn (gen_truncv4siv4hi2 (operands[0], tmp));
> > > +    DONE;
> > > +  }
> > > +)
> > > +
> > >  (define_expand "ftrunc<VHSDF:mode>2"
> > >    [(set (match_operand:VHSDF 0 "register_operand")
> > >  	(unspec:VHSDF [(match_operand:VHSDF 1 "register_operand")] diff
> > > --git a/gcc/testsuite/gcc.target/aarch64/fix_trunc2.c
> > > b/gcc/testsuite/gcc.target/aarch64/fix_trunc2.c
> > > new file mode 100644
> > > index 00000000000..57cc00913a3
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/aarch64/fix_trunc2.c
> > > @@ -0,0 +1,14 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-O2" } */
> > > +
> > > +void
> > > +f (short *__restrict a, float *__restrict b) {
> > > +  a[0] = b[0];
> > > +  a[1] = b[1];
> > > +  a[2] = b[2];
> > > +  a[3] = b[3];
> > > +}
> > > +
> > > +/* { dg-final { scan-assembler-times {fcvtzs\tv[0-9]+.4s, v[0-9]+.4s}
> > > +1 } } */
> > > +/* { dg-final { scan-assembler-times {xtn\tv[0-9]+.4h, v[0-9]+.4s} 1
> > > +} } */
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

      reply	other threads:[~2024-06-18  5:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04  1:09 Pengxuan Zheng
2024-06-06 12:29 ` Richard Sandiford
2024-06-06 13:22   ` Richard Biener
2024-06-18  0:05   ` Pengxuan Zheng (QUIC)
2024-06-18  5:55     ` Richard Biener [this message]

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=16qr4350-8278-n18q-53o8-47r209o5099o@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=quic_pzheng@quicinc.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).