test regression fix: Remove xfail for variable length targets

Message ID 20240116063510.3692246-1-juzhe.zhong@rivai.ai
State New
Headers
Series test regression fix: Remove xfail for variable length targets |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 success Testing passed

Commit Message

juzhe.zhong@rivai.ai Jan. 16, 2024, 6:35 a.m. UTC
  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.

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(-)
  

Comments

Richard Biener Jan. 16, 2024, 7:38 a.m. UTC | #1
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 } } } } } */
>
  
juzhe.zhong@rivai.ai Jan. 16, 2024, 7:45 a.m. UTC | #2
>> 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;



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)
  
Richard Biener Jan. 16, 2024, 7:48 a.m. UTC | #3
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 } } } } } */
> > 
>  
>
  

Patch

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 } } } } } */