* [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
@ 2023-05-09 12:05 juzhe.zhong
2023-05-09 13:54 ` Kito Cheng
0 siblings, 1 reply; 7+ messages in thread
From: juzhe.zhong @ 2023-05-09 12:05 UTC (permalink / raw)
To: gcc-patches; +Cc: kito.cheng, palmer, jeffreyalaw, rdapp.gcc, Juzhe-Zhong
From: Juzhe-Zhong <juzhe.zhong@rivai.ai>
This incorrect codes blocks the scalable RVV auto-vectorization.
Take a look at this target hook implementation of aarch64.
They only have the similiar handling on TARGET_SIMD.
They let movmisalign<mode> to handle scalable vector of SVE.
For RVV, we should follow the same implementation of ARM SVE.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_support_vector_misalignment): Fix incorrect codes.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/v-2.c: Adapt testcase.
* gcc.target/riscv/rvv/autovec/zve32f-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64d-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64d-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64f-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64f-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64x-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64x-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c: Ditto.
---
gcc/config/riscv/riscv.cc | 21 +++++++------------
.../gcc.target/riscv/rvv/autovec/v-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve32f-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve32f-3.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve32x-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve32x-3.c | 2 +-
.../gcc.target/riscv/rvv/autovec/zve64d-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve64d-3.c | 4 ++--
.../riscv/rvv/autovec/zve64d_zvl128b-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve64f-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve64f-3.c | 4 ++--
.../riscv/rvv/autovec/zve64f_zvl128b-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve64x-2.c | 4 ++--
.../gcc.target/riscv/rvv/autovec/zve64x-3.c | 2 +-
.../riscv/rvv/autovec/zve64x_zvl128b-2.c | 2 +-
15 files changed, 32 insertions(+), 39 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 8684271f8ac..ff90c44d811 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7264,27 +7264,20 @@ riscv_estimated_poly_value (poly_int64 val,
return val.coeffs[0] + val.coeffs[1] * over_128 / 128;
}
+/* Return true if the vector misalignment factor is supported by the
+ target. */
bool
riscv_support_vector_misalignment (machine_mode mode,
const_tree type ATTRIBUTE_UNUSED,
int misalignment,
bool is_packed ATTRIBUTE_UNUSED)
{
- if (TARGET_VECTOR)
- {
- if (STRICT_ALIGNMENT)
- {
- /* Return if movmisalign pattern is not supported for this mode. */
- if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
- return false;
-
- /* Misalignment factor is unknown at compile time. */
- if (misalignment == -1)
- return false;
- }
- return true;
- }
+ /* TODO: For RVV scalable vector auto-vectorization, we should allow
+ movmisalign<mode> pattern to handle misalign data movement to unblock
+ possible auto-vectorization.
+ RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
+ in the future. */
return default_builtin_support_vector_misalignment (mode, type, misalignment,
is_packed);
}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/v-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/v-2.c
index 3d086e30081..66d8ea15f5b 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/v-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/v-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gcv -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gcv -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-2.c
index d6199665126..7cdc174c06f 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve32f -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve32f -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 3 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-3.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-3.c
index d5109c72045..5654a34ea5c 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32f-3.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve32f -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve32f -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 4 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-2.c
index 575e9479f94..1602f5f17d7 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve32x -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve32x -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 2 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-3.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-3.c
index 50e8963033b..5cc8f1462d6 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve32x-3.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve32x -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve32x -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
#include "template-1.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-2.c
index 0d6ebc53d1a..5e38b41a5c3 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64d -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64d -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 3 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-3.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-3.c
index 2a72030c3bc..6a23713d1ce 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-3.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64d -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64d -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c
index 9e236e0af1b..20429967f36 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64d_zvl128b -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64d_zvl128b -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-2.c
index 6bb6b919c77..ee37282f1f8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64f -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64f -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 3 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-3.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-3.c
index 43eca9d0727..a4618e00494 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-3.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64f -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64f -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 4 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c
index f1500074370..64caef5c6ef 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64f_zvl128b -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64f_zvl128b -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 4 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 5 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-2.c
index ede28e88dac..6a64a1a1fdf 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64x -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64x -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 2 "vect" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-3.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-3.c
index d59f7362b43..a30e73371ce 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-3.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64x -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64x -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m2 -fdump-tree-vect-details" } */
#include "template-1.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c
index 90398db52a0..b98a8704276 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv32gc_zve64x_zvl128b -mabi=ilp32d --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
+/* { dg-options "-march=rv32gc_zve64x_zvl128b -mabi=ilp32d -fno-vect-cost-model --param riscv-autovec-preference=fixed-vlmax -fdump-tree-vect-details" } */
#include "template-1.h"
--
2.36.3
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
2023-05-09 12:05 [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT juzhe.zhong
@ 2023-05-09 13:54 ` Kito Cheng
[not found] ` <1F0C200444EB77DD+4F441E6E-C2D1-420A-ADA7-B867BA6786FC@rivai.ai>
0 siblings, 1 reply; 7+ messages in thread
From: Kito Cheng @ 2023-05-09 13:54 UTC (permalink / raw)
To: juzhe.zhong; +Cc: gcc-patches, palmer, jeffreyalaw, rdapp.gcc
I am ok with both changes but I tried to build some test cases, and it
seems the changes are caused by options update, not caused by the
riscv_support_vector_misalignment update? so I would like to see the
testcase should split out into a separated patch.
> +/* Return true if the vector misalignment factor is supported by the
> + target. */
> bool
> riscv_support_vector_misalignment (machine_mode mode,
> const_tree type ATTRIBUTE_UNUSED,
> int misalignment,
> bool is_packed ATTRIBUTE_UNUSED)
> {
> - if (TARGET_VECTOR)
> - {
> - if (STRICT_ALIGNMENT)
> - {
> - /* Return if movmisalign pattern is not supported for this mode. */
> - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> - return false;
> -
> - /* Misalignment factor is unknown at compile time. */
> - if (misalignment == -1)
> - return false;
> - }
> - return true;
> - }
> + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> + movmisalign<mode> pattern to handle misalign data movement to unblock
> + possible auto-vectorization.
>
> + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> + in the future. */
> return default_builtin_support_vector_misalignment (mode, type, misalignment,
> is_packed);
> }
Should we have some corresponding change on autovec.md like this?
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index f1c5ff5951bf..c2873201d82e 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -51,7 +51,7 @@
(define_expand "movmisalign<mode>"
[(set (match_operand:V 0 "nonimmediate_operand")
(match_operand:V 1 "general_operand"))]
- "TARGET_VECTOR"
+ "TARGET_VECTOR && !STRICT_ALIGNMENT"
{
/* Equivalent to a normal move for our purpooses. */
emit_move_insn (operands[0], operands[1]);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
[not found] ` <1F0C200444EB77DD+4F441E6E-C2D1-420A-ADA7-B867BA6786FC@rivai.ai>
@ 2023-05-09 14:29 ` Kito Cheng
2023-05-09 14:36 ` 钟居哲
2023-05-09 14:36 ` Kito Cheng
0 siblings, 2 replies; 7+ messages in thread
From: Kito Cheng @ 2023-05-09 14:29 UTC (permalink / raw)
To: juzhe.zhong; +Cc: gcc-patches, palmer, jeffreyalaw, rdapp.gcc
Oh, checked default_builtin_support_vector_misalignment and I realized
we can just remove riscv_support_vector_misalignment at all...
On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zhong@rivai.ai> wrote:
>
> riscv_support_vector_misalignment update makes some of the testcase check fail. I have checked the those fails， they are reasonable. So I include test case adapt in this patch.
> ---- Replied Message ----
> FromKito Cheng<kito.cheng@gmail.com>
> Date05/09/2023 21:54
> Tojuzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai>
> Ccgcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> palmer@dabbelt.com<palmer@dabbelt.com>,
> jeffreyalaw@gmail.com<jeffreyalaw@gmail.com>,
> rdapp.gcc@gmail.com<rdapp.gcc@gmail.com>
> SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> I am ok with both changes but I tried to build some test cases, and it
> seems the changes are caused by options update, not caused by the
> riscv_support_vector_misalignment update? so I would like to see the
> testcase should split out into a separated patch.
>
> > +/* Return true if the vector misalignment factor is supported by the
> > + target. */
> > bool
> > riscv_support_vector_misalignment (machine_mode mode,
> > const_tree type ATTRIBUTE_UNUSED,
> > int misalignment,
> > bool is_packed ATTRIBUTE_UNUSED)
> > {
> > - if (TARGET_VECTOR)
> > - {
> > - if (STRICT_ALIGNMENT)
> > - {
> > - /* Return if movmisalign pattern is not supported for this mode. */
> > - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> > - return false;
> > -
> > - /* Misalignment factor is unknown at compile time. */
> > - if (misalignment == -1)
> > - return false;
> > - }
> > - return true;
> > - }
> > + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > + movmisalign<mode> pattern to handle misalign data movement to unblock
> > + possible auto-vectorization.
> >
> > + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> > + in the future. */
> > return default_builtin_support_vector_misalignment (mode, type, misalignment,
> > is_packed);
> > }
>
> Should we have some corresponding change on autovec.md like this?
>
> diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> index f1c5ff5951bf..c2873201d82e 100644
> --- a/gcc/config/riscv/autovec.md
> +++ b/gcc/config/riscv/autovec.md
> @@ -51,7 +51,7 @@
> (define_expand "movmisalign<mode>"
> [(set (match_operand:V 0 "nonimmediate_operand")
> (match_operand:V 1 "general_operand"))]
> - "TARGET_VECTOR"
> + "TARGET_VECTOR && !STRICT_ALIGNMENT"
> {
> /* Equivalent to a normal move for our purpooses. */
> emit_move_insn (operands[0], operands[1]);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
2023-05-09 14:29 ` Kito Cheng
@ 2023-05-09 14:36 ` 钟居哲
2023-05-09 14:36 ` Kito Cheng
1 sibling, 0 replies; 7+ messages in thread
From: 钟居哲 @ 2023-05-09 14:36 UTC (permalink / raw)
To: kito.cheng; +Cc: gcc-patches, palmer, Jeff Law, rdapp.gcc
[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]
Yes.... We can remove it but I still keep it here and add comment for TODO.
Since we may want to support it for VLS modes, like ARM SVE, they have Advanced SIMD modes (128bit VLS mode):
/* Return true if the vector misalignment factor is supported by the
target. */
static bool
aarch64_builtin_support_vector_misalignment (machine_mode mode,
const_tree type, int misalignment,
bool is_packed)
{
if (TARGET_SIMD && STRICT_ALIGNMENT)
{
/* Return if movmisalign pattern is not supported for this mode. */
if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
return false;
/* Misalignment factor is unknown at compile time. */
if (misalignment == -1)
return false;
}
return default_builtin_support_vector_misalignment (mode, type, misalignment,
is_packed);
}
This is ARM implementation, TAGET_SIMD is for Advance SIMD.
juzhe.zhong@rivai.ai
From: Kito Cheng
Date: 2023-05-09 22:29
To: juzhe.zhong
CC: gcc-patches@gcc.gnu.org; palmer@dabbelt.com; jeffreyalaw@gmail.com; rdapp.gcc@gmail.com
Subject: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
Oh, checked default_builtin_support_vector_misalignment and I realized
we can just remove riscv_support_vector_misalignment at all...
On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zhong@rivai.ai> wrote:
>
> riscv_support_vector_misalignment update makes some of the testcase check fail. I have checked the those fails， they are reasonable. So I include test case adapt in this patch.
> ---- Replied Message ----
> FromKito Cheng<kito.cheng@gmail.com>
> Date05/09/2023 21:54
> Tojuzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai>
> Ccgcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> palmer@dabbelt.com<palmer@dabbelt.com>,
> jeffreyalaw@gmail.com<jeffreyalaw@gmail.com>,
> rdapp.gcc@gmail.com<rdapp.gcc@gmail.com>
> SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> I am ok with both changes but I tried to build some test cases, and it
> seems the changes are caused by options update, not caused by the
> riscv_support_vector_misalignment update? so I would like to see the
> testcase should split out into a separated patch.
>
> > +/* Return true if the vector misalignment factor is supported by the
> > + target. */
> > bool
> > riscv_support_vector_misalignment (machine_mode mode,
> > const_tree type ATTRIBUTE_UNUSED,
> > int misalignment,
> > bool is_packed ATTRIBUTE_UNUSED)
> > {
> > - if (TARGET_VECTOR)
> > - {
> > - if (STRICT_ALIGNMENT)
> > - {
> > - /* Return if movmisalign pattern is not supported for this mode. */
> > - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> > - return false;
> > -
> > - /* Misalignment factor is unknown at compile time. */
> > - if (misalignment == -1)
> > - return false;
> > - }
> > - return true;
> > - }
> > + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > + movmisalign<mode> pattern to handle misalign data movement to unblock
> > + possible auto-vectorization.
> >
> > + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> > + in the future. */
> > return default_builtin_support_vector_misalignment (mode, type, misalignment,
> > is_packed);
> > }
>
> Should we have some corresponding change on autovec.md like this?
>
> diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> index f1c5ff5951bf..c2873201d82e 100644
> --- a/gcc/config/riscv/autovec.md
> +++ b/gcc/config/riscv/autovec.md
> @@ -51,7 +51,7 @@
> (define_expand "movmisalign<mode>"
> [(set (match_operand:V 0 "nonimmediate_operand")
> (match_operand:V 1 "general_operand"))]
> - "TARGET_VECTOR"
> + "TARGET_VECTOR && !STRICT_ALIGNMENT"
> {
> /* Equivalent to a normal move for our purpooses. */
> emit_move_insn (operands[0], operands[1]);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
2023-05-09 14:29 ` Kito Cheng
2023-05-09 14:36 ` 钟居哲
@ 2023-05-09 14:36 ` Kito Cheng
2023-05-09 15:21 ` 钟居哲
1 sibling, 1 reply; 7+ messages in thread
From: Kito Cheng @ 2023-05-09 14:36 UTC (permalink / raw)
To: juzhe.zhong; +Cc: gcc-patches, palmer, jeffreyalaw, rdapp.gcc
One more question from me: should we just add -fno-vect-cost-model to
AUTOVEC_TEST_OPTS?
On Tue, May 9, 2023 at 10:29 PM Kito Cheng <kito.cheng@gmail.com> wrote:
>
> Oh, checked default_builtin_support_vector_misalignment and I realized
> we can just remove riscv_support_vector_misalignment at all...
>
>
> On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zhong@rivai.ai> wrote:
> >
> > riscv_support_vector_misalignment update makes some of the testcase check fail. I have checked the those fails， they are reasonable. So I include test case adapt in this patch.
> > ---- Replied Message ----
> > FromKito Cheng<kito.cheng@gmail.com>
> > Date05/09/2023 21:54
> > Tojuzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai>
> > Ccgcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> > palmer@dabbelt.com<palmer@dabbelt.com>,
> > jeffreyalaw@gmail.com<jeffreyalaw@gmail.com>,
> > rdapp.gcc@gmail.com<rdapp.gcc@gmail.com>
> > SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> > I am ok with both changes but I tried to build some test cases, and it
> > seems the changes are caused by options update, not caused by the
> > riscv_support_vector_misalignment update? so I would like to see the
> > testcase should split out into a separated patch.
> >
> > > +/* Return true if the vector misalignment factor is supported by the
> > > + target. */
> > > bool
> > > riscv_support_vector_misalignment (machine_mode mode,
> > > const_tree type ATTRIBUTE_UNUSED,
> > > int misalignment,
> > > bool is_packed ATTRIBUTE_UNUSED)
> > > {
> > > - if (TARGET_VECTOR)
> > > - {
> > > - if (STRICT_ALIGNMENT)
> > > - {
> > > - /* Return if movmisalign pattern is not supported for this mode. */
> > > - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> > > - return false;
> > > -
> > > - /* Misalignment factor is unknown at compile time. */
> > > - if (misalignment == -1)
> > > - return false;
> > > - }
> > > - return true;
> > > - }
> > > + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > > + movmisalign<mode> pattern to handle misalign data movement to unblock
> > > + possible auto-vectorization.
> > >
> > > + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> > > + in the future. */
> > > return default_builtin_support_vector_misalignment (mode, type, misalignment,
> > > is_packed);
> > > }
> >
> > Should we have some corresponding change on autovec.md like this?
> >
> > diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> > index f1c5ff5951bf..c2873201d82e 100644
> > --- a/gcc/config/riscv/autovec.md
> > +++ b/gcc/config/riscv/autovec.md
> > @@ -51,7 +51,7 @@
> > (define_expand "movmisalign<mode>"
> > [(set (match_operand:V 0 "nonimmediate_operand")
> > (match_operand:V 1 "general_operand"))]
> > - "TARGET_VECTOR"
> > + "TARGET_VECTOR && !STRICT_ALIGNMENT"
> > {
> > /* Equivalent to a normal move for our purpooses. */
> > emit_move_insn (operands[0], operands[1]);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
2023-05-09 14:36 ` Kito Cheng
@ 2023-05-09 15:21 ` 钟居哲
2023-05-10 8:24 ` Kito Cheng
0 siblings, 1 reply; 7+ messages in thread
From: 钟居哲 @ 2023-05-09 15:21 UTC (permalink / raw)
To: kito.cheng; +Cc: gcc-patches, palmer, Jeff Law, rdapp.gcc
[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]
No, I don't think so. Some testcases the reason I added -fno-vect-cost-model here is
because we don't have enough patterns to enable some auto-vectorizations.
I add -fno-vect-cost-model to force enable auto-vectorizations for such cases for testing.
juzhe.zhong@rivai.ai
From: Kito Cheng
Date: 2023-05-09 22:36
To: juzhe.zhong
CC: gcc-patches@gcc.gnu.org; palmer@dabbelt.com; jeffreyalaw@gmail.com; rdapp.gcc@gmail.com
Subject: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
One more question from me: should we just add -fno-vect-cost-model to
AUTOVEC_TEST_OPTS?
On Tue, May 9, 2023 at 10:29 PM Kito Cheng <kito.cheng@gmail.com> wrote:
>
> Oh, checked default_builtin_support_vector_misalignment and I realized
> we can just remove riscv_support_vector_misalignment at all...
>
>
> On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zhong@rivai.ai> wrote:
> >
> > riscv_support_vector_misalignment update makes some of the testcase check fail. I have checked the those fails， they are reasonable. So I include test case adapt in this patch.
> > ---- Replied Message ----
> > FromKito Cheng<kito.cheng@gmail.com>
> > Date05/09/2023 21:54
> > Tojuzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai>
> > Ccgcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> > palmer@dabbelt.com<palmer@dabbelt.com>,
> > jeffreyalaw@gmail.com<jeffreyalaw@gmail.com>,
> > rdapp.gcc@gmail.com<rdapp.gcc@gmail.com>
> > SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> > I am ok with both changes but I tried to build some test cases, and it
> > seems the changes are caused by options update, not caused by the
> > riscv_support_vector_misalignment update? so I would like to see the
> > testcase should split out into a separated patch.
> >
> > > +/* Return true if the vector misalignment factor is supported by the
> > > + target. */
> > > bool
> > > riscv_support_vector_misalignment (machine_mode mode,
> > > const_tree type ATTRIBUTE_UNUSED,
> > > int misalignment,
> > > bool is_packed ATTRIBUTE_UNUSED)
> > > {
> > > - if (TARGET_VECTOR)
> > > - {
> > > - if (STRICT_ALIGNMENT)
> > > - {
> > > - /* Return if movmisalign pattern is not supported for this mode. */
> > > - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> > > - return false;
> > > -
> > > - /* Misalignment factor is unknown at compile time. */
> > > - if (misalignment == -1)
> > > - return false;
> > > - }
> > > - return true;
> > > - }
> > > + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > > + movmisalign<mode> pattern to handle misalign data movement to unblock
> > > + possible auto-vectorization.
> > >
> > > + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> > > + in the future. */
> > > return default_builtin_support_vector_misalignment (mode, type, misalignment,
> > > is_packed);
> > > }
> >
> > Should we have some corresponding change on autovec.md like this?
> >
> > diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> > index f1c5ff5951bf..c2873201d82e 100644
> > --- a/gcc/config/riscv/autovec.md
> > +++ b/gcc/config/riscv/autovec.md
> > @@ -51,7 +51,7 @@
> > (define_expand "movmisalign<mode>"
> > [(set (match_operand:V 0 "nonimmediate_operand")
> > (match_operand:V 1 "general_operand"))]
> > - "TARGET_VECTOR"
> > + "TARGET_VECTOR && !STRICT_ALIGNMENT"
> > {
> > /* Equivalent to a normal move for our purpooses. */
> > emit_move_insn (operands[0], operands[1]);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
2023-05-09 15:21 ` 钟居哲
@ 2023-05-10 8:24 ` Kito Cheng
0 siblings, 0 replies; 7+ messages in thread
From: Kito Cheng @ 2023-05-10 8:24 UTC (permalink / raw)
To: 钟居哲; +Cc: gcc-patches, palmer, Jeff Law, rdapp.gcc
Thanks, although I still have concern about that we should consider
check on movmisalign with STRICT_ALIGNMENT, but I am ok with this for
now, we can always fix that if got future issues.
committed to trunk
On Tue, May 9, 2023 at 11:22 PM 钟居哲 <juzhe.zhong@rivai.ai> wrote:
>
> No, I don't think so. Some testcases the reason I added -fno-vect-cost-model here is
> because we don't have enough patterns to enable some auto-vectorizations.
> I add -fno-vect-cost-model to force enable auto-vectorizations for such cases for testing.
>
>
>
> juzhe.zhong@rivai.ai
>
> From: Kito Cheng
> Date: 2023-05-09 22:36
> To: juzhe.zhong
> CC: gcc-patches@gcc.gnu.org; palmer@dabbelt.com; jeffreyalaw@gmail.com; rdapp.gcc@gmail.com
> Subject: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> One more question from me: should we just add -fno-vect-cost-model to
> AUTOVEC_TEST_OPTS?
>
> On Tue, May 9, 2023 at 10:29 PM Kito Cheng <kito.cheng@gmail.com> wrote:
> >
> > Oh, checked default_builtin_support_vector_misalignment and I realized
> > we can just remove riscv_support_vector_misalignment at all...
> >
> >
> > On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zhong@rivai.ai> wrote:
> > >
> > > riscv_support_vector_misalignment update makes some of the testcase check fail. I have checked the those fails， they are reasonable. So I include test case adapt in this patch.
> > > ---- Replied Message ----
> > > FromKito Cheng<kito.cheng@gmail.com>
> > > Date05/09/2023 21:54
> > > Tojuzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai>
> > > Ccgcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> > > palmer@dabbelt.com<palmer@dabbelt.com>,
> > > jeffreyalaw@gmail.com<jeffreyalaw@gmail.com>,
> > > rdapp.gcc@gmail.com<rdapp.gcc@gmail.com>
> > > SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> > > I am ok with both changes but I tried to build some test cases, and it
> > > seems the changes are caused by options update, not caused by the
> > > riscv_support_vector_misalignment update? so I would like to see the
> > > testcase should split out into a separated patch.
> > >
> > > > +/* Return true if the vector misalignment factor is supported by the
> > > > + target. */
> > > > bool
> > > > riscv_support_vector_misalignment (machine_mode mode,
> > > > const_tree type ATTRIBUTE_UNUSED,
> > > > int misalignment,
> > > > bool is_packed ATTRIBUTE_UNUSED)
> > > > {
> > > > - if (TARGET_VECTOR)
> > > > - {
> > > > - if (STRICT_ALIGNMENT)
> > > > - {
> > > > - /* Return if movmisalign pattern is not supported for this mode. */
> > > > - if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> > > > - return false;
> > > > -
> > > > - /* Misalignment factor is unknown at compile time. */
> > > > - if (misalignment == -1)
> > > > - return false;
> > > > - }
> > > > - return true;
> > > > - }
> > > > + /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > > > + movmisalign<mode> pattern to handle misalign data movement to unblock
> > > > + possible auto-vectorization.
> > > >
> > > > + RVV VLS auto-vectorization or SIMD auto-vectorization can be supported here
> > > > + in the future. */
> > > > return default_builtin_support_vector_misalignment (mode, type, misalignment,
> > > > is_packed);
> > > > }
> > >
> > > Should we have some corresponding change on autovec.md like this?
> > >
> > > diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> > > index f1c5ff5951bf..c2873201d82e 100644
> > > --- a/gcc/config/riscv/autovec.md
> > > +++ b/gcc/config/riscv/autovec.md
> > > @@ -51,7 +51,7 @@
> > > (define_expand "movmisalign<mode>"
> > > [(set (match_operand:V 0 "nonimmediate_operand")
> > > (match_operand:V 1 "general_operand"))]
> > > - "TARGET_VECTOR"
> > > + "TARGET_VECTOR && !STRICT_ALIGNMENT"
> > > {
> > > /* Equivalent to a normal move for our purpooses. */
> > > emit_move_insn (operands[0], operands[1]);
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-05-10 8:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-09 12:05 [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT juzhe.zhong
2023-05-09 13:54 ` Kito Cheng
[not found] ` <1F0C200444EB77DD+4F441E6E-C2D1-420A-ADA7-B867BA6786FC@rivai.ai>
2023-05-09 14:29 ` Kito Cheng
2023-05-09 14:36 ` 钟居哲
2023-05-09 14:36 ` Kito Cheng
2023-05-09 15:21 ` 钟居哲
2023-05-10 8:24 ` Kito Cheng
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).