RISC-V Regression: Fix FAIL of bb-slp-pr65935.c for RVV
Checks
Commit Message
Here is the reference comparing dump IR between ARM SVE and RVV.
https://godbolt.org/z/zqess8Gss
We can see RVV has one more dump IR:
optimized: basic block part vectorized using 128 byte vectors
since RVV has 1024 bit vectors.
The codegen is reasonable good.
However, I saw GCN also has 1024 bit vector.
This patch may cause this case FAIL in GCN port ?
Hi, GCN folk, could you check this patch in GCN port for me ?
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-pr65935.c: Add vect1024 variant.
* lib/target-supports.exp: Ditto.
---
gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c | 3 ++-
gcc/testsuite/lib/target-supports.exp | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)
Comments
On 10/10/2023 02:39, Juzhe-Zhong wrote:
> Here is the reference comparing dump IR between ARM SVE and RVV.
>
> https://godbolt.org/z/zqess8Gss
>
> We can see RVV has one more dump IR:
> optimized: basic block part vectorized using 128 byte vectors
> since RVV has 1024 bit vectors.
>
> The codegen is reasonable good.
>
> However, I saw GCN also has 1024 bit vector.
> This patch may cause this case FAIL in GCN port ?
>
> Hi, GCN folk, could you check this patch in GCN port for me ?
This patch *fixes* an existing test fail on GCN. :)
It's probably one of the many I've never had time to analyze (and
optimizing more than expected makes it low priority).
LGTM
Andrew
Great ! I am gonna wait for Richi's approval.
juzhe.zhong@rivai.ai
From: Andrew Stubbs
Date: 2023-10-10 17:40
To: Juzhe-Zhong; gcc-patches@gcc.gnu.org
CC: rguenther@suse.de; jeffreyalaw@gmail.com
Subject: Re: [PATCH] RISC-V Regression: Fix FAIL of bb-slp-pr65935.c for RVV
On 10/10/2023 02:39, Juzhe-Zhong wrote:
> Here is the reference comparing dump IR between ARM SVE and RVV.
>
> https://godbolt.org/z/zqess8Gss
>
> We can see RVV has one more dump IR:
> optimized: basic block part vectorized using 128 byte vectors
> since RVV has 1024 bit vectors.
>
> The codegen is reasonable good.
>
> However, I saw GCN also has 1024 bit vector.
> This patch may cause this case FAIL in GCN port ?
>
> Hi, GCN folk, could you check this patch in GCN port for me ?
This patch *fixes* an existing test fail on GCN. :)
It's probably one of the many I've never had time to analyze (and
optimizing more than expected makes it low priority).
LGTM
Andrew
On Tue, 10 Oct 2023, Juzhe-Zhong wrote:
> Here is the reference comparing dump IR between ARM SVE and RVV.
>
> https://godbolt.org/z/zqess8Gss
>
> We can see RVV has one more dump IR:
> optimized: basic block part vectorized using 128 byte vectors
> since RVV has 1024 bit vectors.
>
> The codegen is reasonable good.
>
> However, I saw GCN also has 1024 bit vector.
> This patch may cause this case FAIL in GCN port ?
>
> Hi, GCN folk, could you check this patch in GCN port for me ?
OK
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-pr65935.c: Add vect1024 variant.
> * lib/target-supports.exp: Ditto.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c | 3 ++-
> gcc/testsuite/lib/target-supports.exp | 6 ++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c b/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c
> index 8df35327e7a..9ef1330b47c 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c
> @@ -67,7 +67,8 @@ int main()
>
> /* We should also be able to use 2-lane SLP to initialize the real and
> imaginary components in the first loop of main. */
> -/* { dg-final { scan-tree-dump-times "optimized: basic block" 10 "slp1" } } */
> +/* { dg-final { scan-tree-dump-times "optimized: basic block" 10 "slp1" { target {! { vect1024 } } } } } */
> +/* { dg-final { scan-tree-dump-times "optimized: basic block" 11 "slp1" { target { { vect1024 } } } } } */
> /* We should see the s->phase[dir] operand splatted and no other operand built
> from scalars. See PR97334. */
> /* { dg-final { scan-tree-dump "Using a splat" "slp1" } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index dc366d35a0a..95c489d7f76 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -8903,6 +8903,12 @@ proc check_effective_target_vect_variable_length { } {
> return [expr { [lindex [available_vector_sizes] 0] == 0 }]
> }
>
> +# Return 1 if the target supports vectors of 1024 bits.
> +
> +proc check_effective_target_vect1024 { } {
> + return [expr { [lsearch -exact [available_vector_sizes] 1024] >= 0 }]
> +}
> +
> # Return 1 if the target supports vectors of 512 bits.
>
> proc check_effective_target_vect512 { } {
>
@@ -67,7 +67,8 @@ int main()
/* We should also be able to use 2-lane SLP to initialize the real and
imaginary components in the first loop of main. */
-/* { dg-final { scan-tree-dump-times "optimized: basic block" 10 "slp1" } } */
+/* { dg-final { scan-tree-dump-times "optimized: basic block" 10 "slp1" { target {! { vect1024 } } } } } */
+/* { dg-final { scan-tree-dump-times "optimized: basic block" 11 "slp1" { target { { vect1024 } } } } } */
/* We should see the s->phase[dir] operand splatted and no other operand built
from scalars. See PR97334. */
/* { dg-final { scan-tree-dump "Using a splat" "slp1" } } */
@@ -8903,6 +8903,12 @@ proc check_effective_target_vect_variable_length { } {
return [expr { [lindex [available_vector_sizes] 0] == 0 }]
}
+# Return 1 if the target supports vectors of 1024 bits.
+
+proc check_effective_target_vect1024 { } {
+ return [expr { [lsearch -exact [available_vector_sizes] 1024] >= 0 }]
+}
+
# Return 1 if the target supports vectors of 512 bits.
proc check_effective_target_vect512 { } {