public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	 "tamar.christina" <Tamar.Christina@arm.com>
Subject: Re: Re: [PATCH] test regression fix: Remove xfail for variable length targets
Date: Tue, 16 Jan 2024 08:48:17 +0100 (CET)	[thread overview]
Message-ID: <9s60548q-r32s-r647-6q3p-40s0346n4qo1@fhfr.qr> (raw)
In-Reply-To: <0F4116832099EE9E+202401161545385020980@rivai.ai>

On Tue, 16 Jan 2024, juzhe.zhong@rivai.ai wrote:

> >> That's probably because we have vect_variable_length && vect128 instead?
> Yes. Both RVV and SVE uses 128bit vector SLP.
> 
> The optimized IR (both ARM SVE and RVV are similiar):
>   vect__1.5_189 = MEM <vector(4) int> [(int *)x_50(D)];
>   vect__1.6_191 = MEM <vector(4) int> [(int *)x_50(D) + 16B];
>   mask__2.7_192 = vect__1.5_189 == { 1, 1, 1, 1 };
>   mask__2.7_193 = vect__1.6_191 == { 1, 1, 1, 1 };
>   mask_patt_156.8_194 = VEC_PACK_TRUNC_EXPR <mask__2.7_192, mask__2.7_193>;
>   vect__3.11_196 = MEM <vector(8) short int> [(short int *)y_51(D)];
>   mask__4.12_197 = vect__3.11_196 == { 2, 2, 2, 2, 2, 2, 2, 2 };
>   mask_patt_157.13_198 = mask_patt_156.8_194 & mask__4.12_197;
>   vect_patt_158.14_199 = .VCOND_MASK (mask_patt_157.13_198, { 1, 1, 1, 1, 1, 1, 1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0 });
>   vect_patt_159.15_200 = [vec_unpack_lo_expr] vect_patt_158.14_199;
>   vect_patt_159.15_201 = [vec_unpack_hi_expr] vect_patt_158.14_199;

so xfail { vect_variable_length && { ! vect256 } && { ! vect128 } } then?

> 
> 
> juzhe.zhong@rivai.ai
>  
> From: Richard Biener
> Date: 2024-01-16 15:38
> To: Juzhe-Zhong
> CC: gcc-patches; Tamar.Christina
> Subject: Re: [PATCH] test regression fix: Remove xfail for variable length targets
> On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
>  
> > Recently notice there is a XPASS in RISC-V:
> > XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects  scan-tree-dump-not slp2 "vector operands from scalars"
> > XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from scalars"
> > 
> > And checked both ARM SVE and RVV:
> > 
> > https://godbolt.org/z/T9cPa7fh3
> > 
> > both has the same dump slp2. So I guess ARM SVE has the same XPASS in this test.
>  
> That's probably because we have vect_variable_length && vect128 instead?
> Thus, what's the IL after SLP2 (and some DCE)?
>  
> > gcc/testsuite/ChangeLog:
> > 
> > * gcc.dg/vect/bb-slp-43.c: Remove xfail for variable length.
> > 
> > ---
> >  gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > index dad2d24262d..40bd2e0dfbf 100644
> > --- a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > @@ -14,4 +14,4 @@ f (int *restrict x, short *restrict y)
> >  }
> >  
> >  /* { dg-final { scan-tree-dump-not "mixed mask and nonmask" "slp2" } } */
> > -/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" { target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign } } xfail { vect_variable_length && { ! vect256 } } } } } */
> > +/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" { target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign } } } } } */
> > 
>  
> 

-- 
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-01-16  7:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16  6:35 Juzhe-Zhong
2024-01-16  7:38 ` Richard Biener
2024-01-16  7:45   ` juzhe.zhong
2024-01-16  7:48     ` 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=9s60548q-r32s-r647-6q3p-40s0346n4qo1@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=Tamar.Christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    /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).