Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 8/22/2024 5:35 AM, Richard Biener wrote:

On Thu, Aug 22, 2024 at 1:03 AM Edwin Lu  wrote:


Hi,

Just wanted to ping this for more guidance.


It's difficult for me as long as I cannot investigate this with a testcase.  Can
we go ahead with the other parts so the testcase can be added and the
issue reproduced?

Richard.


The testcase can be found in patch 1/2 of the series 
https://inbox.sourceware.org/gcc-patches/2024053512.2625173-2-patr...@rivosinc.com/ 
with the newly added gcc.target/riscv/rvv/autovec/no-segment.c file.


+cc Jeff, Palmer

From what I understand reading over the threads on the previous patch 
series versions, review for patch 1/2 has been deferred until this bug 
fix has been acked so we can't move forward with the other patch yet.


Edwin


On 7/24/2024 12:03 PM, Edwin Lu wrote:


On 7/24/2024 3:52 AM, Richard Biener wrote:

On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu  wrote:


On 7/23/2024 11:20 AM, Richard Sandiford wrote:

Edwin Lu  writes:

On 7/23/2024 4:56 AM, Richard Biener wrote:

On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu  wrote:

Hi Richard,

On 5/31/2024 1:48 AM, Richard Biener wrote:

On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill
 wrote:

From: Greg McGary 

Still a NACK.  If remain ends up zero then

 /* Try to use a single smaller load when
we are about
to load excess elements compared to
the unrolled
scalar loop.  */
 if (known_gt ((vec_num * j + i + 1) *
nunits,
(group_size * vf -
gap)))
   {
 poly_uint64 remain = ((group_size *
vf - gap)
   - (vec_num * j
+ i) * nunits);
 if (known_ge ((vec_num * j + i + 1)
* nunits
   - (group_size * vf -
gap), nunits))
   /* DR will be unused.  */
   ltype = NULL_TREE;

needs to be re-formulated so that the combined conditions make sure
this doesn't happen.  The outer known_gt should already ensure that
remain > 0.  For correctness that should possibly be maybe_gt
though.

Yeah.  FWIW, I mentioned the maybe_gt thing in
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653013.html:

 Pre-existing, but shouldn't this be maybe_gt rather than known_gt?
 We can only skip doing it if we know for sure that the load
won't cross
 the gap.  (Not sure whether the difference can trigger in
practice.)

But AFAICT, the known_gt doesn't inherently prove that remain is known
to be nonzero.  It just proves that the gap between the end of the
scalar
accesses and the end of this vector is known to be nonzero.

[switching round for easier reply]

[removed some clarification questions about poly_int and vector
representations]

What is j and i when the divisor is zero?

The values I see in gdb are: vec_num = 4 j = 0 i = 3 vf = {coeffs =
{2,
2}} nunits = {coeffs = {2, 2}} group_size = 4 gap = 2 vect_align = 2
remain = {coeffs = {0, 2}}

OK, so let's use D to mean "data" and G to mean "gap".  Then, for the
minimum vector length of 2 elements, we have:

 DD GG DD GG

The last load will read beyond the scalar loop if the vector loop
happens
to handle all elements of the scalar loop.

For a vector length of 4 elements, we have:

 DDGG DDGG DDGG DDGG

where every load contains both data and gaps.  The same will be true
for larger vectors.

That's where remain={0,2} is coming from.  The last load is fully
redundant
for the minimum VL but not for larger VL.
Based on that, the patch below looks correct to me, but I might have
misunderstood the intent.

As an alternative to the original patch, would this also make sense?

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index aab3aa59962..cd657ac63af 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11479,7 +11479,7 @@ vectorizable_load (vec_info *vinfo,
   /* Try to use a single smaller load when we are
about
  to load excess elements compared to the
unrolled
  scalar loop.  */
-   if (known_gt ((vec_num * j + i + 1) * nunits,
+   if (maybe_gt ((vec_num * j + i + 1) * nunits,
  (group_size * vf - gap)))
 {
   poly_uint64 remain = ((group_size * vf - gap)

That's a good point - this should indeed be maybe_gt


@@ -11502,6 +11502,10 @@ vectorizable_load (vec_info *vinfo,
 /* Aligned access to the gap area when
there's
at least one element in it is OK.  */
 ;
+   else if (maybe_eq (remain,

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

Hi,

Just wanted to ping this for more guidance.

Edwin

On 7/24/2024 12:03 PM, Edwin Lu wrote:


On 7/24/2024 3:52 AM, Richard Biener wrote:

On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu  wrote:


On 7/23/2024 11:20 AM, Richard Sandiford wrote:

Edwin Lu  writes:

On 7/23/2024 4:56 AM, Richard Biener wrote:

On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu  wrote:

Hi Richard,

On 5/31/2024 1:48 AM, Richard Biener wrote:
On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill 
 wrote:

From: Greg McGary 

Still a NACK.  If remain ends up zero then

    /* Try to use a single smaller load when 
we are about
   to load excess elements compared to 
the unrolled

   scalar loop.  */
    if (known_gt ((vec_num * j + i + 1) * 
nunits,
   (group_size * vf - 
gap)))

  {
    poly_uint64 remain = ((group_size * 
vf - gap)
  - (vec_num * j 
+ i) * nunits);
    if (known_ge ((vec_num * j + i + 1) 
* nunits
  - (group_size * vf - 
gap), nunits))

  /* DR will be unused.  */
  ltype = NULL_TREE;

needs to be re-formulated so that the combined conditions make sure
this doesn't happen.  The outer known_gt should already ensure that
remain > 0.  For correctness that should possibly be maybe_gt 
though.

Yeah.  FWIW, I mentioned the maybe_gt thing in
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653013.html:

    Pre-existing, but shouldn't this be maybe_gt rather than known_gt?
    We can only skip doing it if we know for sure that the load 
won't cross
    the gap.  (Not sure whether the difference can trigger in 
practice.)


But AFAICT, the known_gt doesn't inherently prove that remain is known
to be nonzero.  It just proves that the gap between the end of the 
scalar

accesses and the end of this vector is known to be nonzero.

[switching round for easier reply]
[removed some clarification questions about poly_int and vector 
representations]

What is j and i when the divisor is zero?
The values I see in gdb are: vec_num = 4 j = 0 i = 3 vf = {coeffs = 
{2,

2}} nunits = {coeffs = {2, 2}} group_size = 4 gap = 2 vect_align = 2
remain = {coeffs = {0, 2}}

OK, so let's use D to mean "data" and G to mean "gap".  Then, for the
minimum vector length of 2 elements, we have:

    DD GG DD GG

The last load will read beyond the scalar loop if the vector loop 
happens

to handle all elements of the scalar loop.

For a vector length of 4 elements, we have:

    DDGG DDGG DDGG DDGG

where every load contains both data and gaps.  The same will be true
for larger vectors.

That's where remain={0,2} is coming from.  The last load is fully 
redundant

for the minimum VL but not for larger VL.
Based on that, the patch below looks correct to me, but I might have
misunderstood the intent.

As an alternative to the original patch, would this also make sense?

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index aab3aa59962..cd657ac63af 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11479,7 +11479,7 @@ vectorizable_load (vec_info *vinfo,
  /* Try to use a single smaller load when we are 
about
 to load excess elements compared to the 
unrolled

 scalar loop.  */
-   if (known_gt ((vec_num * j + i + 1) * nunits,
+   if (maybe_gt ((vec_num * j + i + 1) * nunits,
 (group_size * vf - gap)))
    {
  poly_uint64 remain = ((group_size * vf - gap)

That's a good point - this should indeed be maybe_gt


@@ -11502,6 +11502,10 @@ vectorizable_load (vec_info *vinfo,
    /* Aligned access to the gap area when 
there's

   at least one element in it is OK.  */
    ;
+   else if (maybe_eq (remain, 0))
+ /* Handle remain.coeffs[0] == 0 case. 
Number of
+    elements is an exact multiple of vector 
length.  */

+ ;

Hmm, but here it should be known_eq?  And why doesn't
constant_multiple_p work then?  I think remain.coeffs[1] is never
negative here, but that would be another way to arrive at zero.


If I use known_eq, the condition would be skipped and we'll enter the
final else statement which triggers the floating point exception in
constant_multiple_p.

I don't know what it would mean for remain.coeffs[1] to be negative.
To me it doesn't really make sense given my understanding that
it represents the number of additional chunks beyond the minimum vector
size. 

Re: [Committed] RISC-V: Remove testcase XFAIL

[Edwin Lu]

Thanks!

Edwin

On 8/19/2024 1:17 PM, Jeff Law wrote:



On 8/19/24 2:14 PM, Edwin Lu wrote:

The testcase has been modified to include the -fwrapv flag which now
causes the test to pass. Remove the xfail exception

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-5.c: Remove riscv xfail exception

OK
jeff

[PATCH] RISC-V: Remove testcase XFAIL

[Edwin Lu]

The testcase has been modified to include the -fwrapv flag which now
causes the test to pass. Remove the xfail exception

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-5.c: Remove riscv xfail exception

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.dg/signbit-5.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/signbit-5.c b/gcc/testsuite/gcc.dg/signbit-5.c
index 2bca640f930..e65c8910c82 100644
--- a/gcc/testsuite/gcc.dg/signbit-5.c
+++ b/gcc/testsuite/gcc.dg/signbit-5.c
@@ -4,7 +4,6 @@
 /* This test does not work when the truth type does not match vector type.  */
 /* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
 /* { dg-xfail-run-if "truth type does not match vector type" { amdgcn-*-* } } 
*/
-/* { dg-xfail-run-if "truth type does not match vector type" { riscv_v } } */
 
 
 #include 
-- 
2.34.1

Re: [Committed] RISC-V: Fix missing abi arg in test

[Edwin Lu]

Thanks!

Edwin

On 8/8/2024 12:24 AM, Robin Dapp wrote:

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
index d150f20b5d9..02814183dbb 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
@@ -1,5 +1,5 @@
  /* { dg-do run } */
-/* { dg-options "-O3 -march=rv64gcv_zvl256b -fdump-rtl-expand-details" } */
+/* { dg-options "-O3 -march=rv64gcv_zvl256b -mabi=lp64d 
-fdump-rtl-expand-details" } */
  
  int b[24];

  _Bool c[24];

OK.

We really want to have an march imply an mabi, especially if there's no other
choice anyway.

[PATCH] RISC-V: Fix missing abi arg in test

[Edwin Lu]

The following test was failing when building on 32 bit targets
due to not overwriting the mabi arg. This resulted in dejagnu
attempting to run the test with -mabi=ilp32d -march=rv64gcv_zvl256b

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr116202-run-1.c: Add mabi arg

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
index d150f20b5d9..02814183dbb 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-O3 -march=rv64gcv_zvl256b -fdump-rtl-expand-details" } */
+/* { dg-options "-O3 -march=rv64gcv_zvl256b -mabi=lp64d 
-fdump-rtl-expand-details" } */
 
 int b[24];
 _Bool c[24];
-- 
2.34.1

Re: [Committed] RISC-V: Add configure check for B extention support

[Edwin Lu]

Thanks! Committed

Edwin

On 7/29/2024 6:37 AM, Kito Cheng wrote:

LGTM, although I said no binutils check for zacas and zabha, but B is
a different situation since GCC will add that if zba, zbb and zbs are
all present.



On Thu, Jul 25, 2024 at 7:51 AM Edwin Lu  wrote:

Binutils 2.42 and before don't recognize the B extension in the march
strings even though it supports zba_zbb_zbs. Add a configure check to
ignore the B in the march string if found.

gcc/ChangeLog:

 * common/config/riscv/riscv-common.cc (riscv_subset_list::to_string):
 Skip b in march string
 * config.in: Regenerate.
 * configure: Regenerate.
 * configure.ac: Add B assembler check

Signed-off-by: Edwin Lu 
---
  gcc/common/config/riscv/riscv-common.cc |  8 +++
  gcc/config.in   |  6 +
  gcc/configure   | 31 +
  gcc/configure.ac|  5 
  4 files changed, 50 insertions(+)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 682826c0e34..200a57e1bc8 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -857,6 +857,7 @@ riscv_subset_list::to_string (bool version_p) const
bool skip_zaamo_zalrsc = false;
bool skip_zabha = false;
bool skip_zicsr = false;
+  bool skip_b = false;
bool i2p0 = false;

/* For RISC-V ISA version 2.2 or earlier version, zicsr and zifencei is
@@ -891,6 +892,10 @@ riscv_subset_list::to_string (bool version_p) const
/* Skip since binutils 2.42 and earlier don't recognize zabha.  */
skip_zabha = true;
  #endif
+#ifndef HAVE_AS_MARCH_B
+  /* Skip since binutils 2.42 and earlier don't recognize b.  */
+  skip_b = true;
+#endif

for (subset = m_head; subset != NULL; subset = subset->next)
  {
@@ -911,6 +916,9 @@ riscv_subset_list::to_string (bool version_p) const
if (skip_zabha && subset->name == "zabha")
 continue;

+  if (skip_b && subset->name == "b")
+   continue;
+
/* For !version_p, we only separate extension with underline for
  multi-letter extension.  */
if (!first &&
diff --git a/gcc/config.in b/gcc/config.in
index bc819005bd6..96e829b9c93 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -629,6 +629,12 @@
  #endif


+/* Define if the assembler understands -march=rv*_b. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_MARCH_B
+#endif
+
+
  /* Define if the assembler understands -march=rv*_zaamo_zalrsc. */
  #ifndef USED_FOR_TARGET
  #undef HAVE_AS_MARCH_ZAAMO_ZALRSC
diff --git a/gcc/configure b/gcc/configure
index 01acca7fb5c..c5725c4cd44 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30913,6 +30913,37 @@ if test $gcc_cv_as_riscv_march_zabha = yes; then

  $as_echo "#define HAVE_AS_MARCH_ZABHA 1" >>confdefs.h

+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for -march=rv32i_b 
support" >&5
+$as_echo_n "checking assembler for -march=rv32i_b support... " >&6; }
+if ${gcc_cv_as_riscv_march_b+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_riscv_march_b=no
+  if test x$gcc_cv_as != x; then
+$as_echo '' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -march=rv32i_b -o conftest.o conftest.s 
>&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   gcc_cv_as_riscv_march_b=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_riscv_march_b" >&5
+$as_echo "$gcc_cv_as_riscv_march_b" >&6; }
+if test $gcc_cv_as_riscv_march_b = yes; then
+
+$as_echo "#define HAVE_AS_MARCH_B 1" >>confdefs.h
+
  fi

  ;;
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 3f20c107b6a..93d9236ff36 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5466,6 +5466,11 @@ configured with --enable-newlib-nano-formatted-io.])
[-march=rv32i_zabha],,,
[AC_DEFINE(HAVE_AS_MARCH_ZABHA, 1,
  [Define if the assembler understands -march=rv*_zabha.])])
+gcc_GAS_CHECK_FEATURE([-march=rv32i_b support],
+  gcc_cv_as_riscv_march_b,
+  [-march=rv32i_b],,,
+  [AC_DEFINE(HAVE_AS_MARCH_B, 1,
+[Define if the assembler understands -march=rv*_b.])])
  ;;
  loongarch*-*-*)
  gcc_GAS_CHECK_FEATURE([.dtprelword support],
--
2.34.1

[PATCH] RISC-V: Add configure check for B extention support

[Edwin Lu]

Binutils 2.42 and before don't recognize the B extension in the march
strings even though it supports zba_zbb_zbs. Add a configure check to
ignore the B in the march string if found.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_subset_list::to_string):
Skip b in march string
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add B assembler check

Signed-off-by: Edwin Lu 
---
 gcc/common/config/riscv/riscv-common.cc |  8 +++
 gcc/config.in   |  6 +
 gcc/configure   | 31 +
 gcc/configure.ac|  5 
 4 files changed, 50 insertions(+)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 682826c0e34..200a57e1bc8 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -857,6 +857,7 @@ riscv_subset_list::to_string (bool version_p) const
   bool skip_zaamo_zalrsc = false;
   bool skip_zabha = false;
   bool skip_zicsr = false;
+  bool skip_b = false;
   bool i2p0 = false;
 
   /* For RISC-V ISA version 2.2 or earlier version, zicsr and zifencei is
@@ -891,6 +892,10 @@ riscv_subset_list::to_string (bool version_p) const
   /* Skip since binutils 2.42 and earlier don't recognize zabha.  */
   skip_zabha = true;
 #endif
+#ifndef HAVE_AS_MARCH_B
+  /* Skip since binutils 2.42 and earlier don't recognize b.  */
+  skip_b = true;
+#endif
 
   for (subset = m_head; subset != NULL; subset = subset->next)
 {
@@ -911,6 +916,9 @@ riscv_subset_list::to_string (bool version_p) const
   if (skip_zabha && subset->name == "zabha")
continue;
 
+  if (skip_b && subset->name == "b")
+   continue;
+
   /* For !version_p, we only separate extension with underline for
 multi-letter extension.  */
   if (!first &&
diff --git a/gcc/config.in b/gcc/config.in
index bc819005bd6..96e829b9c93 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -629,6 +629,12 @@
 #endif
 
 
+/* Define if the assembler understands -march=rv*_b. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_MARCH_B
+#endif
+
+
 /* Define if the assembler understands -march=rv*_zaamo_zalrsc. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_MARCH_ZAAMO_ZALRSC
diff --git a/gcc/configure b/gcc/configure
index 01acca7fb5c..c5725c4cd44 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30913,6 +30913,37 @@ if test $gcc_cv_as_riscv_march_zabha = yes; then
 
 $as_echo "#define HAVE_AS_MARCH_ZABHA 1" >>confdefs.h
 
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
-march=rv32i_b support" >&5
+$as_echo_n "checking assembler for -march=rv32i_b support... " >&6; }
+if ${gcc_cv_as_riscv_march_b+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_riscv_march_b=no
+  if test x$gcc_cv_as != x; then
+$as_echo '' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -march=rv32i_b -o conftest.o 
conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   gcc_cv_as_riscv_march_b=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_riscv_march_b" >&5
+$as_echo "$gcc_cv_as_riscv_march_b" >&6; }
+if test $gcc_cv_as_riscv_march_b = yes; then
+
+$as_echo "#define HAVE_AS_MARCH_B 1" >>confdefs.h
+
 fi
 
 ;;
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 3f20c107b6a..93d9236ff36 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5466,6 +5466,11 @@ configured with --enable-newlib-nano-formatted-io.])
   [-march=rv32i_zabha],,,
   [AC_DEFINE(HAVE_AS_MARCH_ZABHA, 1,
 [Define if the assembler understands -march=rv*_zabha.])])
+gcc_GAS_CHECK_FEATURE([-march=rv32i_b support],
+  gcc_cv_as_riscv_march_b,
+  [-march=rv32i_b],,,
+  [AC_DEFINE(HAVE_AS_MARCH_B, 1,
+[Define if the assembler understands -march=rv*_b.])])
 ;;
 loongarch*-*-*)
 gcc_GAS_CHECK_FEATURE([.dtprelword support],
-- 
2.34.1

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 7/24/2024 3:03 AM, Robin Dapp wrote:

Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the
vector can have (for 128b vector operating on 32b elements, B == 4, but if
operating on 64b elements B == 2); however, I'm not too sure what A
represents.

The runtime size of a vector is a polynomial with a "base size" of A and
"increments beyond A" of B.  B is compile-time variable/indeterminate and
runtime invariant.  For (non-zve32) RVV it specifies the number of 64-bit
chunks beyond the minimum size of 64 bits.  The polynomial is [2 2] in that
case and the "vector bit size" would be
   64 * [2 2] = [128 128] = 128 + x * 128.
For a runtime vector size of 256 bits, x would be 1 and so on and we determine
it at runtime via csrr.


On the poly_int docs, it says

An indeterminate value of 0 should usually represent the minimum possible
runtime value, with c0 specifying the value in that case.

"minimum possible runtime value" doesn't make sense to me. Does it mean the
potential minimum bound of elements it will operate on?

This refers to the minimum runtime size of a vector, the constant 2 * 64 bit
above.  So it doesn't talk about the number of elements.  The number of
elements can be deducted from the "vector size" polynomial by dividing it by
the element size.  The minimum number of elements for an element size S could
e.g. be [128 128] / S = 128 / S + x * (128 / S).


I think all of this makes sense to me! Thanks for all the explanations!

Edwin

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 7/24/2024 3:03 AM, Robin Dapp wrote:

Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the
vector can have (for 128b vector operating on 32b elements, B == 4, but if
operating on 64b elements B == 2); however, I'm not too sure what A
represents.

The runtime size of a vector is a polynomial with a "base size" of A and
"increments beyond A" of B.  B is compile-time variable/indeterminate and
runtime invariant.  For (non-zve32) RVV it specifies the number of 64-bit
chunks beyond the minimum size of 64 bits.  The polynomial is [2 2] in that
case and the "vector bit size" would be
   64 * [2 2] = [128 128] = 128 + x * 128.
For a runtime vector size of 256 bits, x would be 1 and so on and we determine
it at runtime via csrr.


On the poly_int docs, it says

An indeterminate value of 0 should usually represent the minimum possible
runtime value, with c0 specifying the value in that case.

"minimum possible runtime value" doesn't make sense to me. Does it mean the
potential minimum bound of elements it will operate on?

This refers to the minimum runtime size of a vector, the constant 2 * 64 bit
above.  So it doesn't talk about the number of elements.  The number of
elements can be deducted from the "vector size" polynomial by dividing it by
the element size.  The minimum number of elements for an element size S could
e.g. be [128 128] / S = 128 / S + x * (128 / S).


I think all of this makes sense to me! Thanks for all the explanations!

Edwin

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 7/24/2024 3:52 AM, Richard Biener wrote:

On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu  wrote:


On 7/23/2024 11:20 AM, Richard Sandiford wrote:

Edwin Lu  writes:

On 7/23/2024 4:56 AM, Richard Biener wrote:

On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu  wrote:

Hi Richard,

On 5/31/2024 1:48 AM, Richard Biener wrote:

On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill  wrote:

From: Greg McGary 

Still a NACK.  If remain ends up zero then

/* Try to use a single smaller load when we are about
   to load excess elements compared to the unrolled
   scalar loop.  */
if (known_gt ((vec_num * j + i + 1) * nunits,
   (group_size * vf - gap)))
  {
poly_uint64 remain = ((group_size * vf - gap)
  - (vec_num * j + i) * nunits);
if (known_ge ((vec_num * j + i + 1) * nunits
  - (group_size * vf - gap), nunits))
  /* DR will be unused.  */
  ltype = NULL_TREE;

needs to be re-formulated so that the combined conditions make sure
this doesn't happen.  The outer known_gt should already ensure that
remain > 0.  For correctness that should possibly be maybe_gt though.

Yeah.  FWIW, I mentioned the maybe_gt thing in
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653013.html:

Pre-existing, but shouldn't this be maybe_gt rather than known_gt?
We can only skip doing it if we know for sure that the load won't cross
the gap.  (Not sure whether the difference can trigger in practice.)

But AFAICT, the known_gt doesn't inherently prove that remain is known
to be nonzero.  It just proves that the gap between the end of the scalar
accesses and the end of this vector is known to be nonzero.


Putting the list back in the loop and CCing Richard S.


I'm currently looking into this patch and am trying to figure out what
is going on. Stepping through gdb, I see that remain == {coeffs = {0,
2}} and nunits == {coeffs = {2, 2}} (the outer known_gt returned true
with known_gt({coeffs = {8, 8}}, {coeffs = {6, 8}})).

From what I understand, this falls under the umbrella of 0 <= remain <
nunits. The divide by zero error is because of the 0 <= remain which is
coming from the constant_multiple_p function in poly-int.h where it
performs the modulus NCa(a.coeffs[0]) % NCb(b.coeffs[0]).
(https://github.com/gcc-mirror/gcc/blob/master/gcc/poly-int.h#L1970-L1971)


>  if (known_ge ((vec_num * j + i + 1) * nunits
>- (group_size * vf - gap),
nunits))
>/* DR will be unused.  */
>ltype = NULL_TREE;

This if condition is a bit suspicious to me though. I'm seeing that it's
evaluating known_ge({coeffs = {2, 0}}, {coeffs = {2, 2}}) which is
returning false. Should it be maybe_ge instead?

No, we can only not emit a load if we know it won't be used, not if
it eventually cannot be used.

Agreed.

[switching round for easier reply]

After running some
tests, to me it looks like it doesn't vectorize quite as often; however,
I'm not fully sure what else to do when the coeffs can potentially be
equal to 0.

Should it even be possible for there to be a {coeffs = {0, n}}
situation? My understanding of how poly_ints are used for representing
vectorization is that the first coefficient is the number of elements
needed to make the minimum supported vector size. That is, if vector
lengths are 128 bits, element size is 32 bits, coeff[0] should be
minimum of 4. Is this understanding correct?

I was told n can be negative, but nunits.coeff[0] should be non-zero.

What would it mean for the coeffs[0] to be 0? Would that mean the vector length 
supports 0 bits?

coeffs = {A,B} just means A+B*X, where X is the number of vector
"chunks" beyond the minimum length.  It's certainly valid for a poly_int
to have a zero coeffs[0] (i.e. zero A).  For example, (the length of a
vector) - (the minimum length) would have this property.

Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the vector 
can have (for 128b vector operating on 32b elements, B == 4, but if operating 
on 64b elements B == 2); however, I'm not too sure what A represents.

On the poly_int docs, it says

An indeterminate value of 0 should usually represent the minimum possible 
runtime value, with c0 specifying the value in that case.

"minimum possible runtime value" doesn't make sense to me. Does it mean the 
potential minimum bound of elements it will operate on?


What is j and i when the divi

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 7/23/2024 11:20 AM, Richard Sandiford wrote:

Edwin Lu  writes:

On 7/23/2024 4:56 AM, Richard Biener wrote:

On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu  wrote:

Hi Richard,

On 5/31/2024 1:48 AM, Richard Biener wrote:

On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill  wrote:

From: Greg McGary 

Still a NACK.  If remain ends up zero then

   /* Try to use a single smaller load when we are about
  to load excess elements compared to the unrolled
  scalar loop.  */
   if (known_gt ((vec_num * j + i + 1) * nunits,
  (group_size * vf - gap)))
 {
   poly_uint64 remain = ((group_size * vf - gap)
 - (vec_num * j + i) * nunits);
   if (known_ge ((vec_num * j + i + 1) * nunits
 - (group_size * vf - gap), nunits))
 /* DR will be unused.  */
 ltype = NULL_TREE;

needs to be re-formulated so that the combined conditions make sure
this doesn't happen.  The outer known_gt should already ensure that
remain > 0.  For correctness that should possibly be maybe_gt though.

Yeah.  FWIW, I mentioned the maybe_gt thing in
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653013.html:

   Pre-existing, but shouldn't this be maybe_gt rather than known_gt?
   We can only skip doing it if we know for sure that the load won't cross
   the gap.  (Not sure whether the difference can trigger in practice.)

But AFAICT, the known_gt doesn't inherently prove that remain is known
to be nonzero.  It just proves that the gap between the end of the scalar
accesses and the end of this vector is known to be nonzero.


Putting the list back in the loop and CCing Richard S.


I'm currently looking into this patch and am trying to figure out what
is going on. Stepping through gdb, I see that remain == {coeffs = {0,
2}} and nunits == {coeffs = {2, 2}} (the outer known_gt returned true
with known_gt({coeffs = {8, 8}}, {coeffs = {6, 8}})).

   From what I understand, this falls under the umbrella of 0 <= remain <
nunits. The divide by zero error is because of the 0 <= remain which is
coming from the constant_multiple_p function in poly-int.h where it
performs the modulus NCa(a.coeffs[0]) % NCb(b.coeffs[0]).
(https://github.com/gcc-mirror/gcc/blob/master/gcc/poly-int.h#L1970-L1971)


   >  if (known_ge ((vec_num * j + i + 1) * nunits
   >- (group_size * vf - gap),
nunits))
   >/* DR will be unused.  */
   >ltype = NULL_TREE;

This if condition is a bit suspicious to me though. I'm seeing that it's
evaluating known_ge({coeffs = {2, 0}}, {coeffs = {2, 2}}) which is
returning false. Should it be maybe_ge instead?

No, we can only not emit a load if we know it won't be used, not if
it eventually cannot be used.

Agreed.

[switching round for easier reply]

After running some
tests, to me it looks like it doesn't vectorize quite as often; however,
I'm not fully sure what else to do when the coeffs can potentially be
equal to 0.

Should it even be possible for there to be a {coeffs = {0, n}}
situation? My understanding of how poly_ints are used for representing
vectorization is that the first coefficient is the number of elements
needed to make the minimum supported vector size. That is, if vector
lengths are 128 bits, element size is 32 bits, coeff[0] should be
minimum of 4. Is this understanding correct?

I was told n can be negative, but nunits.coeff[0] should be non-zero.

What would it mean for the coeffs[0] to be 0? Would that mean the vector length 
supports 0 bits?

coeffs = {A,B} just means A+B*X, where X is the number of vector
"chunks" beyond the minimum length.  It's certainly valid for a poly_int
to have a zero coeffs[0] (i.e. zero A).  For example, (the length of a
vector) - (the minimum length) would have this property.


Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the vector 
can have (for 128b vector operating on 32b elements, B == 4, but if operating 
on 64b elements B == 2); however, I'm not too sure what A represents.

On the poly_int docs, it says

An indeterminate value of 0 should usually represent the minimum possible 
runtime value, with c0 specifying the value in that case.

"minimum possible runtime value" doesn't make sense to me. Does it mean the 
potential minimum bound of elements it will operate on?


What is j and i when the divisor is zero?

The values I see in gdb are: vec_num = 4 j = 0 i = 3 vf = {coeffs = {2,
2}} nunits = {coeffs = {2, 2}} grou

Re: [PATCH v3 2/2] Prevent divide-by-zero

[Edwin Lu]

On 7/23/2024 4:56 AM, Richard Biener wrote:

On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu  wrote:

Hi Richard,

On 5/31/2024 1:48 AM, Richard Biener wrote:

On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill  wrote:

From: Greg McGary 

Still a NACK.  If remain ends up zero then

  /* Try to use a single smaller load when we are about
 to load excess elements compared to the unrolled
 scalar loop.  */
  if (known_gt ((vec_num * j + i + 1) * nunits,
 (group_size * vf - gap)))
{
  poly_uint64 remain = ((group_size * vf - gap)
- (vec_num * j + i) * nunits);
  if (known_ge ((vec_num * j + i + 1) * nunits
- (group_size * vf - gap), nunits))
/* DR will be unused.  */
ltype = NULL_TREE;

needs to be re-formulated so that the combined conditions make sure
this doesn't happen.  The outer known_gt should already ensure that
remain > 0.  For correctness that should possibly be maybe_gt though.


Putting the list back in the loop and CCing Richard S.


I'm currently looking into this patch and am trying to figure out what
is going on. Stepping through gdb, I see that remain == {coeffs = {0,
2}} and nunits == {coeffs = {2, 2}} (the outer known_gt returned true
with known_gt({coeffs = {8, 8}}, {coeffs = {6, 8}})).

  From what I understand, this falls under the umbrella of 0 <= remain <
nunits. The divide by zero error is because of the 0 <= remain which is
coming from the constant_multiple_p function in poly-int.h where it
performs the modulus NCa(a.coeffs[0]) % NCb(b.coeffs[0]).
(https://github.com/gcc-mirror/gcc/blob/master/gcc/poly-int.h#L1970-L1971)


  >  if (known_ge ((vec_num * j + i + 1) * nunits
  >- (group_size * vf - gap),
nunits))
  >/* DR will be unused.  */
  >ltype = NULL_TREE;

This if condition is a bit suspicious to me though. I'm seeing that it's
evaluating known_ge({coeffs = {2, 0}}, {coeffs = {2, 2}}) which is
returning false. Should it be maybe_ge instead?

No, we can only not emit a load if we know it won't be used, not if
it eventually cannot be used.


After running some
tests, to me it looks like it doesn't vectorize quite as often; however,
I'm not fully sure what else to do when the coeffs can potentially be
equal to 0.

Should it even be possible for there to be a {coeffs = {0, n}}
situation? My understanding of how poly_ints are used for representing
vectorization is that the first coefficient is the number of elements
needed to make the minimum supported vector size. That is, if vector
lengths are 128 bits, element size is 32 bits, coeff[0] should be
minimum of 4. Is this understanding correct?

I was told n can be negative, but nunits.coeff[0] should be non-zero.

What is j and i when the divisor is zero?


The values I see in gdb are: vec_num = 4 j = 0 i = 3 vf = {coeffs = {2, 
2}} nunits = {coeffs = {2, 2}} group_size = 4 gap = 2 vect_align = 2 
remain = {coeffs = {0, 2}}


What would it mean for the coeffs[0] to be 0? Would that mean the vector length 
supports 0 bits?


gcc/ChangeLog:
  * gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent 
divide-by-zero.
  * testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove dg-ice.
---
No changes in v3. Depends on the risc-v backend option added in patch 1 to
trigger the ICE.
---
   gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c | 1 -
   gcc/tree-vect-stmts.cc  | 3 ++-
   2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
index dfbe09f01a1..79d03612a22 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
@@ -1,6 +1,5 @@
   /* { dg-do compile } */
   /* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=scalable -O3 
-mno-autovec-segment" } */
-/* { dg-ice "Floating point exception" } */

   enum e { c, d };
   enum g { f };
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4219ad832db..34f5736ba00 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11558,7 +11558,8 @@ vectorizable_load (vec_info *vinfo,
   - (vec_num * j + i) * nunits);
  /* remain should now be > 0 and < nunits.  */
  unsigned num;
-   if (constant_multiple_p (nunits, remain, &num))
+   i

Re: [PATCH v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

[Edwin Lu]

Hi Kito,


On 7/22/2024 8:19 AM, Kito Cheng wrote:

Corresponding implementation in compiler-rt already merged in LLVM
side, so I plan to merge this into trunk tomorrow if no strong
objections.

NOTE: This has been tested with clang/llvm within our internal CI.



On Mon, Jul 22, 2024 at 10:16 PM Kito Cheng  wrote:


This provides a common abstraction layer to probe the available extensions at
run-time. These functions can be used to implement function multi-versioning or
to detect available extensions.

The advantages of providing this abstraction layer are:
- Easy to port to other new platforms.
- Easier to maintain in GCC for function multi-versioning.
   - For example, maintaining platform-dependent code in C code/libgcc is much
 easier than maintaining it in GCC by creating GIMPLEs...

This API is intended to provide the capability to query minimal common 
available extensions on the system.

Proposal in riscv-c-api-doc: 
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74

Full function multi-versioning implementation will come later. We are posting
this first because we intend to backport it to the GCC 14 branch to unblock
LLVM 19 to use this with GCC 14.2, rather than waiting for GCC 15.

Changes since v2:
- Prevent it initialize more than once.

Changes since v1:
- Fix the format.
- Prevented race conditions by introducing a local variable to avoid load/store
   operations during the computation of the feature bit.

libgcc/ChangeLog:

 * config/riscv/feature_bits.c: New.
 * config/riscv/t-elf (LIB2ADD): Add feature_bits.c.
---
  libgcc/config/riscv/feature_bits.c | 313 +
  libgcc/config/riscv/t-elf  |   1 +
  2 files changed, 314 insertions(+)
  create mode 100644 libgcc/config/riscv/feature_bits.c

diff --git a/libgcc/config/riscv/feature_bits.c 
b/libgcc/config/riscv/feature_bits.c
new file mode 100644
index 000..cce4fbfa6be
--- /dev/null
+++ b/libgcc/config/riscv/feature_bits.c
@@ -0,0 +1,313 @@
+
+void __init_riscv_feature_bits ()
+{
+  if (__init)
+return;
+
+#ifdef __linux
+  __init_riscv_features_bits_linux ();
+#else
+  /* Unsupported, just initlizaed that into all zeros.  */
+  __riscv_feature_bits.length = 0


I don't know enough about this to be able to comment on the patch 
itself. There's just a missing semicolon here which slipped its way into 
the v3 patch which would cause errors when trying to build on non-linux 
targets.


../../../../../../gcc/libgcc/config/riscv/feature_bits.c:307:34: error: 
expected ';' before '__riscv_vendor_feature_bits'

  307 |   __riscv_feature_bits.length = 0
  |  ^
  |  ;
  308 |   __riscv_vendor_feature_bits.length = 0;
  |   ~~~
make[5]: *** [../../../../../../gcc/libgcc/static-object.mk:17: 
feature_bits.o] Error 1




+  __riscv_vendor_feature_bits.length = 0;
+  __riscv_vendor_feature_bits.vendorID = 0;
+#endif
+
+  __init = 1;
+}


Edwin

Re: [Committed] RISC-V: Fix testcase missing arch attribute

[Edwin Lu]

Committed! Thanks!

Edwin

On 7/17/2024 1:14 AM, Kito Cheng wrote:

LGTM :)

On Wed, Jul 17, 2024 at 9:15 AM Edwin Lu  wrote:

The C + F extentions implies the zcf extension on rv32. Add missing zcf
extension for the rv32 target.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/target-attr-16.c: Update expected assembly

Signed-off-by: Edwin Lu 
---
  gcc/testsuite/gcc.target/riscv/target-attr-16.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/target-attr-16.c 
b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
index 1c7badccdee..c6b626d0c6c 100644
--- a/gcc/testsuite/gcc.target/riscv/target-attr-16.c
+++ b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
@@ -24,5 +24,5 @@ void bar (void)
  {
  }

-/* { dg-final { scan-assembler-times ".option arch, 
rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
 4 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times ".option arch, 
rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zcf1p0_zba1p0_zbb1p0"
 4 { target { rv32 } } } } */
  /* { dg-final { scan-assembler-times ".option arch, 
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
 4 { target { rv64 } } } } */
--
2.34.1

[PATCH] RISC-V: Fix testcase missing arch attribute

[Edwin Lu]

The C + F extentions implies the zcf extension on rv32. Add missing zcf
extension for the rv32 target.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/target-attr-16.c: Update expected assembly

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.target/riscv/target-attr-16.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/target-attr-16.c 
b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
index 1c7badccdee..c6b626d0c6c 100644
--- a/gcc/testsuite/gcc.target/riscv/target-attr-16.c
+++ b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
@@ -24,5 +24,5 @@ void bar (void)
 {
 }
 
-/* { dg-final { scan-assembler-times ".option arch, 
rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
 4 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times ".option arch, 
rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zcf1p0_zba1p0_zbb1p0"
 4 { target { rv32 } } } } */
 /* { dg-final { scan-assembler-times ".option arch, 
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
 4 { target { rv64 } } } } */
-- 
2.34.1

Re: [Committed] RISC-V: Fix testcase for vector .SAT_SUB in zip benchmark

[Edwin Lu]

Committed!

Edwin

On 7/12/2024 3:40 PM, Jeff Law wrote:



On 7/12/24 12:37 PM, Edwin Lu wrote:

The following testcase was not properly testing anything due to an
uninitialized variable. As a result, the loop was not iterating through
the testing data, but instead on undefined values which could cause an
unexpected abort.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h:
initialize variable

OK.  Thanks for chasing this down.

jeff

[PATCH] RISC-V: Fix testcase for vector .SAT_SUB in zip benchmark

[Edwin Lu]

The following testcase was not properly testing anything due to an
uninitialized variable. As a result, the loop was not iterating through
the testing data, but instead on undefined values which could cause an
unexpected abort.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h:
initialize variable

Signed-off-by: Edwin Lu 
---
 .../gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h
index d238c6392de..309d63377d5 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h
@@ -9,6 +9,7 @@ main ()
 
   for (i = 0; i < sizeof (DATA) / sizeof (DATA[0]); i++)
 {
+  d = DATA[i];
   RUN_BINARY_VX (&d.x[N], d.b, N);
 
   for (k = 0; k < N; k++)
-- 
2.34.1

Re: [PATCH v1] RISC-V: Add testcases for vector .SAT_SUB in zip benchmark

[Edwin Lu]

Hi Pan,

This patch appears to be tripping up our postcommit for building linux 
with vector https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1325.


FAIL: gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub_zip-run.c 
execution test


Looking at the logs, the test fails due to the __builtin_abort call when
d.x[k] != d.expect[k].


diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h
new file mode 100644
index 000..d238c6392de
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vx.h
@@ -0,0 +1,22 @@
+#ifndef HAVE_DEFINED_VEC_SAT_BINARY_VX_H
+#define HAVE_DEFINED_VEC_SAT_BINARY_VX_H
+
+int
+main ()
+{
+  unsigned i, k;
+  T d;
+
+  for (i = 0; i < sizeof (DATA) / sizeof (DATA[0]); i++)
+{
+  RUN_BINARY_VX (&d.x[N], d.b, N);
+
+  for (k = 0; k < N; k++)
+   if (d.x[k] != d.expect[k])
+ __builtin_abort ();
+}
+
+  return 0;
+}
+
+#endif


I think you forgot to initialize d = data[i] in the loop?

Edwin

Re: [Committed V2 1/2] RISC-V: Add support for B standard extension

[Edwin Lu]

Committed!

Edwin

On 7/9/2024 12:07 PM, Jeff Law wrote:



On 7/9/24 11:44 AM, Edwin Lu wrote:
This patch adds support for recognizing the B standard extension to 
be the
collection of Zba, Zbb, Zbs extensions for consistency and 
conciseness across

toolchains

* https://github.com/riscv/riscv-b/tags

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Add imply rules for B
  extension
* config/riscv/arch-canonicalize: Ditto
Both of these patches are fine.  And a good reminder, I'll change my 
most recently submitted patch to use "gcb" since it fits the pattern 
of zba_zbb_zbs.


jeff

[PATCH V2 2/2] RISC-V: Update testsuite to use b

[Edwin Lu]

Update all instances of zba_zbb_zbs in the testsuite to use b instead

I doubt anything would happen but just re-running it through ci
to make sure changes in first patch don't break anything here.

gcc/testsuite/ChangeLog:

* g++.target/riscv/redundant-bitmap-1.C: Use gcb instead of
  zba_zbb_zbs
* g++.target/riscv/redundant-bitmap-2.C: Ditto
* g++.target/riscv/redundant-bitmap-3.C: Ditto
* g++.target/riscv/redundant-bitmap-4.C: Ditto
* gcc.target/riscv/shift-add-1.c: Ditto
* gcc.target/riscv/shift-add-2.c: Ditto
* gcc.target/riscv/synthesis-1.c: Ditto
* gcc.target/riscv/synthesis-2.c: Ditto
* gcc.target/riscv/synthesis-3.c: Ditto
* gcc.target/riscv/synthesis-4.c: Ditto
* gcc.target/riscv/synthesis-5.c: Ditto
* gcc.target/riscv/synthesis-6.c: Ditto
* gcc.target/riscv/synthesis-7.c: Ditto
* gcc.target/riscv/synthesis-8.c: Ditto
* gcc.target/riscv/zba_zbs_and-1.c: Ditto
* gcc.target/riscv/zbs-zext-3.c: Ditto
* lib/target-supports.exp: Add b to riscv_get_arch

Signed-off-by: Edwin Lu 
---
V2: no change
---
 gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C | 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-3.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-4.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-5.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-6.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-7.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-8.c| 2 +-
 gcc/testsuite/gcc.target/riscv/zba_zbs_and-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/zbs-zext-3.c | 4 ++--
 gcc/testsuite/lib/target-supports.exp   | 2 +-
 17 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
index 37066f10eea..62bb2ab7b67 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
index 86acaba298f..52204daecd1 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
index 16bd7c1785e..6745220f2f4 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
index f664ee01a01..5e351fe457e 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/gcc.target/riscv/shift-add-1.c 
b/gcc/testsuite/gcc.target/riscv/shift-add-1.c
index d98875c3271..db84a51a222 100644
--- a/gcc/testsuite/gcc.target/riscv/shift-add-1.c
+++ b/gcc/testsuite/gcc.target/riscv/shift-add-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-march=rv64gcb -mabi=lp64" } */
 /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
 
 int composeFromSurrogate(const unsigned short high) {
diff --git a/gcc/testsuite/gcc.target/riscv/shift-add-2.c 
b/gcc/testsuite/gcc.target/riscv/shift-

[PATCH V2 1/2] RISC-V: Add support for B standard extension

[Edwin Lu]

This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains

* https://github.com/riscv/riscv-b/tags

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Add imply rules for B
  extension
* config/riscv/arch-canonicalize: Ditto

Signed-off-by: Edwin Lu 
---
V2: Add b to riscv_combine_info
---
 gcc/common/config/riscv/riscv-common.cc | 7 +++
 gcc/config/riscv/arch-canonicalize  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index dab2e767965..b0a16f5bd30 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -84,6 +84,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
 
   {"zabha", "zaamo"},
 
+  {"b", "zba"},
+  {"b", "zbb"},
+  {"b", "zbs"},
+
   {"zdinx", "zfinx"},
   {"zfinx", "zicsr"},
   {"zdinx", "zicsr"},
@@ -245,6 +249,8 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"c", ISA_SPEC_CLASS_20190608, 2, 0},
   {"c", ISA_SPEC_CLASS_2P2,  2, 0},
 
+  {"b",   ISA_SPEC_CLASS_NONE, 1, 0},
+
   {"h",   ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"v",   ISA_SPEC_CLASS_NONE, 1, 0},
@@ -405,6 +411,7 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
 static const struct riscv_ext_version riscv_combine_info[] =
 {
   {"a", ISA_SPEC_CLASS_20191213, 2, 1},
+  {"b",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zk",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zkn",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zks",  ISA_SPEC_CLASS_NONE, 1, 0},
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index 35a7fe4455a..2ea514dd986 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -45,6 +45,7 @@ IMPLIED_EXT = {
   "zabha" : ["zaamo"],
 
   "f" : ["zicsr"],
+  "b" : ["zba", "zbb", "zbs"],
   "zdinx" : ["zfinx", "zicsr"],
   "zfinx" : ["zicsr"],
   "zhinx" : ["zhinxmin", "zfinx", "zicsr"],
-- 
2.34.1

[PATCH V2 0/2] Add support for B extention

[Edwin Lu]

Support for recognizing B as the collection of zba, zbb, zbs extensions

https://github.com/riscv/riscv-b/tags

V2: add b to riscv_combine_info

Edwin Lu (2):
  RISC-V: Add support for B standard extension
  RISC-V: Update testsuite to use b

 gcc/common/config/riscv/riscv-common.cc | 7 +++
 gcc/config/riscv/arch-canonicalize  | 1 +
 gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C | 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-3.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-4.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-5.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-6.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-7.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-8.c| 2 +-
 gcc/testsuite/gcc.target/riscv/zba_zbs_and-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/zbs-zext-3.c | 4 ++--
 gcc/testsuite/lib/target-supports.exp   | 2 +-
 19 files changed, 26 insertions(+), 18 deletions(-)

-- 
2.34.1

[PATCH 2/2] RISC-V: Update testsuite to use b

[Edwin Lu]

Update all instances of zba_zbb_zbs in the testsuite to use b instead.

 gcc/testsuite/ChangeLog:

* g++.target/riscv/redundant-bitmap-1.C: Use gcb instead of
  zba_zbb_zbs
* g++.target/riscv/redundant-bitmap-2.C: Ditto
* g++.target/riscv/redundant-bitmap-3.C: Ditto
* g++.target/riscv/redundant-bitmap-4.C: Ditto
* gcc.target/riscv/shift-add-1.c: Ditto
* gcc.target/riscv/shift-add-2.c: Ditto
* gcc.target/riscv/synthesis-1.c: Ditto
* gcc.target/riscv/synthesis-2.c: Ditto
* gcc.target/riscv/synthesis-3.c: Ditto
* gcc.target/riscv/synthesis-4.c: Ditto
* gcc.target/riscv/synthesis-5.c: Ditto
* gcc.target/riscv/synthesis-6.c: Ditto
* gcc.target/riscv/synthesis-7.c: Ditto
* gcc.target/riscv/synthesis-8.c: Ditto
* gcc.target/riscv/zba_zbs_and-1.c: Ditto
* gcc.target/riscv/zbs-zext-3.c: Ditto
* lib/target-supports.exp: Add b to riscv_get_arch

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C | 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-3.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-4.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-5.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-6.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-7.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-8.c| 2 +-
 gcc/testsuite/gcc.target/riscv/zba_zbs_and-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/zbs-zext-3.c | 4 ++--
 gcc/testsuite/lib/target-supports.exp   | 2 +-
 17 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
index 37066f10eea..62bb2ab7b67 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
index 86acaba298f..52204daecd1 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
index 16bd7c1785e..6745220f2f4 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C 
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
index f664ee01a01..5e351fe457e 100644
--- a/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-O2 -march=rv64gcb -mabi=lp64" } */
 
 void setBit(char &a, int b) {
 char c = 0x1UL << b;
diff --git a/gcc/testsuite/gcc.target/riscv/shift-add-1.c 
b/gcc/testsuite/gcc.target/riscv/shift-add-1.c
index d98875c3271..db84a51a222 100644
--- a/gcc/testsuite/gcc.target/riscv/shift-add-1.c
+++ b/gcc/testsuite/gcc.target/riscv/shift-add-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gc_zba_zbb_zbs -mabi=lp64" } */
+/* { dg-options "-march=rv64gcb -mabi=lp64" } */
 /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
 
 int composeFromSurrogate(const unsigned short high) {
diff --git a/gcc/testsuite/gcc.target/riscv/shift-add-2.c 
b/gcc/testsuite/gcc.target/riscv/shift-add-2.c
index 87439858e59..ed95ced5b85 100644
--- a/gcc/testsuite/gcc.target/riscv/shift-add-2.c
+++ b/gcc/testsuite/gcc.target/riscv/shift-add-2.

[PATCH 1/2] RISC-V: Add support for B standard extension

[Edwin Lu]

This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains

* https://github.com/riscv/riscv-b/tags

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Add imply rules for B
  extension
* config/riscv/arch-canonicalize: Ditto

Signed-off-by: Edwin Lu 
---
 gcc/common/config/riscv/riscv-common.cc | 6 ++
 gcc/config/riscv/arch-canonicalize  | 1 +
 2 files changed, 7 insertions(+)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index b9bda3e110a..df7f33b7486 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -84,6 +84,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
 
   {"zabha", "zaamo"},
 
+  {"b", "zba"},
+  {"b", "zbb"},
+  {"b", "zbs"},
+
   {"zdinx", "zfinx"},
   {"zfinx", "zicsr"},
   {"zdinx", "zicsr"},
@@ -245,6 +249,8 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"c", ISA_SPEC_CLASS_20190608, 2, 0},
   {"c", ISA_SPEC_CLASS_2P2,  2, 0},
 
+  {"b",   ISA_SPEC_CLASS_NONE, 1, 0},
+
   {"h",   ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"v",   ISA_SPEC_CLASS_NONE, 1, 0},
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index 35a7fe4455a..2ea514dd986 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -45,6 +45,7 @@ IMPLIED_EXT = {
   "zabha" : ["zaamo"],
 
   "f" : ["zicsr"],
+  "b" : ["zba", "zbb", "zbs"],
   "zdinx" : ["zfinx", "zicsr"],
   "zfinx" : ["zicsr"],
   "zhinx" : ["zhinxmin", "zfinx", "zicsr"],
-- 
2.34.1

[PATCH 0/2] Add support for B extention

[Edwin Lu]

Support for recognizing B as the collection of zba, zbb, zbs extensions

https://github.com/riscv/riscv-b/tags

Edwin Lu (2):
  RISC-V: Add support for B standard extension
  RISC-V: Update testsuite to use b

  gcc/testsuite/ChangeLog:

 gcc/common/config/riscv/riscv-common.cc | 6 ++
 gcc/config/riscv/arch-canonicalize  | 1 +
 gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-3.C | 2 +-
 gcc/testsuite/g++.target/riscv/redundant-bitmap-4.C | 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/shift-add-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-3.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-4.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-5.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-6.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-7.c| 2 +-
 gcc/testsuite/gcc.target/riscv/synthesis-8.c| 2 +-
 gcc/testsuite/gcc.target/riscv/zba_zbs_and-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/zbs-zext-3.c | 4 ++--
 gcc/testsuite/lib/target-supports.exp   | 2 +-
 19 files changed, 25 insertions(+), 18 deletions(-)

-- 
2.34.1

Re: [Committed V3 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

[Edwin Lu]

Thanks!

Edwin

On 6/17/2024 5:33 PM, Jeff Law wrote:



On 6/17/24 12:33 PM, Edwin Lu wrote:

When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode = Pmode to correctly satisfy the
maybe_legitimize_operand check, however, there may be problems when
working in 32 bit environments.

Make the assert unconditional and replace it with an internal error for
more descriptive logging

gcc/ChangeLog:

* config/riscv/riscv-v.cc: Move assert out of conditional block

OK.

Jeff

Re: [Committed V3 1/2] RISC-V: Fix vwsll combine on rv32 targets

[Edwin Lu]

Committed. Thanks!

Edwin

On 6/17/2024 5:31 PM, Jeff Law wrote:



On 6/17/24 12:33 PM, Edwin Lu wrote:

On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded 
insn

operand's mode (Pmode == SI). Ensure that mode of the operands match

Tested on rv32/64 gcv newlib. Letting CI perform additional testing

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Fix mode mismatch

OK
jeff

[PATCH V3 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

[Edwin Lu]

When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode = Pmode to correctly satisfy the
maybe_legitimize_operand check, however, there may be problems when
working in 32 bit environments.

Make the assert unconditional and replace it with an internal error for
more descriptive logging

gcc/ChangeLog:

* config/riscv/riscv-v.cc: Move assert out of conditional block

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2: change assert to internal error

V3: No change
---
 gcc/config/riscv/riscv-v.cc | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 8911f5783c8..5306711c1b7 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,7 @@
 #include "rtx-vector-builder.h"
 #include "targhooks.h"
 #include "predict.h"
+#include "errors.h"
 
 using namespace riscv_vector;
 
@@ -290,11 +291,17 @@ public:
   always Pmode.  */
if (mode == VOIDmode)
  mode = Pmode;
-   else
- /* Early assertion ensures same mode since maybe_legitimize_operand
-will check this.  */
- gcc_assert (GET_MODE (ops[opno]) == VOIDmode
- || GET_MODE (ops[opno]) == mode);
+
+   /* Early assertion ensures same mode since maybe_legitimize_operand
+  will check this.  */
+   machine_mode required_mode = GET_MODE (ops[opno]);
+   if (required_mode != VOIDmode && required_mode != mode)
+ internal_error ("expected mode %s for operand %d of "
+ "insn %s but got mode %s.\n",
+ GET_MODE_NAME (mode),
+ opno,
+ insn_data[(int) icode].name,
+ GET_MODE_NAME (required_mode));
 
add_input_operand (ops[opno], mode);
   }
@@ -346,7 +353,13 @@ public:
 else if (m_insn_flags & VXRM_RDN_P)
   add_rounding_mode_operand (VXRM_RDN);
 
-gcc_assert (insn_data[(int) icode].n_operands == m_opno);
+
+if (insn_data[(int) icode].n_operands != m_opno)
+  internal_error ("invalid number of operands for insn %s, "
+ "expected %d but got %d.\n",
+ insn_data[(int) icode].name,
+ insn_data[(int) icode].n_operands, m_opno);
+
 expand (icode, any_mem_p);
   }
 
-- 
2.34.1

[PATCH V3 1/2] RISC-V: Fix vwsll combine on rv32 targets

[Edwin Lu]

On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match

Tested on rv32/64 gcv newlib. Letting CI perform additional testing

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Fix mode mismatch

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2: Remove subreg check

V3: Update _trunc_scalar splitter as well
---
 gcc/config/riscv/autovec-opt.md | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 6a2eabbd854..d7a3cfd4602 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -1517,8 +1517,7 @@ (define_insn_and_split "*vwsll_zext1_scalar_"
   "&& 1"
   [(const_int 0)]
   {
-if (GET_CODE (operands[2]) == SUBREG)
-  operands[2] = SUBREG_REG (operands[2]);
+operands[2] = gen_lowpart (Pmode, operands[2]);
 insn_code icode = code_for_pred_vwsll_scalar (mode);
 riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, operands);
 DONE;
@@ -1584,8 +1583,7 @@ (define_insn_and_split "*vwsll_zext1_trunc_scalar_"
   "&& 1"
   [(const_int 0)]
   {
-if (GET_CODE (operands[2]) == SUBREG)
-  operands[2] = SUBREG_REG (operands[2]);
+operands[2] = gen_lowpart (Pmode, operands[2]);
 insn_code icode = code_for_pred_vwsll_scalar (mode);
 riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, operands);
 DONE;
-- 
2.34.1

[PATCH V3 0/2] Fix ICE with vwsll combine on 32bit targets

[Edwin Lu]

The following testcases have been failing on rv32 targets since 
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler
error: in maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess
errors)

Fix the bug and also robustify our emit_insn by making an assertion
check unconditional

I'm not sure if this ICE warrants its own separate testcase since it is
already being tested. I do have a minimal testcase on hand if we would
like to add one.

V2: Remove subreg condition and change assert to internal error

V3: Update the _trunc_scalar splitter as well

Edwin Lu (2):
  RISC-V: Fix vwsll combine on rv32 targets
  RISC-V: Move mode assertion out of conditional branch in emit_insn

 gcc/config/riscv/autovec-opt.md |  6 ++
 gcc/config/riscv/riscv-v.cc | 25 +++--
 2 files changed, 21 insertions(+), 10 deletions(-)

-- 
2.34.1

[PATCH V2 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

[Edwin Lu]

When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode = Pmode to correctly satisfy the
maybe_legitimize_operand check, however, there may be problems when
working in 32 bit environments.

Make the assert unconditional and replace it with an internal error for
more descriptive logging

gcc/ChangeLog:

* config/riscv/riscv-v.cc: Move assert out of conditional block

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2: change assert to internal error
---
 gcc/config/riscv/riscv-v.cc | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 8911f5783c8..3f8214b74d5 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,7 @@
 #include "rtx-vector-builder.h"
 #include "targhooks.h"
 #include "predict.h"
+#include "errors.h"
 
 using namespace riscv_vector;
 
@@ -290,11 +291,17 @@ public:
   always Pmode.  */
if (mode == VOIDmode)
  mode = Pmode;
-   else
- /* Early assertion ensures same mode since maybe_legitimize_operand
-will check this.  */
- gcc_assert (GET_MODE (ops[opno]) == VOIDmode
- || GET_MODE (ops[opno]) == mode);
+
+   /* Early assertion ensures same mode since maybe_legitimize_operand
+  will check this.  */
+machine_mode required_mode = GET_MODE (ops[opno]);
+if (required_mode != VOIDmode && required_mode != mode)
+ internal_error ("expected mode %s for operand %d of "
+ "insn %s but got mode %s.\n",
+ GET_MODE_NAME (mode),
+ opno,
+ insn_data[(int) icode].name,
+ GET_MODE_NAME (required_mode));
 
add_input_operand (ops[opno], mode);
   }
@@ -346,7 +353,13 @@ public:
 else if (m_insn_flags & VXRM_RDN_P)
   add_rounding_mode_operand (VXRM_RDN);
 
-gcc_assert (insn_data[(int) icode].n_operands == m_opno);
+
+if (insn_data[(int) icode].n_operands != m_opno)
+  internal_error ("invalid number of operands for insn %s, "
+ "expected %d but got %d.\n",
+ insn_data[(int) icode].name,
+ insn_data[(int) icode].n_operands, m_opno);
+
 expand (icode, any_mem_p);
   }
 
-- 
2.34.1

[PATCH V2 1/2] RISC-V: Fix vwsll combine on rv32 targets

[Edwin Lu]

On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Fix mode mismatch

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2: Remove subreg check
---
 gcc/config/riscv/autovec-opt.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 6a2eabbd854..29916adb62b 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -1517,8 +1517,7 @@ (define_insn_and_split "*vwsll_zext1_scalar_"
   "&& 1"
   [(const_int 0)]
   {
-if (GET_CODE (operands[2]) == SUBREG)
-  operands[2] = SUBREG_REG (operands[2]);
+operands[2] = gen_lowpart (Pmode, operands[2]);
 insn_code icode = code_for_pred_vwsll_scalar (mode);
 riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, operands);
 DONE;
-- 
2.34.1

[PATCH V2 0/2] Fix ICE with vwsll combine on 32bit targets

[Edwin Lu]

The following testcases have been failing on rv32 targets since 
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler
error: in maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess
errors)

Fix the bug and also robustify our emit_insn by making an assertion
check unconditional

I'm not sure if this ICE warrants its own separate testcase since it is
already being tested. I do have a minimal testcase on hand if we would
like to add one.

V2: Remove subreg condition and change assert to internal error

Edwin Lu (2):
  RISC-V: Fix vwsll combine on rv32 targets
  RISC-V: Move mode assertion out of conditional branch in emit_insn

 gcc/config/riscv/autovec-opt.md |  3 +--
 gcc/config/riscv/riscv-v.cc | 25 +++--
 2 files changed, 20 insertions(+), 8 deletions(-)

-- 
2.34.1

Re: [PATCH 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

[Edwin Lu]

On 6/12/2024 12:39 AM, Robin Dapp wrote:

Hi Edwin,

this LGTM but I just remembered I intended to turn the assert
into a more descriptive error.

The attached patch has been sitting on my local branch for a
while.  Maybe we should rather fold yours into it?


That's fine with me! Having more descriptive errors would have helped a 
lot during the triaging/debugging step :)


Edwin


Regards
  Robin

 From d164403ef577917f905c1690f2199fab330f05e2 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Fri, 31 May 2024 14:51:17 +0200
Subject: [PATCH] RISC-V: Use descriptive errors instead of asserts.

In emit_insn we forestall possible ICEs in maybe_legitimize_operand by
asserting.  This patch replaces the assertions by more descriptive
internal errors.

gcc/ChangeLog:

* config/riscv/riscv-v.cc: Replace asserts by internal errors.
---
  gcc/config/riscv/riscv-v.cc | 27 ++-
  1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 8911f5783c8..810203b8ba5 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,7 @@
  #include "rtx-vector-builder.h"
  #include "targhooks.h"
  #include "predict.h"
+#include "errors.h"
  
  using namespace riscv_vector;
  
@@ -291,10 +292,20 @@ public:

if (mode == VOIDmode)
  mode = Pmode;
else
- /* Early assertion ensures same mode since maybe_legitimize_operand
-will check this.  */
- gcc_assert (GET_MODE (ops[opno]) == VOIDmode
- || GET_MODE (ops[opno]) == mode);
+ {
+   /* Early assertion ensures same mode since maybe_legitimize_operand
+  will check this.  */
+   machine_mode required_mode = GET_MODE (ops[opno]);
+   if (required_mode != VOIDmode && required_mode != mode)
+ {
+   internal_error ("expected mode %s for operand %d of "
+   "insn %s but got mode %s.\n",
+   GET_MODE_NAME (mode),
+   opno,
+   insn_data[(int) icode].name,
+   GET_MODE_NAME (required_mode));
+ }
+ }
  
  	add_input_operand (ops[opno], mode);

}
@@ -346,7 +357,13 @@ public:
  else if (m_insn_flags & VXRM_RDN_P)
add_rounding_mode_operand (VXRM_RDN);
  
-gcc_assert (insn_data[(int) icode].n_operands == m_opno);

+
+if (insn_data[(int) icode].n_operands != m_opno)
+  internal_error ("invalid number of operands for insn %s, "
+ "expected %d but got %d.\n",
+ insn_data[(int) icode].name,
+ insn_data[(int) icode].n_operands, m_opno);
+
  expand (icode, any_mem_p);
}
  

Re: [PATCH 1/2] RISC-V: Fix vwsll combine on rv32 targets

[Edwin Lu]

Hi Robin,

I did a test run without the subreg condition and it also appears to 
work when running on rv32gcv and rv64gcv newlib. Would it be better to 
remove the subreg?


Edwin

On 6/12/2024 12:42 AM, Robin Dapp wrote:

Hi Edwin,

this is OK but did you check if we can get rid of the subreg
condition now that we have gen_lowpart?

Regards
  Robin

[PATCH 2/2] RISC-V: Move mode assertion out of conditional branch in emit_insn

[Edwin Lu]

When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode = Pmode to correctly satisfy the
maybe_legitimize_operand check, however, there may be problems when
working in 32 bit environments.

Make the assert unconditional

gcc/ChangeLog:

* config/riscv/riscv-v.cc: Move assert out of conditional block

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv-v.cc | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 8911f5783c8..6387727833f 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -290,11 +290,11 @@ public:
   always Pmode.  */
if (mode == VOIDmode)
  mode = Pmode;
-   else
- /* Early assertion ensures same mode since maybe_legitimize_operand
-will check this.  */
- gcc_assert (GET_MODE (ops[opno]) == VOIDmode
- || GET_MODE (ops[opno]) == mode);
+
+   /* Early assertion ensures same mode since maybe_legitimize_operand
+  will check this.  */
+   gcc_assert (GET_MODE (ops[opno]) == VOIDmode
+ || GET_MODE (ops[opno]) == mode);
 
add_input_operand (ops[opno], mode);
   }
-- 
2.34.1

[PATCH 1/2] RISC-V: Fix vwsll combine on rv32 targets

[Edwin Lu]

On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Fix mode mismatch

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
 gcc/config/riscv/autovec-opt.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 6a2eabbd854..b9e5ccfef25 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -1519,6 +1519,7 @@ (define_insn_and_split "*vwsll_zext1_scalar_"
   {
 if (GET_CODE (operands[2]) == SUBREG)
   operands[2] = SUBREG_REG (operands[2]);
+operands[2] = gen_lowpart (Pmode, operands[2]);
 insn_code icode = code_for_pred_vwsll_scalar (mode);
 riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, operands);
 DONE;
-- 
2.34.1

[PATCH 0/2] Fix ICE with vwsll combine on 32bit targets

[Edwin Lu]

The following testcases have been failing on rv32 targets since 
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler error: in 
maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess errors)

Fix the bug and also robustify our emit_insn by making an assertion
check unconditional

I'm not sure if this ICE warrants its own separate testcase since it is
already being tested. I do have a minimal testcase on hand if we would
like to add one.

Edwin Lu (2):
  RISC-V: Fix vwsll combine on rv32 targets
  RISC-V: Move mode assertion out of conditional branch in emit_insn

 gcc/config/riscv/autovec-opt.md |  1 +
 gcc/config/riscv/riscv-v.cc | 10 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.34.1

[PATCH] RISC-V: Fix testcases renamed test flag options

[Edwin Lu]

Some testcases still had --param=riscv-autovec-preference=_,
update to use -mrvv-vector-bits=_. Also add missing period
in riscv.opt which caused a compiler driver error.

gcc/ChangeLog:

* config/riscv/riscv.opt: Add missing period

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/no-segment.c: Update dejagnu flags
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-2.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-3.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-4.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-5.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-6.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-7.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-1.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-2.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-3.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-4.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-5.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-6.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-7.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-1.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-10.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-11.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-12.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-13.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-14.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-15.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-16.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-17.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-18.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-2.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-3.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-4.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-5.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-6.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-7.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-8.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-9.c:
  Ditto
---
 gcc/config/riscv/riscv.opt| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-2.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-3.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-4.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-5.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-6.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-7.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-1.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-2.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-3.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-4.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-5.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-6.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-7.c  | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-1.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-10.c   | 4 ++--
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-11.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-12.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-13.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-14.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-15.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-16.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-17.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-18.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-2.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_n

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Edwin Lu]

On 4/11/2024 5:45 AM, Li, Pan2 wrote:

Thanks for reporting this. Just take a look from my test log that 930623-1.c is 
all pass.

Thus I bet this difference comes from the build option --with-arch=rv32imac but 
my test script take rv64gcv.


I've built the git revision f3fdcf4a37a with
../gcc-trunk/configure --target=riscv-unknown-elf 
--prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
--disable-multilib --with-arch=rv32imac --with-abi=ilp32



I am a bit surprised since the target is not supposed to support floating point
or vector instructions AFAIK.


Because you specify rv32imac, with doesn't include f/d/v extension, aka 
single/double floating point and vector extension. Thus, related functionality 
are disabled.


The issue does not happen with gcc-trunk from yesterday.


Ack, will look into it.

Pan
 

Hi Pan,

Our postcommit-ci found that it breaks for non-vector targets on rv32/64 
newlib/linux https://github.com/patrick-rivos/gcc-postcommit-ci/issues/757.


The patchwork precommit-ci also appeared to have flagged it 
https://github.com/ewlu/gcc-precommit-ci/issues/1417#issuecomment-2048846532


Edwin

Re: [gcc-13 backport Committed] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

[Edwin Lu]

On 4/4/2024 7:40 AM, Palmer Dabbelt wrote:

On Thu, 04 Apr 2024 07:37:56 PDT (-0700), ja...@redhat.com wrote:

On Thu, Apr 04, 2024 at 07:28:40AM -0700, Palmer Dabbelt wrote:

I'm not sure if we need release maintainer approval,


For cherry-picking one's own non-risky bugfixes for regression or
documentation bugs from trunk to release branches no special approval
is needed, or maintainer of the corresponding code can approve that,
release manager approval is only needed when a branch is frozen before a
release.


Ya, I'm just never sure when the branch is frozen...


all I can find is the
13.2.1 status report saying 13.3 is expected in the spring
.  My 
allergies
certainly indicate it's spring, but that's kind of a wide time 
window...


Maybe Jakub knows?


Most likely some short time after 14.1 is released, so that one can 
still
cherry-pick whatever was fixed on the 14 branch and there is time for 
those

cherry-picks and testing.
https://gcc.gnu.org/releases.html#timeline gives some hints...


OK, so sounds like it's not frozen now and Edwin's OK to commit this 
on the 13 branch.  Thanks.




Jakub


Thanks for the clarifications! Committed!

Edwin

[gcc-13 backport PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

[Edwin Lu]

We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail

Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
explains

Tested on linux rv64gcv.

gcc/ChangeLog:

PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL

(cherry picked from commit 60586710b0646efdbbd77a7f53b93fb5edb87a61)
---
 gcc/config/riscv/riscv.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 01eebc83cc5..cefd3b7b2b2 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3961,7 +3961,8 @@ riscv_setup_incoming_varargs (cumulative_args_t cum,
  argument.  Advance a local copy of CUM past the last "real" named
  argument, to find out how many registers are left over.  */
   local_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 riscv_function_arg_advance (pack_cumulative_args (&local_cum), arg);
 
   /* Found out how many registers we need to save.  */
-- 
2.34.1

Re: [Committed] RISC-V: Update test expectancies with recent scheduler change

[Edwin Lu]

On 3/18/2024 8:14 PM, Jeff Law wrote:



On 3/12/24 3:56 PM, Edwin Lu wrote:

Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Disable 
scheduling

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: Ditto
* gcc.target/riscv/rvv/base/vcreate.c: Disable scheduling and update
test expectancies
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-30.c: Disable 
scheduling

* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-31.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: Update test
expectancies
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: Ditto
As we discussed last week.  This should go forward as it brings a 
better degree of stability to these tests.  Looking forward to cleaner 
testresults as my tester has been complaining about this stuff for a 
month now :(



And a note for the future.  Let's take this one:

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c

index 4c6e88e7eed..46d3b5e98d4 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c
@@ -60,11 +60,11 @@ test_vbool1_then_vbool64(int8_t * restrict in, 
int8_t * restrict out) {

  }
    /* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m8,\s*ta,\s*ma} 6 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m4,\s*ta,\s*ma} 1 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m2,\s*ta,\s*ma} 1 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m1,\s*ta,\s*ma} 1 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf2,\s*ta,\s*ma} 1 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf4,\s*ta,\s*ma} 1 } } */
-/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf8,\s*ta,\s*ma} 1 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m4,\s*ta,\s*ma} 2 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m2,\s*ta,\s*ma} 2 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m1,\s*ta,\s*ma} 2 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf2,\s*ta,\s*ma} 2 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf4,\s*ta,\s*ma} 2 } } */
+/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf8,\s*ta,\s*ma} 2 } } */
  /* { dg-final { scan-assembler-times 
{vlm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */
  /* { dg-final { scan-assembler-times 
{vsm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */


This shows an example of how uarch information such as instruction 
latency will affect vset counts.  If someone wanted to test that 
pr108185-1 can drive the counts of each of those vsets to since 
instance, they can certainly #include pr108185-1 and provide suitable 
dg directives to set a specific uarch tuning and appropriate dg-final 
directives to ensure just a single instance of each vset occurs.


I'm not expecting you do to this.  Just making a note if someone 
really wants to use those tests to verify a specific set of vsets on a 
particular uarch.



Jeff


Committed!

Edwin

Re: [Committed] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

[Edwin Lu]

On 3/18/2024 8:07 PM, Jeff Law wrote:



On 3/18/24 12:54 PM, Edwin Lu wrote:
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named 
arguments and
there is nothing to advance, but that is not the case for (...) 
functions

returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail

Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
explains

Tested on linux rv64gcv.

gcc/ChangeLog:

PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL

OK.  Thanks for taking care of this.

Jeff


Committed!

Edwin

[PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

[Edwin Lu]

We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail

Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
explains

Tested on linux rv64gcv.

gcc/ChangeLog:

PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL
---
 gcc/config/riscv/riscv.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 680c4a728e9..1f5dc33796b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5378,7 +5378,8 @@ riscv_setup_incoming_varargs (cumulative_args_t cum,
  argument.  Advance a local copy of CUM past the last "real" named
  argument, to find out how many registers are left over.  */
   local_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 riscv_function_arg_advance (pack_cumulative_args (&local_cum), arg);
 
   /* Found out how many registers we need to save.  */
-- 
2.34.1

[PATCH V2] RISC-V: Update test expectancies with recent scheduler change

[Edwin Lu]

Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Disable scheduling
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: Ditto
* gcc.target/riscv/rvv/base/vcreate.c: Disable scheduling and update
test expectancies
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-30.c: Disable scheduling
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-31.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: Update test
expectancies
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: Ditto

Signed-off-by: Edwin Lu 
---
V1: Change tests to scan for range of vsetvls instead of specific number

V2: Add -fno-schedule-insns and -fno-schedule-insns2 to testcases that
were missing them. Those that had disabled insn scheduling, update
testcases to match current outputs to pass tests
---
 .../vect/costmodel/riscv/rvv/dynamic-lmul4-6.c   |  1 +
 .../vect/costmodel/riscv/rvv/dynamic-lmul4-8.c   |  1 +
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-2.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-3.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-4.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-5.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-6.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-7.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/rvv/base/vcreate.c|  6 --
 .../gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-30.c |  1 +
 .../gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-31.c |  1 +
 .../riscv/rvv/vsetvl/vlmax_single_block-17.c | 12 ++--
 .../riscv/rvv/vsetvl/vlmax_single_block-18.c |  6 +++---
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-11.c |  2 +-
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-12.c |  2 +-
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-4.c  |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-5.c  |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-6.c  |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-7.c  |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-8.c  |  4 ++--
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-9.c  |  4 ++--
 23 files changed, 75 insertions(+), 69 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
index bd7ce23f6b8..b23acebc916 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv32gcv -mabi=ilp32 -O3 -ftree-vectorize --param 
riscv-autovec-lmul=dynamic -mrvv-vector-bits=scalable -fselective-scheduling 
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-schedule-insns -fno-schedule-insns2" } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
index 61619a0c879..ef719ee8445 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv32gcv -mabi=ilp32 -O3 -ftree-vectorize --param 
riscv-autovec-lmul=dynamic -mrvv-vector-bits=scalable -fselective-scheduling 
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-schedule-insns -fno-schedule-insns2" } */
 

[PATCH] middle-end: Fix dominator information with loop duplication PR114197

[Edwin Lu]

When adding the new_preheader to the cfg, only the new_preheader's dominator
information is updated. If one of the new basic block's children was part
of the original cfg and adding new_preheader to the cfg introduces another path
to that child, the child's dominator information will not be updated. This may
cause verify_dominator's assertion to fail.

Force recalculating dominators for all duplicated basic blocks and their
successors when updating new_preheader's dominator information.

PR 114197

gcc/ChangeLog:

* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Recalculate dominator info when adding new_preheader to cfg

gcc/testsuite/ChangeLog:

* gcc.dg/vect/pr114197.c: New test.

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.dg/vect/pr114197.c | 18 ++
 gcc/tree-vect-loop-manip.cc  | 17 -
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr114197.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr114197.c 
b/gcc/testsuite/gcc.dg/vect/pr114197.c
new file mode 100644
index 000..b1fb807729c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr114197.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O3" } */
+
+
+#pragma pack(push)
+struct a {
+  volatile signed b : 8;
+};
+#pragma pack(pop)
+int c;
+static struct a d = {5};
+void e() {
+f:
+  for (c = 8; c < 55; ++c)
+if (!d.b)
+  goto f;
+}
+
diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index f72da915103..0f3a489e78c 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -1840,7 +1840,22 @@ slpeel_tree_duplicate_loop_to_edge_cfg (class loop 
*loop, edge loop_exit,
}
 
   if (was_imm_dom || duplicate_outer_loop)
-   set_immediate_dominator (CDI_DOMINATORS, exit_dest, new_exit->src);
+   {
+ set_immediate_dominator (CDI_DOMINATORS, exit_dest, new_exit->src);
+
+ /* Update the dominator info for children of duplicated bbs.  */
+ for (unsigned i = 0; i < scalar_loop->num_nodes; i++)
+   {
+ basic_block dom_bb = NULL;
+ edge e;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e, ei, new_bbs[i]->succs)
+   {
+ dom_bb = recompute_dominator (CDI_DOMINATORS, e->dest);
+ set_immediate_dominator (CDI_DOMINATORS, e->dest, dom_bb);
+   }
+   }
+   }
 
   /* And remove the non-necessary forwarder again.  Keep the other
  one so we have a proper pre-header for the loop at the exit edge.  */
-- 
2.34.1

[PATCH] RISC-V: Update test expectancies with recent scheduler change

[Edwin Lu]

Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Bound testcase
assembly matching
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: Ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: Ditto
* gcc.target/riscv/rvv/base/vcreate.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-30.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-31.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: Ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: Ditto

Signed-off-by: Edwin Lu 
---
 .../costmodel/riscv/rvv/dynamic-lmul4-6.c |  3 +-
 .../costmodel/riscv/rvv/dynamic-lmul4-8.c |  3 +-
 .../gcc.target/riscv/rvv/base/pr108185-1.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-2.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-3.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-4.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-5.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-6.c| 25 +
 .../gcc.target/riscv/rvv/base/pr108185-7.c| 25 +
 .../gcc.target/riscv/rvv/base/vcreate.c   | 13 +++--
 .../riscv/rvv/vsetvl/vlmax_back_prop-30.c |  8 --
 .../riscv/rvv/vsetvl/vlmax_back_prop-31.c |  8 --
 .../riscv/rvv/vsetvl/vlmax_single_block-17.c  | 28 ++-
 .../riscv/rvv/vsetvl/vlmax_single_block-18.c  | 14 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c  |  9 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-11.c  |  3 +-
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-12.c  |  3 +-
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-4.c   |  8 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-5.c   |  8 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-6.c   |  8 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-7.c   |  8 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-8.c   |  8 --
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-9.c   |  8 --
 23 files changed, 238 insertions(+), 77 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
index d2766f5984c..1cb0888f9d8 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c
@@ -20,7 +20,8 @@ foo (uint8_t *restrict a, uint8_t *restrict b, int n)
 }
 
 /* { dg-final { scan-assembler {e8,m4} } } */
-/* { dg-final { scan-assembler-times {csrr} 1 } } */
+/* { dg-final { scan-assembler-bound {csrr} >= 1 } } */
+/* { dg-final { scan-assembler-bound {csrr} <= 3 } } */
 /* Since we don't support VLA SLP for LMUL = 8, dynamic LMUL cost model start 
from LMUL = 4.  */
 /* { dg-final { scan-tree-dump-not "Preferring smaller LMUL loop because it 
has unexpected spills" "vect" } } */
 /* { dg-final { scan-tree-dump-not "Maximum lmul = 8" "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
index 362c49f1411..0d644fc69bf 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c
@@ -29,7 +29,8 @@ foo (uint8_t *restrict a, uint8_t *restrict b, int n)
 }
 
 /* { dg-final { scan-assembler {e8,m4} } } */
-/* { dg-final { scan-assembler-times {csrr} 1 } } */
+/* { dg-final { scan-assembler-bound {csrr} >= 1 } } */
+/* { dg-final { scan-assembler-bound {csrr} <= 3 } } */
 /* Since we don't support VLA SLP for LMUL = 8, dynamic LMUL cost model start 
from LMUL = 4.  */
 /* { dg-final { scan-tree-dump-not "Preferring smaller LMUL loop because it 
h

Re: [Committed V4 4/5] RISC-V: Quick and simple fixes to testcases that break due to reordering

[Edwin Lu]

On 2/21/2024 10:57 AM, Robin Dapp wrote:



For calling-convention-*.c, LGTM but one nit about change log. Take
**Update** here may make others not easy to learn what you did about
the file. You can say similar to "Rearrange and adjust the
asm-checker times" or likewise. Of course, you can refine the
changelog when commit.

* gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: update




Yes, agreed,  changes LGTM but please refine the commit message
slightly.  The first letter should also be capitalized I believe.

The rest of the is already ACK'ed so I believe it's good to go now.
I didn't pay a lot of attention to the other commit messages.
In case they need refining you can do that still.



Thanks! I updated the changelogs and committed.

Edwin

Re: [Committed V2] RISC-V: Specify mtune and march for PR113742

[Edwin Lu]

Committed

Edwin

On 2/20/2024 5:36 PM, Kito Cheng wrote:

LGTM, thanks for fixing that issue :)

On Wed, Feb 21, 2024 at 6:03 AM Edwin Lu  wrote:

The testcase pr113742.c is failing for 32 bit targets due to the following cc1
error:
cc1: error: ABI requries '-march=rv64'

Specify '-march=rv64gc' with '-mtune=sifive-p600-series'

V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645609.html

 PR target/113742

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/pr113742.c: change mcpu to mtune and add march

Signed-off-by: Edwin Lu 
---
V1: use require-effective-target
V2: switch to specifying march and mtune
---
  gcc/testsuite/gcc.target/riscv/pr113742.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/pr113742.c 
b/gcc/testsuite/gcc.target/riscv/pr113742.c
index ab8934c2a8a..573afd6f0ad 100644
--- a/gcc/testsuite/gcc.target/riscv/pr113742.c
+++ b/gcc/testsuite/gcc.target/riscv/pr113742.c
@@ -1,4 +1,4 @@
-//* { dg-do compile } */
-/* { dg-options "-O2 -finstrument-functions -mabi=lp64d -mcpu=sifive-p670" } */
+/* { dg-do compile } */
+/* { dg-options "-O2 -finstrument-functions -march=rv64gc -mabi=lp64d 
-mtune=sifive-p600-series" } */

  void foo(void) {}
--
2.34.1

[PATCH V2] RISC-V: Specify mtune and march for PR113742

[Edwin Lu]

The testcase pr113742.c is failing for 32 bit targets due to the following cc1
error:
cc1: error: ABI requries '-march=rv64'

Specify '-march=rv64gc' with '-mtune=sifive-p600-series'

V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645609.html

PR target/113742

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr113742.c: change mcpu to mtune and add march

Signed-off-by: Edwin Lu 
---
V1: use require-effective-target
V2: switch to specifying march and mtune
---
 gcc/testsuite/gcc.target/riscv/pr113742.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/pr113742.c 
b/gcc/testsuite/gcc.target/riscv/pr113742.c
index ab8934c2a8a..573afd6f0ad 100644
--- a/gcc/testsuite/gcc.target/riscv/pr113742.c
+++ b/gcc/testsuite/gcc.target/riscv/pr113742.c
@@ -1,4 +1,4 @@
-//* { dg-do compile } */
-/* { dg-options "-O2 -finstrument-functions -mabi=lp64d -mcpu=sifive-p670" } */
+/* { dg-do compile } */
+/* { dg-options "-O2 -finstrument-functions -march=rv64gc -mabi=lp64d 
-mtune=sifive-p600-series" } */
 
 void foo(void) {}
-- 
2.34.1

Re: [Committed] testsuite: Add support for scanning assembly with comparitor

[Edwin Lu]

Thanks! Committed

Edwin

On 2/15/2024 9:27 AM, Mike Stump wrote:

On Feb 12, 2024, at 11:38 AM, Edwin Lu  wrote:

There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.

Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes would require a
separate testcase per tune since each assembly output would be different. If we
know a base number of lines should appear across all tunes (i.e. testing return
values: we expect at minimum n stores into register x), we can lower-bound the
test to search for scan-assembler-bound {RE for storing into register x} >= n.
This avoids artificially inflating the scan-assembler-times expected count due
to the assembler choosing to perform extra stores into register x (using it as
a temporary register).

The testcase would be more robust to cpu/tune changes at the cost of not being
as granular towards specific cpu tuning.

I didn't see an Ok?  Just in case you forgot, yes, this is ok.

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 2/15/2024 1:25 AM, Li, Pan2 wrote:


Sorry for late reply due to holiday. I double-checked the 
calling-convernsion-*.c dump, it is safe to adjust the asm check to the number 
as you mentioned.


Hi Pan,

I hope you had a good holiday! I already changed the numbers and added a 
bit more checks and documentation to the calling-convention-*.c files in 
this patch 
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645638.html.


If you have the time, it'd be great if you can take a look at it.

Thanks!
Edwin

[PATCH V4 4/5] RISC-V: Quick and simple fixes to testcases that break due to reordering

[Edwin Lu]

The following test cases are easily fixed with small updates to the expected
assembly order. Additionally make calling-convention testcases more robust

PR target/113249

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: update
* gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-5.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-6.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: reorder assembly
* gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto
* gcc.target/riscv/rvv/vsetvl/avl_single-107.c: change expected vsetvl

Signed-off-by: Edwin Lu 
---
V1-3:
- Patch did not exist
V4: 
- New patch
- improve calling-convention testcases (calling-conventions)
- reorder expected function body assembly (binop/shift_vx_constraint)
- change expected value (avl_single)
---
 .../rvv/autovec/vls/calling-convention-1.c| 27 ---
 .../rvv/autovec/vls/calling-convention-2.c| 23 ++--
 .../rvv/autovec/vls/calling-convention-3.c| 18 -
 .../rvv/autovec/vls/calling-convention-4.c| 12 -
 .../rvv/autovec/vls/calling-convention-5.c| 22 ++-
 .../rvv/autovec/vls/calling-convention-6.c| 17 
 .../rvv/autovec/vls/calling-convention-7.c| 12 -
 .../riscv/rvv/base/binop_vx_constraint-12.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-16.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-17.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-19.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-21.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-23.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-25.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-27.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-29.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-31.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-33.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-35.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-4.c|  4 +--
 .../riscv/rvv/base/binop_vx_constraint-40.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-44.c   |  4 +--
 .../riscv/rvv/base/binop_vx_constraint-8.c|  4 +--
 .../riscv/rvv/base/shift_vx_constraint-1.c|  5 +---
 .../riscv/rvv/vsetvl/avl_single-107.c |  2 +-
 25 files changed, 140 insertions(+), 62 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
index 41e31c258f8..217885c2d67 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
@@ -143,12 +143,33 @@ DEF_RET1_ARG9 (v1024qi)
 DEF_RET1_ARG9 (v2048qi)
 DEF_RET1_ARG9 (v4096qi)
 
+// RET1_ARG0 tests
 /* { dg-final { scan-assembler-times {li\s+a[0-1],\s*0} 9 } } */
+/* { dg-final { scan-assembler-times {mv\s+s0,a0\s+call\s+memset\s+mv\s+a0,s0} 
3 } } */
+
+// v1qi tests: return value (lbu) and function prologue (sb)
+// 1 lbu per test, argnum sb's when args > 1
 /* { dg-final { scan-assembler-times {lbu\s+a0,\s*[0-9]+\(sp\)} 8 } } */
-/* { dg-final { scan-assembler-times {lhu\s+a0,\s*[0-9]+\(sp\)} 8 } } */
-/* { dg-final { scan-assembler-times {lw\s+a0,\s*[0-9]+\(sp\)} 8 } } */
-/* { dg-final { scan-assembler-times {ld\s+a[0-1],\s*[0-9]+\(sp\)} 35 } } */
 /* { dg-final { scan-assembler-times {sb\s+a[0-7],\s*[0-9]+\(sp\)} 43 } } */
+
+// v2qi test: return value (lhu) and function prologue (sh)
+// 1 lhu per test, argnum sh's when args > 1
+/* { dg-final { scan-assembler

[PATCH V4 3/5] RISC-V: Use default cost model for insn scheduling

[Edwin Lu]

Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.

PR target/113249

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/bug-1.C: use default scheduling
* gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-50.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-56.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-62.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-68.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-74.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-79.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-84.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-90.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-96.c: ditto
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-30.c: ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: ditto
* gcc.target/riscv/rvv/base/pr108185-2.c: ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: ditto
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-28.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-29.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-32.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-33.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: ditto
* gfortran.dg/vect/vect-8.f90: ditto

Signed-off-by: Edwin Lu 
---
V2: 
- New patch
V3/V4:
- No change
---
 gcc/testsuite/g++.target/riscv/rvv/base/bug-1.C | 2 ++
 gcc/testsuite/gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-102.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-108.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-114.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-119.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-12.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-16.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-17.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-19.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-21.c

[PATCH V4 2/5] RISC-V: Add vector related pipelines

[Edwin Lu]

Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo): Move reservation
(generic_ooo_vec_load): ditto
(generic_ooo_vec_store): ditto
(generic_ooo_vec_loadstore_seg): ditto
(generic_ooo_vec_alu): ditto
(generic_ooo_vec_fcmp): ditto
(generic_ooo_vec_imul): ditto
(generic_ooo_vec_fadd): ditto
(generic_ooo_vec_fmul): ditto
(generic_ooo_crypto): ditto
(generic_ooo_perm): ditto
(generic_ooo_vec_reduction): ditto
(generic_ooo_vec_ordered_reduction): ditto
(generic_ooo_vec_idiv): ditto
(generic_ooo_vec_float_divsqrt): ditto
(generic_ooo_vec_mask): ditto
(generic_ooo_vec_vesetvl): ditto
(generic_ooo_vec_setrm): ditto
(generic_ooo_vec_readlen): ditto
* config/riscv/riscv.md: include generic-vector-ooo
* config/riscv/generic-vector-ooo.md: New file. to here

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2:
- Remove unnecessary syntax changes in generic-ooo
- Add new vector crypto reservations and types to
  pipelines
V3:
- Move all vector pipelines into separate file which defines all ooo vector
  reservations.
- Add temporary attribute while cost model changes.
V4:
- No change
---
 gcc/config/riscv/generic-ooo.md| 127 +-
 gcc/config/riscv/generic-vector-ooo.md | 143 +
 gcc/config/riscv/riscv.md  |   1 +
 3 files changed, 145 insertions(+), 126 deletions(-)
 create mode 100644 gcc/config/riscv/generic-vector-ooo.md

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index 83cd06234b3..e70df63d91f 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -1,5 +1,5 @@
 ;; RISC-V generic out-of-order core scheduling model.
-;; Copyright (C) 2017-2024 Free Software Foundation, Inc.
+;; Copyright (C) 2023-2024 Free Software Foundation, Inc.
 ;;
 ;; This file is part of GCC.
 ;;
@@ -48,9 +48,6 @@ (define_automaton "generic_ooo")
 ;; Integer/float issue queues.
 (define_cpu_unit "issue0,issue1,issue2,issue3,issue4" "generic_ooo")
 
-;; Separate issue queue for vector instructions.
-(define_cpu_unit "generic_ooo_vxu_issue" "generic_ooo")
-
 ;; Integer/float execution units.
 (define_cpu_unit "ixu0,ixu1,ixu2,ixu3" "generic_ooo")
 (define_cpu_unit "fxu0,fxu1" "generic_ooo")
@@ -58,12 +55,6 @@ (define_cpu_unit "fxu0,fxu1" "generic_ooo")
 ;; Integer subunit for division.
 (define_cpu_unit "generic_ooo_div" "generic_ooo")
 
-;; Vector execution unit.
-(define_cpu_unit "generic_ooo_vxu_alu" "generic_ooo")
-
-;; Vector subunit that does mult/div/sqrt.
-(define_cpu_unit "generic_ooo_vxu_multicycle" "generic_ooo")
-
 ;; Shortcuts
 (define_reservation "generic_ooo_issue" "issue0|issue1|issue2|issue3|issue4")
 (define_reservation "generic_ooo_ixu_alu" "ixu0|ixu1|ixu2|ixu3")
@@ -92,25 +83,6 @@ (define_insn_reservation "generic_ooo_float_store" 6
(eq_attr "type" "fpstore"))
   "generic_ooo_issue,generic_ooo_fxu")
 
-;; Vector load/store
-(define_insn_reservation "generic_ooo_vec_load" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-(define_insn_reservation "generic_ooo_vec_store" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vste,vstm,vsts,vstux,vstox,vstr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-;; Vector segment loads/stores.
-(define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,\
-   vssegte,vssegts,vssegtux,vssegtox"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-
 ;; Generic integer instructions.
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
@@ -191,103 +163,6 @@ (define_insn_reservation "generic_ooo_popcount" 2
(eq_attr "type" "cpop,clmul"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
-;; Regular vector operations and integer comparisons.
-(define_insn_reservation "generic_ooo_vec_alu" 3
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" 
"via

[PATCH V4 5/5] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

Enables assert that every typed instruction is associated with a
dfa reservation

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert

Signed-off-by: Edwin Lu 
---
V2:
- No changes
V3: 
- Remove debug statements
V4: 
- no changes
---
 gcc/config/riscv/riscv.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 4100abc9dd1..5e984ee2a55 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8269,9 +8269,7 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
 
   /* If we ever encounter an insn without an insn reservation, trip
  an assert so we can find and fix this problem.  */
-#if 0
   gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
 
   return more - 1;
 }
-- 
2.34.1

[PATCH V4 1/5] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

This patch adds non-vector related insn reservations and updates/creates
new insn reservations so all non-vector typed instructions have a reservation.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation
(generic_ooo_branch): ditto
* config/riscv/generic.md (generic_sfb_alu): ditto
(generic_fmul_half): ditto
* config/riscv/riscv.md: Remove cbo, pushpop, and rdfrm types
* config/riscv/sifive-7.md (sifive_7_hfma): Add reservation
(sifive_7_popcount): ditto
* config/riscv/sifive-p400.md (sifive_p400_clmul): ditto
* config/riscv/sifive-p600.md (sifive_p600_clmul): ditto
* config/riscv/vector.md: change rdfrm to fmove
* config/riscv/zc.md: change pushpop to load/store

Signed-off-by: Edwin Lu 
---
V2:
- Add insn reservations for HF fmul
- Remove/adjust insn types
V3:
- No changes
V4:
- Update sifive-p400 and sifive-p600 series
---
 gcc/config/riscv/generic-ooo.md | 15 +-
 gcc/config/riscv/generic.md | 20 +--
 gcc/config/riscv/riscv.md   | 16 +++---
 gcc/config/riscv/sifive-7.md| 17 +-
 gcc/config/riscv/sifive-p400.md | 10 +++-
 gcc/config/riscv/sifive-p600.md | 10 +++-
 gcc/config/riscv/vector.md  |  2 +-
 gcc/config/riscv/zc.md  | 96 -
 8 files changed, 117 insertions(+), 69 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index a22f8a3e079..83cd06234b3 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -115,9 +115,20 @@ (define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
-   move,bitmanip,min,max,minu,maxu,clz,ctz"))
+   move,bitmanip,rotate,min,max,minu,maxu,clz,ctz,atomic,\
+   condmove,mvpair,zicond"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
+(define_insn_reservation "generic_ooo_sfb_alu" 2
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "sfb_alu"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
+
+;; Branch instructions
+(define_insn_reservation "generic_ooo_branch" 1
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
 
 ;; Float move, convert and compare.
 (define_insn_reservation "generic_ooo_float_move" 3
@@ -184,7 +195,7 @@ (define_insn_reservation "generic_ooo_popcount" 2
 (define_insn_reservation "generic_ooo_vec_alu" 3
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov"))
+   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float comparison, conversion etc.
diff --git a/gcc/config/riscv/generic.md b/gcc/config/riscv/generic.md
index 3f0eaa2ea08..4f6e63bff57 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
@@ -27,7 +27,9 @@ (define_cpu_unit "fdivsqrt" "pipe0")
 
 (define_insn_reservation "generic_alu" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" 
"unknown,const,arith,shift,slt,multi,auipc,nop,logical,move,bitmanip,min,max,minu,maxu,clz,ctz,cpop"))
+   (eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
+   move,bitmanip,min,max,minu,maxu,clz,ctz,rotate,atomic,\
+   condmove,crypto,mvpair,zicond"))
   "alu")
 
 (define_insn_reservation "generic_load" 3
@@ -47,12 +49,17 @@ (define_insn_reservation "generic_xfer" 3
 
 (define_insn_reservation "generic_branch" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "branch,jump,call,jalr"))
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "alu")
+
+(define_insn_reservation "generic_sfb_alu" 2
+  (and (eq_attr "tune" "generic")
+   (eq_attr "type" "sfb_alu"))
   "alu")
 
 (define_insn_reservation "generic_imul" 10
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "imul,clmul"))
+   (eq_attr "type" "imul,clmul,cpop"))
   "imuldiv*10")
 
 (define_insn_reservation "generic_idivsi&qu

[PATCH V4 0/5] RISC-V: Associate typed insns to dfa reservation

[Edwin Lu]

Previous version (V3 23cd2961bd2ff63583f46e3499a07bd54491d45c) was reverted. 

Updates all tune insn reservation pipelines to cover all types defined by
define_attr "type" in riscv.md.

Creates new vector insn reservation pipelines in new file generic-vector-ooo.md
which has separate automaton vector_ooo where all reservations are mapped to.
This allows all tunes to share a common vector model for now as we make 
large changes to the vector cost model. 
(https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642511.html)

Disables pipeline scheduling for some tests with scan dump failures when using
-mtune=generic-ooo. 

Updates test cases that were failing due to simple insn reordering to match new
code generation

Enables assert that all insn types must be associated with a dfa pipeline
reservation

---
V2:
- Update non-vector insn types and add new pipelines
- Add -fno-schedule-insn -fno-schedule-insn2 to some test cases

V3:
- Separate vector pipelines to separate file which all tunes have access to

V4:
- Add insn reservations to sifive-p400 and sifive-p600 series
- Update test cases with new code generation
---

Edwin Lu (5):
  RISC-V: Add non-vector types to dfa pipelines
  RISC-V: Add vector related pipelines
  RISC-V: Use default cost model for insn scheduling
  RISC-V: Quick and simple fixes to testcases that break due to
reordering
  RISC-V: Enable assert for insn_has_dfa_reservation

 gcc/config/riscv/generic-ooo.md   | 140 ++---
 gcc/config/riscv/generic-vector-ooo.md| 143 ++
 gcc/config/riscv/generic.md   |  20 ++-
 gcc/config/riscv/riscv.cc |   2 -
 gcc/config/riscv/riscv.md |  17 +--
 gcc/config/riscv/sifive-7.md  |  17 ++-
 gcc/config/riscv/sifive-p400.md   |  10 +-
 gcc/config/riscv/sifive-p600.md   |  10 +-
 gcc/config/riscv/vector.md|   2 +-
 gcc/config/riscv/zc.md|  96 ++--
 .../g++.target/riscv/rvv/base/bug-1.C |   2 +
 .../riscv/rvv/autovec/reduc/reduc_call-2.c|   2 +
 .../rvv/autovec/vls/calling-convention-1.c|  27 +++-
 .../rvv/autovec/vls/calling-convention-2.c|  23 ++-
 .../rvv/autovec/vls/calling-convention-3.c|  18 ++-
 .../rvv/autovec/vls/calling-convention-4.c|  12 +-
 .../rvv/autovec/vls/calling-convention-5.c|  22 ++-
 .../rvv/autovec/vls/calling-convention-6.c|  17 +++
 .../rvv/autovec/vls/calling-convention-7.c|  12 +-
 .../riscv/rvv/base/binop_vx_constraint-102.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-108.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-114.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-119.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-12.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-16.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-17.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-19.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-21.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-23.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-25.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-27.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-29.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-31.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-33.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-35.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-4.c|   2 +-
 .../riscv/rvv/base/binop_vx_constraint-40.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-44.c   |   2 +-
 .../riscv/rvv/base/binop_vx_constraint-50.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-56.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-62.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-68.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-74.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-79.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-8.c|   2 +-
 .../riscv/rvv/base/binop_vx_constraint-84.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-90.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-96.c   |   2 +
 .../rvv/base/float-point-dynamic-frm-30.c |   2 +
 .../gcc.target/riscv/rvv/base/pr108185-1.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-2.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-3.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-4.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-5.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-6.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-7.c|   2 +
 .../riscv/rvv/base/shift_vx_constraint-1.c|   3 +-
 .../riscv/rvv/vsetvl/avl_single-107.c |   2 +-
 .../gcc.target/riscv/rvv/vsetvl/pr111037-3.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-28.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-29.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-32.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-33.c |   2 +
 .../riscv/

Re: [PATCH] RISC-V: Set require-effective-target rv64 for PR113742

[Edwin Lu]

On 2/14/2024 12:09 PM, Robin Dapp wrote:

On 2/14/24 20:46, Edwin Lu wrote:

The testcase pr113742.c is failing for 32 bit targets due to the following cc1
error:
cc1: error: ABI requries '-march=rv64'

I think we usually just add exactly this to the test options (so
it is always run rather than just on a 64-bit target.

Regards
  Robin


Ah oops I glanced over the /* { dg-do compile } */part. It should be 
fine to add '-march=rv64gc' instead then?


Edwin

[PATCH] RISC-V: Set require-effective-target rv64 for PR113742

[Edwin Lu]

The testcase pr113742.c is failing for 32 bit targets due to the following cc1
error:
cc1: error: ABI requries '-march=rv64'

Disable testing on rv32 targets

PR target/113742

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr113742.c: add require-effective-target

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.target/riscv/pr113742.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/riscv/pr113742.c 
b/gcc/testsuite/gcc.target/riscv/pr113742.c
index ab8934c2a8a..9cea92ed97c 100644
--- a/gcc/testsuite/gcc.target/riscv/pr113742.c
+++ b/gcc/testsuite/gcc.target/riscv/pr113742.c
@@ -1,4 +1,5 @@
 //* { dg-do compile } */
 /* { dg-options "-O2 -finstrument-functions -mabi=lp64d -mcpu=sifive-p670" } */
+/* { dg-require-effective-target rv64 } */
 
 void foo(void) {}
-- 
2.34.1

[PATCH] testsuite: Add support for scanning assembly with comparitor

[Edwin Lu]

There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.

Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes would require a
separate testcase per tune since each assembly output would be different. If we
know a base number of lines should appear across all tunes (i.e. testing return
values: we expect at minimum n stores into register x), we can lower-bound the
test to search for scan-assembler-bound {RE for storing into register x} >= n.
This avoids artificially inflating the scan-assembler-times expected count due
to the assembler choosing to perform extra stores into register x (using it as
a temporary register).

The testcase would be more robust to cpu/tune changes at the cost of not being
as granular towards specific cpu tuning.

gcc/ChangeLog:

* doc/sourcebuild.texi: add scan-assembler-bound

gcc/testsuite/ChangeLog:

* lib/scanasm.exp: add scan-assembler-bound

Signed-off-by: Edwin Lu 
---
 gcc/doc/sourcebuild.texi  |  4 +++
 gcc/testsuite/lib/scanasm.exp | 64 +++
 2 files changed, 68 insertions(+)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 193be19767f..4a8c672c9fd 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -3396,6 +3396,10 @@ excluding LTO sections.
 Passes if @var{regex} is matched exactly @var{num} times in the test's
 assembler output, excluding LTO sections.
 
+@item scan-assembler-bound @var{regex} @var{cmp} @var{num} [@{ target/xfail 
@var{selector} @}]
+Passes if @var{regex} is matched @var{cmp} @var{num} times in the test's
+assembler output, excluding LTO sections. @var{cmp} is a comparitor.
+
 @item scan-assembler-dem @var{regex} [@{ target/xfail @var{selector} @}]
 Passes if @var{regex} matches text in the test's demangled assembler output,
 excluding LTO sections.
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 165890eb976..741a5a048b8 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -516,6 +516,70 @@ proc scan-assembler-times { args } {
 
 set_required_options_for scan-assembler-times
 
+# Call pass if pattern is present within a lower or upper bound, 
+# otherwise fail.
+# ex /* { dg-final { scan-assembler-bound {RE} > 3 } }
+proc scan-assembler-bound { args } {
+if { [llength $args] < 3 } {
+   error "scan-assembler-bound: too few arguments"
+return
+}
+if { [llength $args] > 4 } {
+   error "scan-assembler-bound: too many arguments"
+   return
+}
+if { [llength $args] >= 4 } {
+   switch [dg-process-target [lindex $args 3]] {
+   "S" { }
+   "N" { return }
+   "F" { setup_xfail "*-*-*" }
+   "P" { }
+   }
+}
+
+set testcase [testname-for-summary]
+# The name might include a list of options; extract the file name.
+set filename [lindex $testcase 0]
+set pattern [lindex $args 0]
+set cmp [lindex $args 1]
+set bound [lindex $args 2]
+set pp_pattern [make_pattern_printable $pattern]
+
+# This must match the rule in gcc-dg.exp.
+set output_file "[file rootname [file tail $filename]].s"
+
+set files [glob -nocomplain $output_file]
+if { $files == "" } {
+   verbose -log "$testcase: output file does not exist"
+   unresolved "$testcase scan-assembler-bound $pp_pattern $min $max"
+   return
+}
+
+if { [lsearch { < > <= >= } $cmp] == -1 } {
+error "scan-assembler-bound: illegal argument: $cmp"
+return
+}
+if ![string is integer $bound ] {
+error "scan-assembler-bound: illegal argument: $bound"
+return
+}
+
+set fd [open $output_file r]
+set text [read $fd]
+close $fd
+regsub -all 
{(^|\n)[[:space:]]*\.section[[:space:]]*"?\.gnu\.lto_(?:[^\n]*\n(?![[:space:]]*\.(section|text|data|bss)))*[^\n]*\n}
 $text {\1} text
+
+set result_count [regexp -all -- $pattern $text]
+if [expr $result_count $cmp $bound] {
+   pass "$testcase scan-assembler-bound $pp_pattern $cmp $bound"
+} else {
+   verbose -log "$testcase: $pp_pattern found $result_count times"
+   fail "$testcase scan-assembler-bound $pp_pattern $cmp $bound"
+}
+}
+
+set_required_options_for scan-assembler-bound
+
 # Utility for scanning demangled compiler result, invoked via dg-final.
 # Call pass if pattern is present, otherwise fail.
 proc scan-assembler-dem { args } {
-- 
2.34.1

Re: [Committed] RISC-V: Fix rvv intrinsic pragma tests dejagnu selector

[Edwin Lu]

Committed

On 1/30/2024 9:51 AM, Palmer Dabbelt wrote:

On Mon, 29 Jan 2024 11:38:12 PST (-0800), e...@rivosinc.com wrote:

Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/abi-1.c: change selector
* gcc.target/riscv/rvv/base/pragma-2.c: ditto
* gcc.target/riscv/rvv/base/pragma-3.c: ditto

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c    | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c

index 2eef9e1e1a8..a072bdd47bf 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { ! riscv_xtheadvector } } } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { 
"-march=rv*v*" } } */

+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */

 void foo0 () {__rvv_bool64_t t;}
 void foo1 () {__rvv_bool32_t t;}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c

index fd2aa3066cd..fc1bb13c53d 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
@@ -1,4 +1,4 @@
 /* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { 
"-march=rv*v*" } } */

+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */

 #pragma riscv intrinsic "vector"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c

index 96a0e051a29..45580bb2faa 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
@@ -1,4 +1,4 @@
 /* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { 
"-march=rv*v*" } } */

+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } */

 #pragma riscv intrinsic "report-error" /* { dg-error {unknown 
'#pragma riscv intrinsic' option 'report-error'} } */


Reviewed-by: Palmer Dabbelt 

[PATCH] RISC-V: Add support for B standard extension

[Edwin Lu]

This patch adds support for recognizing the B standard extension to be the
collection of Zba, Zbb, Zbs extensions for consistency and conciseness across
toolchains

* https://github.com/riscv/riscv-b/tags

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Add imply rules for B extension
* config/riscv/arch-canonicalize: ditto

Signed-off-by: Edwin Lu 
---
 gcc/common/config/riscv/riscv-common.cc | 7 +++
 gcc/config/riscv/arch-canonicalize  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 631ce8309a0..31117a7b0fd 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -77,6 +77,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
   {"f", "zicsr"},
   {"d", "zicsr"},
 
+  {"b", "zba"},
+  {"b", "zbb"},
+  {"b", "zbs"},
+
   {"zdinx", "zfinx"},
   {"zfinx", "zicsr"},
   {"zdinx", "zicsr"},
@@ -235,6 +239,8 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"c", ISA_SPEC_CLASS_20190608, 2, 0},
   {"c", ISA_SPEC_CLASS_2P2,  2, 0},
 
+  {"b",   ISA_SPEC_CLASS_NONE, 1, 0},
+
   {"h",   ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"v",   ISA_SPEC_CLASS_NONE, 1, 0},
@@ -388,6 +394,7 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
 /* Combine extensions defined in this table  */
 static const struct riscv_ext_version riscv_combine_info[] =
 {
+  {"b",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zk",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zkn",  ISA_SPEC_CLASS_NONE, 1, 0},
   {"zks",  ISA_SPEC_CLASS_NONE, 1, 0},
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index 629bed85347..dcfae732714 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -41,6 +41,7 @@ LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
 IMPLIED_EXT = {
   "d" : ["f", "zicsr"],
   "f" : ["zicsr"],
+  "b" : ["zba", "zbb", "zbs"],
   "zdinx" : ["zfinx", "zicsr"],
   "zfinx" : ["zicsr"],
   "zhinx" : ["zhinxmin", "zfinx", "zicsr"],
-- 
2.34.1

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 2/2/2024 11:10 PM, Li, Pan2 wrote:

Hi Edwin


I believe the only problematic failures are the 5 vls calling convention
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.


Does this "only 24" comes from calling-convention-1.c?


Oops sorry about that. I said I would include all the 7 failures and 
ended up not doing that. The failures are here
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29


These all have the problem of only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 
being found. So that is calling-conventions 1, 2, 3, 4, 7 with only 24 
matching RE.


FAIL: gcc.target/riscv/rvv/base/vcreate.c scan-assembler-times 
vmv1r.v\\s+v[0-9]+,\\s*v[0-9]+ 24 <-- found 36 times
FAIL: gcc.target/riscv/rvv/base/vcreate.c scan-assembler-times 
vmv2r.v\\s+v[0-9]+,\\s*v[0-9]+ 12 <-- found 28 times
FAIL: gcc.target/riscv/rvv/base/vcreate.c scan-assembler-times 
vmv4r.v\\s+v[0-9]+,\\s*v[0-9]+ 16 <-- found 19 times


These find more vmv's than expected

FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-107.c   -O2 
scan-assembler-times vsetvli\\tzero,zero,e32,m1,t[au],m[au] 1 <-- found 
0 times
FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-107.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none   scan-assembler-times 
vsetvli\\tzero,zero,e32,m1,t[au],m[au] 1 <-- found 0 times
FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-107.c   -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects   scan-assembler-times 
vsetvli\\tzero,zero,e32,m1,t[au],m[au] 1 <-- found 0 times


These failures are from vsetvli zero,a0,e2,m1,ta,ma being found instead. 
I believe these should be fine.





This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:


V32qi will pass the args by reference instead of GPR(s), thus It is expected. I 
think we need to diff the asm code before and after the patch for the whole 
test-file.
The RE "ld\\s+a[0-1],\\s*[0-9]+\\(sp\\)" would like to check vls mode values 
are returned by a[0-1].



I've been using this https://godbolt.org/z/vdxTY3rc7 (calling convention 
1) as my comparison to what I have compiled locally (included as 
attachment). From what I see, the differences, aside from reordering due 
to latency, are that the ld insns use a5 (for 32-512) or t4 (for 
1024-2048) or t5 (for 4096) for ARG8 and ARG9. Is there something else 
that I might be missing?


Edwin

.file   "calling-convention-1.c"
.option nopic
.attribute arch, 
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl1024b1p0_zvl128b1p0_zvl2048b1p0_zvl256b1p0_zvl32b1p0_zvl4096b1p0_zvl512b1p0_zvl64b1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align  1
.globl  v1qi_RET1_ARG0
.type   v1qi_RET1_ARG0, @function
v1qi_RET1_ARG0:
.LFB0:
.cfi_startproc
li  a0,0
ret
.cfi_endproc
.LFE0:
.size   v1qi_RET1_ARG0, .-v1qi_RET1_ARG0
.align  1
.globl  v2qi_RET1_ARG0
.type   v2qi_RET1_ARG0, @function
v2qi_RET1_ARG0:
.LFB1:
.cfi_startproc
li  a0,0
ret
.cfi_endproc
.LFE1:
.size   v2qi_RET1_ARG0, .-v2qi_RET1_ARG0
.align  1
.globl  v4qi_RET1_ARG0
.type   v4qi_RET1_ARG0, @function
v4qi_RET1_ARG0:
.LFB2:
.cfi_startproc
li  a0,0
ret
.cfi_endproc
.LFE2:
.size   v4qi_RET1_ARG0, .-v4qi_RET1_ARG0
.align  1
.globl  v8qi_RET1_ARG0
.type   v8qi_RET1_ARG0, @function
v8qi_RET1_ARG0:
.LFB3:
.cfi_startproc
li  a0,0
ret
.cfi_endproc
.LFE3:
.size   v8qi_RET1_ARG0, .-v8qi_RET1_ARG0
.align  1
.globl  v16qi_RET1_ARG0
.type   v16qi_RET1_ARG0, @function
v16qi_RET1_ARG0:
.LFB4:
.cfi_startproc
li  a0,0
li  a1,0
ret
.cfi_endproc
.LFE4:
.size   v16qi_RET1_ARG0, .-v16qi_RET1_ARG0
.align  1
.globl  v32qi_RET1_ARG0
.type   v32qi_RET1_ARG0, @function
v32qi_RET1_ARG0:
.LFB5:
.cfi_startproc

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 2/1/2024 8:28 PM, Li, Pan2 wrote:

Hi Edwin,

Just rerun the newlib and there is no ICE but still 160 dump failures as below.

Pan



Hi Pan,

Thanks for confirming! Having dump failures is expected. There are 
around 7 more unique failures than I expected 
(https://github.com/patrick-rivos/gcc-postcommit-ci/issues/473 <-- 
postcommit found 46 while I expected 39 
https://inbox.sourceware.org/gcc-patches/12d205cd-3177-48ea-a54e-c2052fdde...@gmail.com/ 
https://github.com/ewlu/gcc-precommit-ci/issues/1178#issuecomment-1889782987) 



I included the 7 failed tests below and what was found instead.

I believe the only problematic failures are the 5 vls calling convention 
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.


FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29


This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:
.cfi_startproc
li  t1,32
vsetvli zero,t1,e8,mf8,ta,ma
vle8.v  v1,0(a1)
vle8.v  v4,0(a2)
vle8.v  v3,0(a3)
vle8.v  v2,0(a4)
vadd.vv v1,v1,v4
vadd.vv v1,v1,v3
vle8.v  v3,0(a5)
ld  a5,0(sp)  <-- used a5 instead of a1
vadd.vv v1,v1,v2
vle8.v  v2,0(a6)
vadd.vv v1,v1,v3
vle8.v  v3,0(a7)
vadd.vv v1,v1,v2
vle8.v  v2,0(a5)
vadd.vv v1,v1,v3
vadd.vv v1,v1,v2
vse8.v  v1,0(a0)
ret
.cfi_endproc

If I understand correctly, this is wrong since we aren't returning 
anything (nothing gets stored in a[0-1])?


Edwin

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 1/31/2024 11:05 PM, juzhe.zh...@rivai.ai wrote:
Sorry again. I just realized you have reverted your patches that's why I 
can pass the testing now.


I checkout your latest patch commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c>

Then I can reproduce the ICE now:

bug.c: In function 'popcount32_uint64_tuint64_t':
bug.c:20:3: internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972

    20 |   }
       |   ^
bug.c:123:3: note: in expansion of macro 'DEF32'
   123 |   DEF32 (uint64_t, uint64_t)   
                 \

       |   ^
bug.c:444:1: note: in expansion of macro 'DEF_ALL'
   444 | DEF_ALL ()
       | ^~~
0x1fbf06f riscv_vector::validate_change_or_fail(rtx_def*, rtx_def**, 
rtx_def*, bool)

         ../../../../gcc/gcc/config/riscv/riscv-v.cc:4972
0x1fe2c60 simplify_replace_vlmax_avl
         ../../../../gcc/gcc/config/riscv/riscv-avlprop.cc:200
0x1fe3b05 pass_avlprop::execute(function*)
         ../../../../gcc/gcc/config/riscv/riscv-avlprop.cc:506

Would you mind taking a look at it ?


juzhe.zh...@rivai.ai


Hi Juzhe,

I ran the following configs on both linux and newlib locally (at hash 
23cd2961bd2ff63583f46e3499a07bd54491d45c mtune=rocket) and did not find 
the ice, only additional scan dump failures.

rv32gc/ilp32d
rv32gc_zba_zbb_zbc_zbs/ilp32d
rv32gcv/ilp32d
rv64gc/lp64d
rv64gc_zba_zbb_zbc_zbs/lp64d
rv64gcv/lp64d
rv64gcv_zvbb_zvbc_zvkg_zvkn_zvknc_zvkned_zvkng_zvknha_zvknhb_zvks_zvksc_zvksed_zvksg_zvksh_zvkt/lp64d
rv64imafdcv_zicond_zawrs_zbc_zvkng_zvksg_zvbb_zvbc_zicsr_zba_zbb_zbs_zicbom_zicbop_zicboz_zfhmin_zkt/lp64d/

Can you send me what configuration you are using to get the ice? Is it 
appearing on other tunes? Nothing in my patch should affect anything in 
riscv-v.cc. I'll look into the problem if I'm able to reproduce the error.


The new scan dump failures are a result of now having a vector 
scheduling pipeline.


Edwin


*From:* Edwin Lu <mailto:e...@rivosinc.com>
*Date:* 2024-02-01 14:13
*To:* juzhe.zh...@rivai.ai <mailto:juzhe.zh...@rivai.ai>;
gcc-patches <mailto:gcc-patches@gcc.gnu.org>
*CC:* Robin Dapp <mailto:rdapp@gmail.com>; kito.cheng
<mailto:kito.ch...@gmail.com>; jeffreyalaw
<mailto:jeffreya...@gmail.com>; palmer <mailto:pal...@rivosinc.com>;
vineetg <mailto:vine...@rivosinc.com>; Patrick O'Neill
<mailto:patr...@rivosinc.com>
*Subject:* Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to
dfa pipelines
 From what I know, if it was a problem with my dfa reservation assert,
it would have ICEd in riscv.cc and not riscv-v.cc. For now I reverted
the changes since I don't want to leave things possibly broken
overnight
and not knowing which patch is the root cause. I kicked off another set
of test runs using our full gcc postcommit testing configurations and
should have those results in tomorrow. Hopefully it was just a missed
config target I didn't test and wasn't tested on the precommit ci.
Edwin
On 1/31/2024 9:42 PM, Edwin Lu wrote:
 > Hi Juzhe,
 >
 > I didn't see any ICEs when I tested locally (tested on
 >

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d).
 Can you tell me what config you're using?
 >
 > Edwin
 >
 > On 1/31/2024 6:57 PM, juzhe.zh...@rivai.ai wrote:
 >> Hi, all.
 >>
 >>

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8>
 >>

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8>
 >>

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707>
 >>

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c>
 >>
 >> These 4 commits cause all testcases failed (ICE and dump FAILs).
 >>
 >> FAIL:
gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_32-4.c
 >> scan-tree-dump-times vect "vectorized 1 loops in function" 11
 >> FAIL:
 >>
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 1/31/2024 11:29 PM, Li, Pan2 wrote:
I can somehow reproduce the failures on commit id 
23cd2961bd2ff63583f46e3499a07bd54491d45c, configurations as below.


./configure --prefix=${install_dir} \

--with-arch=rv64imafdcv \

--with-abi=lp64d \

--with-isa-spec=20191213 \

--with-sim=qemu

make -j $(nproc) build-sim SIM=qemu

make report -j $(nproc) RUNTESTFLAGS=rvv.exp

= Summary of gcc testsuite =

| # of unexpected case / # of unique unexpected case

|gcc |g++ |gfortran |

rv64imafdcv/lp64d/ medlow |160 /47 |0 /0 |- |

make: *** [Makefile:1067: report-gcc-newlib] Error 1

Pan


Hi Pan,

I'm getting similar numbers as well using your steps but I also want to 
confirm whether you are also getting the ICEs or are just getting 
additional scan dump failures. The scan dump failures are a result of 
adding the new scheduling pipelines. I skimmed through them and didn't 
find anything unexpected.


Edwin



*From:*juzhe.zh...@rivai.ai 
*Sent:* Thursday, February 1, 2024 3:06 PM
*To:* Edwin Lu ; gcc-patches 
*Cc:* Robin Dapp ; kito.cheng 
; jeffreyalaw ; palmer 
; vineetg ; Patrick O'Neill 

*Subject:* Re: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to 
dfa pipelines


Sorry again. I just realized you have reverted your patches that's why I 
can pass the testing now.


I checkout your latest patch commit:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c>



Then I can reproduce the ICE now:



bug.c: In function 'popcount32_uint64_tuint64_t':

bug.c:20:3: internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972


    20 |   }

       |   ^

bug.c:123:3: note: in expansion of macro 'DEF32'

   123 |   DEF32 (uint64_t, uint64_t)   
                 \


       |   ^

bug.c:444:1: note: in expansion of macro 'DEF_ALL'

   444 | DEF_ALL ()

       | ^~~

0x1fbf06f riscv_vector::validate_change_or_fail(rtx_def*, rtx_def**, 
rtx_def*, bool)


         ../../../../gcc/gcc/config/riscv/riscv-v.cc:4972

0x1fe2c60 simplify_replace_vlmax_avl

         ../../../../gcc/gcc/config/riscv/riscv-avlprop.cc:200

0x1fe3b05 pass_avlprop::execute(function*)

         ../../../../gcc/gcc/config/riscv/riscv-avlprop.cc:506

Would you mind taking a look at it ?



juzhe.zh...@rivai.ai <mailto:juzhe.zh...@rivai.ai>

*From:*Edwin Lu <mailto:e...@rivosinc.com>

*Date:* 2024-02-01 14:13

*To:*juzhe.zh...@rivai.ai <mailto:juzhe.zh...@rivai.ai>; gcc-patches
<mailto:gcc-patches@gcc.gnu.org>

*CC:*Robin Dapp <mailto:rdapp@gmail.com>; kito.cheng
<mailto:kito.ch...@gmail.com>; jeffreyalaw
<mailto:jeffreya...@gmail.com>; palmer <mailto:pal...@rivosinc.com>;
vineetg <mailto:vine...@rivosinc.com>; Patrick O'Neill
<mailto:patr...@rivosinc.com>

*Subject:* Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to
dfa pipelines

 From what I know, if it was a problem with my dfa reservation assert,

it would have ICEd in riscv.cc and not riscv-v.cc. For now I reverted

the changes since I don't want to leave things possibly broken
overnight

and not knowing which patch is the root cause. I kicked off another set

of test runs using our full gcc postcommit testing configurations and

should have those results in tomorrow. Hopefully it was just a missed

config target I didn't test and wasn't tested on the precommit ci.

Edwin

On 1/31/2024 9:42 PM, Edwin Lu wrote:

> Hi Juzhe,

>

> I didn't see any ICEs when I tested locally (tested on

>

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d>).
 Can you tell me what config you're using?

>

> Edwin

>

> On 1/31/2024 6:57 PM,  juzhe.zh...@rivai.ai <mailto:juzhe.zh...@rivai.ai> 
wrote:

>> Hi, all.

>>

>>
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8> 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8>>

>>
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8> 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3f

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

From what I know, if it was a problem with my dfa reservation assert, 
it would have ICEd in riscv.cc and not riscv-v.cc. For now I reverted 
the changes since I don't want to leave things possibly broken overnight 
and not knowing which patch is the root cause. I kicked off another set 
of test runs using our full gcc postcommit testing configurations and 
should have those results in tomorrow. Hopefully it was just a missed 
config target I didn't test and wasn't tested on the precommit ci.


Edwin

On 1/31/2024 9:42 PM, Edwin Lu wrote:

Hi Juzhe,

I didn't see any ICEs when I tested locally (tested on 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d). Can you tell me what config you're using?


Edwin

On 1/31/2024 6:57 PM, juzhe.zh...@rivai.ai wrote:

Hi, all.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8>
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8>
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707>
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
 
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c>

These 4 commits cause all testcases failed (ICE and dump FAILs).

FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_32-4.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_run-9.c 
(internal

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

Hi Juzhe,

I didn't see any ICEs when I tested locally (tested on 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8123f3ca3fd891034a8366518e756f161c4ff40d). 
Can you tell me what config you're using?


Edwin

On 1/31/2024 6:57 PM, juzhe.zh...@rivai.ai wrote:

Hi, all.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=26c34b809cd1a6249027730a8b52bbf6a1c0f4a8
 

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e56fb037d9d265682f5e7217d8a4c12a8d3fddf8
 

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b799a16ae59fc0f508c5931ebf1851a3446b707
 

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
 


These 4 commits cause all testcases failed (ICE and dump FAILs).

FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_32-4.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-11.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_64-1.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_64-4.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-2.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_64-8.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_64-3.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_run-9.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_run-9.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-3.c 
(internal compiler error: in validate_change_or_fail, at 
config/riscv/riscv-v.cc:4972)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-3.c 
(test for excess errors)
FAIL: 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-3.c 
scan-tree-dump-times vect "vectorized 1 loops in function" 11
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_32-4.c 
(internal compiler error: in

Re: [PATCH] RISC-V: Support scheduling for sifive p600 series

[Edwin Lu]

I recently committed changes modifying the scheduling reservations. Some 
things may need to be retested with the newly enabled asserts.


Edwin

On 1/31/2024 1:40 AM, Monk Chiang wrote:

Add sifive p600 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p650-670.
Add sifive-p650, sifive-p670 for mcpu option will come in separate patches.

gcc/ChangeLog:
* config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type
attribute, and include sifive-p600.md.
* config/riscv/generic-ooo.md: Update type attribute.
* config/riscv/sifive-7.md: Update type attribute.
* config/riscv/sifive-p600.md: New file.
* config/riscv/riscv-cores.def (RISCV_TUNE): Add parameter.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type):
Add sifive_p600.
* config/riscv/riscv.c (sifive_p600_tune_info): New.
* config/riscv/riscv.h (TARGET_SFB_ALU): Update.
* doc/invoke.texi (RISC-V Options): Add sifive-p600-series
---
  gcc/config/riscv/generic-ooo.md  |   2 +-
  gcc/config/riscv/generic.md  |   2 +-
  gcc/config/riscv/riscv-cores.def |   1 +
  gcc/config/riscv/riscv-opts.h|   1 +
  gcc/config/riscv/riscv.cc|  17 +++
  gcc/config/riscv/riscv.h |   4 +-
  gcc/config/riscv/riscv.md|  19 ++--
  gcc/config/riscv/sifive-7.md |   2 +-
  gcc/config/riscv/sifive-p600.md  | 174 +++
  gcc/doc/invoke.texi  |   3 +-
  10 files changed, 212 insertions(+), 13 deletions(-)
  create mode 100644 gcc/config/riscv/sifive-p600.md

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index 421a7bb929d..a22f8a3e079 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -127,7 +127,7 @@
  
  (define_insn_reservation "generic_ooo_fcvt" 3

(and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "fcvt"))
+   (eq_attr "type" "fcvt,fcvt_i2f,fcvt_f2i"))
"generic_ooo_issue,generic_ooo_fxu")
  
  (define_insn_reservation "generic_ooo_fcmp" 2

diff --git a/gcc/config/riscv/generic.md b/gcc/config/riscv/generic.md
index b99ae345bb3..3f0eaa2ea08 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
@@ -42,7 +42,7 @@
  
  (define_insn_reservation "generic_xfer" 3

(and (eq_attr "tune" "generic")
-   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp"))
+   (eq_attr "type" "mfc,mtc,fcvt,fcvt_i2f,fcvt_f2i,fmove,fcmp"))
"alu")
  
  (define_insn_reservation "generic_branch" 1

diff --git a/gcc/config/riscv/riscv-cores.def b/gcc/config/riscv/riscv-cores.def
index b30f4dfb08e..a07a79e2cb7 100644
--- a/gcc/config/riscv/riscv-cores.def
+++ b/gcc/config/riscv/riscv-cores.def
@@ -37,6 +37,7 @@ RISCV_TUNE("rocket", generic, rocket_tune_info)
  RISCV_TUNE("sifive-3-series", generic, rocket_tune_info)
  RISCV_TUNE("sifive-5-series", generic, rocket_tune_info)
  RISCV_TUNE("sifive-7-series", sifive_7, sifive_7_tune_info)
+RISCV_TUNE("sifive-p600-series", sifive_p600, sifive_p600_tune_info)
  RISCV_TUNE("thead-c906", generic, thead_c906_tune_info)
  RISCV_TUNE("generic-ooo", generic_ooo, generic_ooo_tune_info)
  RISCV_TUNE("size", generic, optimize_size_tune_info)
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 1500f8811ef..25951665b13 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -55,6 +55,7 @@ extern enum riscv_isa_spec_class riscv_isa_spec;
  enum riscv_microarchitecture_type {
generic,
sifive_7,
+  sifive_p600,
generic_ooo
  };
  extern enum riscv_microarchitecture_type riscv_microarchitecture;
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7b6111aa545..92d6fd5cf47 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -447,6 +447,23 @@ static const struct riscv_tune_param sifive_7_tune_info = {
NULL,   /* vector cost */
  };
  
+/* Costs to use when optimizing for Sifive p600 Series.  */

+static const struct riscv_tune_param sifive_p600_tune_info = {
+  {COSTS_N_INSNS (4), COSTS_N_INSNS (4)},  /* fp_add */
+  {COSTS_N_INSNS (4), COSTS_N_INSNS (4)},  /* fp_mul */
+  {COSTS_N_INSNS (20), COSTS_N_INSNS (20)},/* fp_div */
+  {COSTS_N_INSNS (4), COSTS_N_INSNS (4)},  /* int_mul */
+  {COSTS_N_INSNS (6), COSTS_N_INSNS (6)},  /* int_div */
+  4,   /* issue_rate */
+  4,   /* branch_cost */
+  3,   /* memory_cost */
+  4,   /* fmv_cost */
+  true,/* 
slow_unaligned_access */
+  false,   /* use_divmod_expansion */
+  RISCV_FUSE_LUI_ADDI | RISCV_FUSE_AUIPC_ADDI,  /* fusible_ops */
+  NULL,/* vector cost */
+};

Re: [COMMITTED V4 2/4] RISC-V: Add vector related pipelines

[Edwin Lu]

On 1/31/2024 12:28 PM, Robin Dapp wrote:

LGTM, thanks.

Regards
  Robin



Committed!

Edwin

Re: [COMMITTED V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:

/* If we ever encounter an insn without an insn reservation, trip
   an assert so we can find and fix this problem.  */
-#if 0
+  if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type (insn));
+  }
gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
  
return more - 1;

  }


I was thinking about make the gcc_assert a gcc_checking_assert so,
in case we accidentally forget something at any point, it would
only gracefully degrade in a release build.  As we already have
a hard assert for the type the patch (and not many test with
enable checking anyway) this is OK IMHO.

I suppose you tested with all available -mtune options?

Regards
  Robin




Committed without the debugging stuff!

Edwin

Re: [COMMITTED V3 3/4] RISC-V: Use default cost model for insn scheduling

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:

Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.


This is OK, thanks.


39 additional unique testsuite failures (scan dumps) will still be present.
I don't know how optimal the new output is compared to the old. Should I update
the testcase expected output to match the new scan dumps?


Currently, without vector op latency, the output should come close
to what's normally considered "good" (i.e. minimal number of vsetvls
and so on).  Therefore I'd suggest not to change the scan dumps to
much except when there is a real problem.  If you have a specific
example that you're unsure about we can discuss this on or off list.

Regards
  Robin




Committed!

Edwin

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:

LGTM, thanks.

Regards
  Robin



Committed!

Edwin

[PATCH V4 2/4] RISC-V: Add vector related pipelines

[Edwin Lu]

Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo): Move reservation
(generic_ooo_vec_load): ditto
(generic_ooo_vec_store): ditto
(generic_ooo_vec_loadstore_seg): ditto
(generic_ooo_vec_alu): ditto
(generic_ooo_vec_fcmp): ditto
(generic_ooo_vec_imul): ditto
(generic_ooo_vec_fadd): ditto
(generic_ooo_vec_fmul): ditto
(generic_ooo_crypto): ditto
(generic_ooo_perm): ditto
(generic_ooo_vec_reduction): ditto
(generic_ooo_vec_ordered_reduction): ditto
(generic_ooo_vec_idiv): ditto
(generic_ooo_vec_float_divsqrt): ditto
(generic_ooo_vec_mask): ditto
(generic_ooo_vec_vesetvl): ditto
(generic_ooo_vec_setrm): ditto
(generic_ooo_vec_readlen): ditto
* config/riscv/riscv.md: include generic-vector-ooo
* config/riscv/generic-vector-ooo.md: New file. to here

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2:
- Remove unnecessary syntax changes in generic-ooo
- Add new vector crypto reservations and types to
  pipelines
V3:
- Move all vector pipelines into separate file which defines all ooo vector
  reservations.
- Add temporary attribute while cost model changes.
V4:
- Remove temporary attribute
---
 gcc/config/riscv/generic-ooo.md| 127 +-
 gcc/config/riscv/generic-vector-ooo.md | 143 +
 gcc/config/riscv/riscv.md  |   1 +
 3 files changed, 145 insertions(+), 126 deletions(-)
 create mode 100644 gcc/config/riscv/generic-vector-ooo.md

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index ef8cb96daf4..4e8297bf96f 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -1,5 +1,5 @@
 ;; RISC-V generic out-of-order core scheduling model.
-;; Copyright (C) 2017-2024 Free Software Foundation, Inc.
+;; Copyright (C) 2023-2024 Free Software Foundation, Inc.
 ;;
 ;; This file is part of GCC.
 ;;
@@ -48,9 +48,6 @@ (define_automaton "generic_ooo")
 ;; Integer/float issue queues.
 (define_cpu_unit "issue0,issue1,issue2,issue3,issue4" "generic_ooo")
 
-;; Separate issue queue for vector instructions.
-(define_cpu_unit "generic_ooo_vxu_issue" "generic_ooo")
-
 ;; Integer/float execution units.
 (define_cpu_unit "ixu0,ixu1,ixu2,ixu3" "generic_ooo")
 (define_cpu_unit "fxu0,fxu1" "generic_ooo")
@@ -58,12 +55,6 @@ (define_cpu_unit "fxu0,fxu1" "generic_ooo")
 ;; Integer subunit for division.
 (define_cpu_unit "generic_ooo_div" "generic_ooo")
 
-;; Vector execution unit.
-(define_cpu_unit "generic_ooo_vxu_alu" "generic_ooo")
-
-;; Vector subunit that does mult/div/sqrt.
-(define_cpu_unit "generic_ooo_vxu_multicycle" "generic_ooo")
-
 ;; Shortcuts
 (define_reservation "generic_ooo_issue" "issue0|issue1|issue2|issue3|issue4")
 (define_reservation "generic_ooo_ixu_alu" "ixu0|ixu1|ixu2|ixu3")
@@ -92,25 +83,6 @@ (define_insn_reservation "generic_ooo_float_store" 6
(eq_attr "type" "fpstore"))
   "generic_ooo_issue,generic_ooo_fxu")
 
-;; Vector load/store
-(define_insn_reservation "generic_ooo_vec_load" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-(define_insn_reservation "generic_ooo_vec_store" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vste,vstm,vsts,vstux,vstox,vstr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-;; Vector segment loads/stores.
-(define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,\
-   vssegte,vssegts,vssegtux,vssegtox"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-
 ;; Generic integer instructions.
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
@@ -191,103 +163,6 @@ (define_insn_reservation "generic_ooo_popcount" 2
(eq_attr "type" "cpop,clmul"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
-;; Regular vector operations and integer comparisons.
-(define_insn_reservation "generic_ooo_vec_alu" 3
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" 
"via

[PATCH] RISC-V: Fix rvv intrinsic pragma tests dejagnu selector

[Edwin Lu]

Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/abi-1.c: change selector
* gcc.target/riscv/rvv/base/pragma-2.c: ditto
* gcc.target/riscv/rvv/base/pragma-3.c: ditto

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
index 2eef9e1e1a8..a072bdd47bf 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { ! riscv_xtheadvector } } } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { "-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */
 
 void foo0 () {__rvv_bool64_t t;}
 void foo1 () {__rvv_bool32_t t;}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
index fd2aa3066cd..fc1bb13c53d 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
@@ -1,4 +1,4 @@
 /* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { "-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */
 
 #pragma riscv intrinsic "vector"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
index 96a0e051a29..45580bb2faa 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
@@ -1,4 +1,4 @@
 /* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } { "-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } */
 
 #pragma riscv intrinsic "report-error" /* { dg-error {unknown '#pragma riscv 
intrinsic' option 'report-error'} } */
-- 
2.34.1

Re: [PATCH V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:

/* If we ever encounter an insn without an insn reservation, trip
   an assert so we can find and fix this problem.  */
-#if 0
+  if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type (insn));
+  }
gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
  
return more - 1;

  }


Oops accidentally left my debugging statements in the patch.



I was thinking about make the gcc_assert a gcc_checking_assert so,
in case we accidentally forget something at any point, it would
only gracefully degrade in a release build.  As we already have
a hard assert for the type the patch (and not many test with
enable checking anyway) this is OK IMHO.

I suppose you tested with all available -mtune options?



I ran the testsuite on all three tunes using linux rv64gcv. generic-ooo 
had some bugs fixed while rocket and sifive-7-series had around 37 new 
scan dump failures which I think is to be expected. No ICE's from the 
hard gcc_assert on any of the tunes so I think it should be fine as is.


Edwin

Re: [PATCH V3 3/4] RISC-V: Use default cost model for insn scheduling

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:


39 additional unique testsuite failures (scan dumps) will still be present.
I don't know how optimal the new output is compared to the old. Should I update
the testcase expected output to match the new scan dumps?


Currently, without vector op latency, the output should come close
to what's normally considered "good" (i.e. minimal number of vsetvls
and so on).  Therefore I'd suggest not to change the scan dumps to
much except when there is a real problem.  If you have a specific
example that you're unsure about we can discuss this on or off list.



That sounds good to me! I don't have a specific example that stands out. 
It's mostly just not finding the expected number of vsetvls or the 
vector insns have been moved earlier or something like that.


Edwin

Re: [PATCH V3 2/4] RISC-V: Add vector related pipelines

[Edwin Lu]

On 1/25/2024 9:06 AM, Robin Dapp wrote:

Thanks, that looks better IMHO.


+;; Copyright (C) 2011-2024 Free Software Foundation, Inc.
+;; Contributed by Andrew Waterman (and...@sifive.com).
+;; Based on MIPS target for GNU compiler.

You might want to change that, as well as the date.  While at
it you can also fix the broken date in my original file ;)



Completely forgot about this. I'll update it :)


+(define_insn_reservation "vec_load" 6
+  (and (eq_attr "is_inorder" "no")
+   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr"))
+  "vxu_ooo_issue,vxu_ooo_alu")

I would rather ditch the is_inorder attribute for now and define
"low" latencies as well as reservations explicitly once we're
sure rather than falling back to scheduler defaults.



I think removing the is_inorder attribute should be ok. I added it 
because I wanted to avoid having two matching insn reservations defined 
since matching solely on the type attribute should also match on all 
subsets as well (i.e. if eventually we add an insn reservation checking 
for type "vlde" and tune "generic-ooo", any "vlde" insn would map to 
both reservations)


For now I should just remove the is_inorder attribute. We will update 
the latencies and add new reservations after we know what they should 
be. Is that correct?



OK with those changes.

Regards
  Robin

Re: [Committed V2] RISC-V: Fix regression (GCC-14 compare with GCC-13.2) of SHA256 from coremark-pro

[Edwin Lu]

On 1/16/2024 5:41 PM, juzhe.zh...@rivai.ai wrote:
Are you saying using glibc lib ? I do the testing with newlib, I didn't 
anything wrong.


Yes, I'm seeing the problem using glibc. Looking at our postcommit ci 
reports, it appears to only affect linux rv32gcv.
It seems that this patch triggers latent bug of VSETVL PASS (Even though 
this patch doesn't change anything related to VSETVL PASS).


I will investigate it.

Thanks.


Thanks!

Edwin

Re: [Committed V2] RISC-V: Fix regression (GCC-14 compare with GCC-13.2) of SHA256 from coremark-pro

[Edwin Lu]

Hi Juzhe,

I'm seeing that this patch introduces failures with rv32gcv-ilp32d as 
seen here https://github.com/ewlu/gcc-precommit-ci/issues/1194. Digging 
a little deeper, it appears that there's an illegal instruction in a 
shared library which (at least for FAIL: 
gcc.c-torture/execute/920501-8.c   -O2  execution test) is using vmv.v.i 
without a prior vsetvl. I believe the other failures may be similar.


Logs:
spawn -ignore SIGHUP 
/scratch/ewlu/ci/triage/compare/build-407-errors/build-gcc-linux-stage2/gcc/xgcc 
-B/scratch/ewlu/ci/triage/compare/build-407-errors/build-gcc-linux-stage2/gcc/ 
/scratch/ewlu/ci/triage/compare/gcc/gcc/testsuite/gcc.c-torture/execute/920501-8.c 
-march=rv32gcv -mabi=ilp32d -mtune=rocket -mcmodel=medlow 
-fdiagnostics-plain-output -O2 -w -lm -o ./920501-8.exe

PASS: gcc.c-torture/execute/920501-8.c   -O2  (test for excess errors)
spawn riscv64-unknown-linux-gnu-run ./920501-8.exe
/scratch/ewlu/ci/triage/compare/build-407-errors/../scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run: 
line 15: 584664 Illegal instruction (core dumped) 
QEMU_CPU="$(march-to-cpu-opt --get-riscv-tag $1)" qemu-riscv$xlen -r 
5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"

FAIL: gcc.c-torture/execute/920501-8.c   -O2  execution test

Execution:
QEMU_CPU="rv32,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true" 
./bin/qemu-riscv32 ./920501-8.exe


GDB output:
Program received signal SIGILL, Illegal instruction.
0x2b3d0f3e in __printf_buffer () from 
/scratch/ewlu/ci/triage/compare/build-407-errors/sysroot/lib32/ilp32d/libc.so.6

1: x/i $pc
=> 0x2b3d0f3e <__printf_buffer+410>:vmv.v.i v1,0

I've included the first 150ish lines of the function's objdump below.

Edwin

$ ./bin/riscv64-unknown-linux-gnu-objdump -d 
sysroot/lib32/ilp32d/libc.so.6 > dump


00046da4 <__printf_buffer>:
   46da4:   000f8797auipc   a5,0xf8
   46da8:   1ac7a783lw  a5,428(a5) # 13ef50 
<_GLOBAL_OFFSET_TABLE_+0x64>

   46dac:   b3010113addisp,sp,-1232
   46db0:   4c812423sw  s0,1224(sp)
   46db4:   c6besw  a5,76(sp)
   46db6:   9792add a5,a5,tp
   46db8:   439clw  a5,0(a5)
   46dba:   842amv  s0,a0
   46dbc:   4d212023sw  s2,1216(sp)
   46dc0:   c2aesw  a1,68(sp)
   46dc2:   892emv  s2,a1
   46dc4:   852emv  a0,a1
   46dc6:   02500593li  a1,37
   46dca:   de3esw  a5,60(sp)
   46dcc:   4c112623sw  ra,1228(sp)
   46dd0:   4c912223sw  s1,1220(sp)
   46dd4:   4b312e23sw  s3,1212(sp)
   46dd8:   4b812423sw  s8,1192(sp)
   46ddc:   84b2mv  s1,a2
   46dde:   dcb2sw  a2,120(sp)
   46de0:   89b6mv  s3,a3
   46de2:   c0b6sw  a3,64(sp)
   46de4:   60a300efjal 773ee 
   46de8:   c4aasw  a0,72(sp)
   46dea:   41250633sub a2,a0,s2
   46dee:   8c2amv  s8,a0
   46df0:   85camv  a1,s2
   46df2:   8522mv  a0,s0
   46df4:   933f90efjal 40726 
<__printf_buffer_write>

   46df8:   4c1clw  a5,24(s0)
   46dfa:   c3ddbeqza5,46ea0 
<__printf_buffer+0xfc>

   46dfc:   000c4783lbu a5,0(s8)
   46e00:   c3c5beqza5,46ea0 
<__printf_buffer+0xfc>

   46e02:   000fa797auipc   a5,0xfa
   46e06:   85a7a783lw  a5,-1958(a5) # 14065c 
<__printf_function_table>

   46e0a:   4b512a23sw  s5,1204(sp)
   46e0e:   da3esw  a5,52(sp)
   46e10:   c399beqza5,46e16 
<__printf_buffer+0x72>
   46e12:   2680106fj   4807a 
<__printf_buffer+0x12d6>

   46e16:   000fa797auipc   a5,0xfa
   46e1a:   8367a783lw  a5,-1994(a5) # 14064c 
<__printf_modifier_table>
   46e1e:   740797e3bneza5,47d6c 
<__printf_buffer+0xfc8>

   46e22:   000f9797auipc   a5,0xf9
   46e26:   e927a783lw  a5,-366(a5) # 13fcb4 
<__printf_va_arg_table>
   46e2a:   740791e3bneza5,47d6c 
<__printf_buffer+0xfc8>

   46e2e:   57fdli  a5,-1
   46e30:   d0besw  a5,96(sp)
   46e32:   0019f793andia5,s3,1
   46e36:   d4besw  a5,104(sp)
   46e38:   111caddi  

[PATCH V3 3/4] RISC-V: Use default cost model for insn scheduling

[Edwin Lu]

Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.

39 additional unique testsuite failures (scan dumps) will still be present.
I don't know how optimal the new output is compared to the old. Should I update
the testcase expected output to match the new scan dumps?

PR target/113249

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/bug-1.C: use default scheduling
* gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-50.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-56.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-62.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-68.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-74.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-79.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-84.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-90.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-96.c: ditto
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-30.c: ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: ditto
* gcc.target/riscv/rvv/base/pr108185-2.c: ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: ditto
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-28.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-29.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-32.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-33.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: ditto
* gfortran.dg/vect/vect-8.f90: ditto

Signed-off-by: Edwin Lu 
---
 gcc/testsuite/g++.target/riscv/rvv/base/bug-1.C | 2 ++
 gcc/testsuite/gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-102.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-108.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-114.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-119.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-12.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-16.c  | 2 ++
 .../gcc.target/riscv/rvv

[PATCH V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

Enables assert that every typed instruction is associated with a
dfa reservation

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert

Signed-off-by: Edwin Lu 
---
V2:
- No changes
V3:
- No changes
---
 gcc/config/riscv/riscv.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ee1a57b321d..c428d3e4e58 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8215,9 +8215,11 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
 
   /* If we ever encounter an insn without an insn reservation, trip
  an assert so we can find and fix this problem.  */
-#if 0
+  if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type (insn));
+  }
   gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
 
   return more - 1;
 }
-- 
2.34.1

[PATCH V3 2/4] RISC-V: Add vector related pipelines

[Edwin Lu]

Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations. Add temporary attribute
for making changes to the vector cost model

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo): Move reservation
(generic_ooo_vec_load): ditto
(generic_ooo_vec_store): ditto
(generic_ooo_vec_loadstore_seg): ditto
(generic_ooo_vec_alu): ditto
(generic_ooo_vec_fcmp): ditto
(generic_ooo_vec_imul): ditto
(generic_ooo_vec_fadd): ditto
(generic_ooo_vec_fmul): ditto
(generic_ooo_crypto): ditto
(generic_ooo_perm): ditto
(generic_ooo_vec_reduction): ditto
(generic_ooo_vec_ordered_reduction): ditto
(generic_ooo_vec_idiv): ditto
(generic_ooo_vec_float_divsqrt): ditto
(generic_ooo_vec_mask): ditto
(generic_ooo_vec_vesetvl): ditto
(generic_ooo_vec_setrm): ditto
(generic_ooo_vec_readlen): ditto
* config/riscv/riscv.md (no): add temporary attribute
* config/riscv/generic-vector-ooo.md: to here

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2:
- Remove unnecessary syntax changes in generic-ooo
- Add new vector crypto reservations and types to
  pipelines
V3:
- Move all vector pipelines into separate file which defines all ooo vector
  reservations.
- Add temporary attribute while cost model changes.
---
 gcc/config/riscv/generic-ooo.md| 125 ---
 gcc/config/riscv/generic-vector-ooo.md | 165 +
 gcc/config/riscv/riscv.md  |   5 +
 3 files changed, 170 insertions(+), 125 deletions(-)
 create mode 100644 gcc/config/riscv/generic-vector-ooo.md

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index ef8cb96daf4..40e5104cde1 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -48,9 +48,6 @@ (define_automaton "generic_ooo")
 ;; Integer/float issue queues.
 (define_cpu_unit "issue0,issue1,issue2,issue3,issue4" "generic_ooo")
 
-;; Separate issue queue for vector instructions.
-(define_cpu_unit "generic_ooo_vxu_issue" "generic_ooo")
-
 ;; Integer/float execution units.
 (define_cpu_unit "ixu0,ixu1,ixu2,ixu3" "generic_ooo")
 (define_cpu_unit "fxu0,fxu1" "generic_ooo")
@@ -58,12 +55,6 @@ (define_cpu_unit "fxu0,fxu1" "generic_ooo")
 ;; Integer subunit for division.
 (define_cpu_unit "generic_ooo_div" "generic_ooo")
 
-;; Vector execution unit.
-(define_cpu_unit "generic_ooo_vxu_alu" "generic_ooo")
-
-;; Vector subunit that does mult/div/sqrt.
-(define_cpu_unit "generic_ooo_vxu_multicycle" "generic_ooo")
-
 ;; Shortcuts
 (define_reservation "generic_ooo_issue" "issue0|issue1|issue2|issue3|issue4")
 (define_reservation "generic_ooo_ixu_alu" "ixu0|ixu1|ixu2|ixu3")
@@ -92,25 +83,6 @@ (define_insn_reservation "generic_ooo_float_store" 6
(eq_attr "type" "fpstore"))
   "generic_ooo_issue,generic_ooo_fxu")
 
-;; Vector load/store
-(define_insn_reservation "generic_ooo_vec_load" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-(define_insn_reservation "generic_ooo_vec_store" 6
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vste,vstm,vsts,vstux,vstox,vstr"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-;; Vector segment loads/stores.
-(define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,\
-   vssegte,vssegts,vssegtux,vssegtox"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-
-
 ;; Generic integer instructions.
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
@@ -191,103 +163,6 @@ (define_insn_reservation "generic_ooo_popcount" 2
(eq_attr "type" "cpop,clmul"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
-;; Regular vector operations and integer comparisons.
-(define_insn_reservation "generic_ooo_vec_alu" 3
-  (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
-  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
-

[PATCH V3 1/4] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

This patch adds non-vector related insn reservations and updates/creates
new insn reservations so all non-vector typed instructions have a reservation.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation
(generic_ooo_branch): ditto
* config/riscv/generic.md ( dittogeneric_sfb_alu):
(generic_fmul_half): ditto
* config/riscv/riscv.md: Remove cbo, pushpop, and rdfrm types
* config/riscv/sifive-7.md (sifive_7_hfma): Add reservation
(sifive_7_popcount): ditto
* config/riscv/vector.md: change rdfrm to fmove
* config/riscv/zc.md: change pushpop to load/store

Signed-off-by: Edwin Lu 
---
V2:
- Add insn reservations for HF fmul
- Remove/adjust insn types
V3:
- No changes
---
 gcc/config/riscv/generic-ooo.md | 15 +-
 gcc/config/riscv/generic.md | 20 +--
 gcc/config/riscv/riscv.md   | 18 +++
 gcc/config/riscv/sifive-7.md| 17 +-
 gcc/config/riscv/vector.md  |  2 +-
 gcc/config/riscv/zc.md  | 96 -
 6 files changed, 102 insertions(+), 66 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index 421a7bb929d..ef8cb96daf4 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -115,9 +115,20 @@ (define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
-   move,bitmanip,min,max,minu,maxu,clz,ctz"))
+   move,bitmanip,rotate,min,max,minu,maxu,clz,ctz,atomic,\
+   condmove,mvpair,zicond"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
+(define_insn_reservation "generic_ooo_sfb_alu" 2
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "sfb_alu"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
+
+;; Branch instructions
+(define_insn_reservation "generic_ooo_branch" 1
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
 
 ;; Float move, convert and compare.
 (define_insn_reservation "generic_ooo_float_move" 3
@@ -184,7 +195,7 @@ (define_insn_reservation "generic_ooo_popcount" 2
 (define_insn_reservation "generic_ooo_vec_alu" 3
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov"))
+   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float comparison, conversion etc.
diff --git a/gcc/config/riscv/generic.md b/gcc/config/riscv/generic.md
index b99ae345bb3..45986cfea89 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
@@ -27,7 +27,9 @@ (define_cpu_unit "fdivsqrt" "pipe0")
 
 (define_insn_reservation "generic_alu" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" 
"unknown,const,arith,shift,slt,multi,auipc,nop,logical,move,bitmanip,min,max,minu,maxu,clz,ctz,cpop"))
+   (eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
+   move,bitmanip,min,max,minu,maxu,clz,ctz,rotate,atomic,\
+   condmove,crypto,mvpair,zicond"))
   "alu")
 
 (define_insn_reservation "generic_load" 3
@@ -47,12 +49,17 @@ (define_insn_reservation "generic_xfer" 3
 
 (define_insn_reservation "generic_branch" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "branch,jump,call,jalr"))
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "alu")
+
+(define_insn_reservation "generic_sfb_alu" 2
+  (and (eq_attr "tune" "generic")
+   (eq_attr "type" "sfb_alu"))
   "alu")
 
 (define_insn_reservation "generic_imul" 10
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "imul,clmul"))
+   (eq_attr "type" "imul,clmul,cpop"))
   "imuldiv*10")
 
 (define_insn_reservation "generic_idivsi" 34
@@ -67,6 +74,12 @@ (define_insn_reservation "generic_idivdi" 66
(eq_attr "mode" "DI")))
   "imuldiv*66")
 
+(define_insn_reservation "generic_fmul_half" 5
+  (and (eq_attr "tune&

[PATCH V3 0/4] RISC-V: Associate typed insns to dfa reservation

[Edwin Lu]

Updates all tune insn reservation pipelines to cover all types defined by
define_attr "type" in riscv.md.

Creates new vector insn reservation pipelines in new file generic-vector-ooo.md
which has separate automaton vector_ooo where all reservations are mapped to.
This allows all tunes to share a common vector model for now as we make 
large changes to the vector cost model. 
(https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642511.html)

Disables pipeline scheduling for some tests with scan dump failures when using
-mtune=generic-ooo. 

Enables assert that all insn types must be associated with a dfa pipeline
reservation

Edwin Lu (4):
  RISC-V: Add non-vector types to dfa pipelines
  RISC-V: Add vector related pipelines
  RISC-V: Use default cost model for insn scheduling
  RISC-V: Enable assert for insn_has_dfa_reservation

---
V2:
- Update non-vector insn types and add new pipelines
- Add -fno-schedule-insn -fno-schedule-insn2 to some test cases

V3:
- Separate vector pipelines to separate file which all tunes have access to
---

 gcc/config/riscv/generic-ooo.md   | 138 ++-
 gcc/config/riscv/generic-vector-ooo.md| 165 ++
 gcc/config/riscv/generic.md   |  20 ++-
 gcc/config/riscv/riscv.cc |   6 +-
 gcc/config/riscv/riscv.md |  23 +--
 gcc/config/riscv/sifive-7.md  |  17 +-
 gcc/config/riscv/vector.md|   2 +-
 gcc/config/riscv/zc.md|  96 +-
 .../g++.target/riscv/rvv/base/bug-1.C |   2 +
 .../riscv/rvv/autovec/reduc/reduc_call-2.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-102.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-108.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-114.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-119.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-12.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-16.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-17.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-19.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-21.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-23.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-25.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-27.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-29.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-31.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-33.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-35.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-4.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-40.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-44.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-50.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-56.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-62.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-68.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-74.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-79.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-8.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-84.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-90.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-96.c   |   2 +
 .../rvv/base/float-point-dynamic-frm-30.c |   2 +
 .../gcc.target/riscv/rvv/base/pr108185-1.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-2.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-3.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-4.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-5.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-6.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-7.c|   2 +
 .../riscv/rvv/base/shift_vx_constraint-1.c|   2 +
 .../gcc.target/riscv/rvv/vsetvl/pr111037-3.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-28.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-29.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-32.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-33.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-17.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-18.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-19.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-11.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-12.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-4.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-5.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-6.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-7.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-8.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-9.c   |   2 +
 gcc/testsuite/gfortran.dg/vect/vect-8.f90 |   2 +
 66 files changed, 391 insertions(+), 192 deletions(-)
 create mode 100644 gcc/config/riscv/generic-vector-ooo.md

-- 
2.34.1

Re: [PATCH V2 2/4][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

Since all the pipelines should be tuned to their cost model, they
would be different anyway. If it would be simpler for now, I could
separate the files out.
I think I'm getting a bit confused. Is there a reason why we would
want to exchange scheduler descriptions like the example you
provided? I'm just thinking why a in-order model would want to use an
ooo vector model and vice versa. Please correct me if I got the wrong
idea.


Yeah, the confusion is understandable as it's all in flow and several
things I mentioned are artifacts of us not yet being stabilized (or
actually having hard data to base our decisions on).

Usually, once a uarch has settled there is no reason to exchange
anything, just smaller tweaks might be done.  I was more thinking of
the near to mid-term future where larger changes like ripping out
one thing and using another one altogether might still happen.

Regarding out of order vs in order - for in-order pipelines we will
always want to get latencies right.  For out of order it is a balancing
act (proper latencies often mean more spilling and the processor will
reorder correctly anyway).

So you're mostly right that the argument is not very strong as soon
as we really know what to do and not to do.


That makes sense to me!

I also want to double check, isn't forcing all typed instructions to
be part of a dfa pipeline in effect removing a situation where a tune
model does not specify a "vector tune model"? At least from my
testing with the assert statement, I get ICEs when trying to run the
testsuite without the vector tune model even on gc.


There are (at least) three parts of the "tune model":
  - vector cost model, specifying the cost of generic vector operations,
not necessarily corresponding to an insn
  - insn cost, specifying the cost of an individual insn, usually close
to latency but sometimes also "complexity" or other things.
  - insn latency and other hardware scheduler properties.

We can leave out any of those which will make us fall back to default
values.  Even if we forced a scheduler description we could still have
the default fallback for the other two and generate unfavorable code
as a result.

So if I'm understanding things correctly, the costs the Juzhe is working 
on in riscv.cc would be part of the vector cost model since they don't 
correspond to individual instructions and only target vector code. These 
costs would be the default fallback in the event of having no scheduler 
descriptions for the insn.


The vector pipelines I'm working describes the insn latency categorized 
by the insn type. The scheduler will attempt to generate favorable code 
by this description but also consider the vector cost model. That is, 
it's possible for an insn with a latency of 1 and cost of 10 to be 
replaced by an insn with a latency of 2 and cost of 3.


The insn cost is the cost of every insn which can be specified 
elsewhere. These override the values in the vector cost model for vector 
insns? Where are these specified?


Then, all of these combined form a tune model like generic-ooo or rocket.

However, this is of course not desirable and we will soon have a
reasonable vector cost model that corresponds to the non-uarch
specific properties of the vector spec.  Once this is in place
we will also want a somewhat generic vector scheduler description
that goes hand in hand with that.  Despite the name, the vector
part of generic-ooo could be used for in-order vector uarchs and
we might want to define a different description for out-of-order
uarchs.  That's a separate discussion but at least for that
contingency it would make sense to easily interchange the scheduler
description ;)

I think I understand everything. I'm currently testing a run with a 
generic-vector-ooo file and I'm a little unsure how we would create a 
second generic-vector-in-order file such that each insn maps only to one 
reservation without using tune attributes but I guess that will be an 
implementation detail for later :)


Edwin

Re: [PATCH V2 2/4][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

Hi Robin,
On 1/10/2024 8:00 AM, Robin Dapp wrote:

Hi Edwin,


This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. Creates new vector crypto related
insn reservations.


In principle, the changes look good to me but I wonder if we could
split off the vector parts from generic-ooo into their own md file
(generic-vector-ooo or so?) and include this in the others?  Or is
there a reason why you decided against this?

I forgot we could include other md files into another file (I'll double 
check that there isn't anything fancy for including other pipelines), 
but I also thought that eventually all the tunes would have their own 
vector cost pipelines. Since all the pipelines should be tuned to their 
cost model, they would be different anyway. If it would be simpler for 
now, I could separate the files out.



A recurring question in vector cost model discussions seems to be how
to handle the situation when a tune model does not specify a "vector tune
model".  The problem exists for the scheduler descriptions and the
normal vector cost model (and possibly insn_costs as well).

Juzhe just implemented a fallback so we always use the "generic rvv" cost
model.  Your changes would be in the same vein and if we could split
them off then we'd be able to easier exchange one scheduler descriptions
for another one (say if one tune model wants to use an in-order vector
model).

I think I'm getting a bit confused. Is there a reason why we would want 
to exchange scheduler descriptions like the example you provided? I'm 
just thinking why a in-order model would want to use an ooo vector model 
and vice versa. Please correct me if I got the wrong idea.


I also want to double check, isn't forcing all typed instructions to be 
part of a dfa pipeline in effect removing a situation where a tune model 
does not specify a "vector tune model"? At least from my testing with 
the assert statement, I get ICEs when trying to run the testsuite 
without the vector tune model even on gc.



There is also still the question of whether to set all latencies
to 1 for an OOO core but this question should be settled separately
as soon as we have proper hardware benchmark results.  If so we
would probably rename generic-vector-ooo into
generic-vector-in-order ;)

Regards
  Robin



I agree the latencies can be tweaked after we get those benchmarks :)

Edwin

[PATCH V2 3/4][RFC] RISC-V: Use default cost model for insn scheduling for tests affected in PR113249

[Edwin Lu]

Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.

Unfortunately, 40 unique testsuite failures (scan dumps) will still be present.
I don't know how optimal the new output is compared to the old. Should I update
the testcase expected output to match the new scan dumps?

PR target/113249

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/bug-1.C: use default tune scheduling
* gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-50.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-56.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-62.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-68.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-74.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-79.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-84.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-90.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-96.c: ditto
* gcc.target/riscv/rvv/base/float-point-dynamic-frm-30.c: ditto
* gcc.target/riscv/rvv/base/pr108185-1.c: ditto
* gcc.target/riscv/rvv/base/pr108185-2.c: ditto
* gcc.target/riscv/rvv/base/pr108185-3.c: ditto
* gcc.target/riscv/rvv/base/pr108185-4.c: ditto
* gcc.target/riscv/rvv/base/pr108185-5.c: ditto
* gcc.target/riscv/rvv/base/pr108185-6.c: ditto
* gcc.target/riscv/rvv/base/pr108185-7.c: ditto
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-28.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-29.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-32.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-33.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: ditto
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: ditto
* gfortran.dg/vect/vect-8.f90: ditto

Signed-off-by: Edwin Lu 
---
V2: 
- New patch
---
 gcc/testsuite/g++.target/riscv/rvv/base/bug-1.C | 2 ++
 gcc/testsuite/gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-102.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-108.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-114.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-119.c | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-12.c  | 2 ++
 .../gcc.target/riscv/rvv/base/binop_vx_constraint-16.c

[PATCH V2 1/4][RFC] RISC-V: Add non-vector types to dfa pipelines

[Edwin Lu]

This patch adds non-vector related insn reservations and updates/creates
new insn reservations so all non-vector typed instructions have a reservation.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation
(generic_ooo_branch): ditto
* config/riscv/generic.md (generic_sfb_alu): ditto
(generic_fmul_half): ditto
* config/riscv/riscv.md: Remove cbo, pushpop, and rdfrm types
* config/riscv/sifive-7.md (sifive_7_hfma): Add reservation
(sifive_7_popcount): ditto
* config/riscv/vector.md: change rdfrm to fmove
* config/riscv/zc.md: change pushpop to load/store

Signed-off-by: Edwin Lu 
---
V2:
- Add insn reservations for HF fmul
- Remove/adjust insn types
---
 gcc/config/riscv/generic-ooo.md | 15 +-
 gcc/config/riscv/generic.md | 20 +--
 gcc/config/riscv/riscv.md   | 18 +++
 gcc/config/riscv/sifive-7.md| 17 +-
 gcc/config/riscv/vector.md  |  2 +-
 gcc/config/riscv/zc.md  | 96 -
 6 files changed, 102 insertions(+), 66 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index 421a7bb929d..ef8cb96daf4 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -115,9 +115,20 @@ (define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
-   move,bitmanip,min,max,minu,maxu,clz,ctz"))
+   move,bitmanip,rotate,min,max,minu,maxu,clz,ctz,atomic,\
+   condmove,mvpair,zicond"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
+(define_insn_reservation "generic_ooo_sfb_alu" 2
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "sfb_alu"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
+
+;; Branch instructions
+(define_insn_reservation "generic_ooo_branch" 1
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "generic_ooo_issue,generic_ooo_ixu_alu")
 
 ;; Float move, convert and compare.
 (define_insn_reservation "generic_ooo_float_move" 3
@@ -184,7 +195,7 @@ (define_insn_reservation "generic_ooo_popcount" 2
 (define_insn_reservation "generic_ooo_vec_alu" 3
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov"))
+   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float comparison, conversion etc.
diff --git a/gcc/config/riscv/generic.md b/gcc/config/riscv/generic.md
index b99ae345bb3..45986cfea89 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
@@ -27,7 +27,9 @@ (define_cpu_unit "fdivsqrt" "pipe0")
 
 (define_insn_reservation "generic_alu" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" 
"unknown,const,arith,shift,slt,multi,auipc,nop,logical,move,bitmanip,min,max,minu,maxu,clz,ctz,cpop"))
+   (eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
+   move,bitmanip,min,max,minu,maxu,clz,ctz,rotate,atomic,\
+   condmove,crypto,mvpair,zicond"))
   "alu")
 
 (define_insn_reservation "generic_load" 3
@@ -47,12 +49,17 @@ (define_insn_reservation "generic_xfer" 3
 
 (define_insn_reservation "generic_branch" 1
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "branch,jump,call,jalr"))
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap"))
+  "alu")
+
+(define_insn_reservation "generic_sfb_alu" 2
+  (and (eq_attr "tune" "generic")
+   (eq_attr "type" "sfb_alu"))
   "alu")
 
 (define_insn_reservation "generic_imul" 10
   (and (eq_attr "tune" "generic")
-   (eq_attr "type" "imul,clmul"))
+   (eq_attr "type" "imul,clmul,cpop"))
   "imuldiv*10")
 
 (define_insn_reservation "generic_idivsi" 34
@@ -67,6 +74,12 @@ (define_insn_reservation "generic_idivdi" 66
(eq_attr "mode" "DI")))
   "imuldiv*66")
 
+(define_insn_reservation "generic_fmul_half" 5
+  (and (eq_attr "tune" "generic")
+

[PATCH V2 4/4][RFC] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

Enables assert that every typed instruction is associated with a
dfa reservation

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert

Signed-off-by: Edwin Lu 
---
V2:
- No changes
---
 gcc/config/riscv/riscv.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 32183d63180..e275fcc2245 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8150,9 +8150,11 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
 
   /* If we ever encounter an insn without an insn reservation, trip
  an assert so we can find and fix this problem.  */
-#if 0
+  if (! insn_has_dfa_reservation_p (insn)) {
+print_rtl(stderr, insn);
+fprintf(stderr, "%d", get_attr_type (insn));
+  }
   gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
 
   return more - 1;
 }
-- 
2.34.1

[PATCH V2 0/4][RFC] RISC-V: Associate typed insns to dfa reservation

[Edwin Lu]

This series is a prototype for adding all typed instructions to a dfa 
scheduling pipeline.

This is what I currently have for cleaning up the cost models. Adding the 
vector insns to the dfa pipelines changes the expected output of a lot of test
cases as expected. Should I update the expected output of the test cases to
the output of the new cost model? I'm not fully sure which codegen is more
optimal. Please let me know if I should do so and I'll add a patch adjusting
the expected testcase output.

Edwin Lu (4):
  RISC-V: Add non-vector types to dfa pipelines
  RISC-V: Add vector related reservations
  RISC-V: Use default cost model for insn scheduling for tests affected
in PR113249
  RISC-V: Enable assert for insn_has_dfa_reservation

---
V2:
- Update non-vector insn types and add new pipelines
- Add -fno-schedule-insn -fno-schedule-insn2 to some test cases
---

 gcc/config/riscv/generic-ooo.md   |  40 -
 gcc/config/riscv/generic.md   | 163 +-
 gcc/config/riscv/riscv.cc |   6 +-
 gcc/config/riscv/riscv.md |  18 +-
 gcc/config/riscv/sifive-7.md  | 161 -
 gcc/config/riscv/vector.md|   2 +-
 gcc/config/riscv/zc.md|  96 +--
 .../g++.target/riscv/rvv/base/bug-1.C |   2 +
 .../riscv/rvv/autovec/reduc/reduc_call-2.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-102.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-108.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-114.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-119.c  |   2 +
 .../riscv/rvv/base/binop_vx_constraint-12.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-16.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-17.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-19.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-21.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-23.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-25.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-27.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-29.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-31.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-33.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-35.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-4.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-40.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-44.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-50.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-56.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-62.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-68.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-74.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-79.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-8.c|   2 +
 .../riscv/rvv/base/binop_vx_constraint-84.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-90.c   |   2 +
 .../riscv/rvv/base/binop_vx_constraint-96.c   |   2 +
 .../rvv/base/float-point-dynamic-frm-30.c |   2 +
 .../gcc.target/riscv/rvv/base/pr108185-1.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-2.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-3.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-4.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-5.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-6.c|   2 +
 .../gcc.target/riscv/rvv/base/pr108185-7.c|   2 +
 .../riscv/rvv/base/shift_vx_constraint-1.c|   2 +
 .../gcc.target/riscv/rvv/vsetvl/pr111037-3.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-28.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-29.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-32.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_back_prop-33.c |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-17.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-18.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_single_block-19.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-11.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-12.c  |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-4.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-5.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-6.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-7.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-8.c   |   2 +
 .../riscv/rvv/vsetvl/vlmax_switch_vtype-9.c   |   2 +
 gcc/testsuite/gfortran.dg/vect/vect-8.f90 |   2 +
 65 files changed, 532 insertions(+), 70 deletions(-)

-- 
2.34.1

[PATCH V2 2/4][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. Creates new vector crypto related
insn reservations.

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo_crypto_aes): create 
reservation
(generic_ooo_crypto_sha): ditto
(generic_ooo_crypto_sm): ditto
(generic_ooo_vec_vesetvl): ditto
(generic_ooo_vec_vsetvl): ditto
* config/riscv/generic.md (pipe0): ditto
(generic_vec_load): ditto
(generic_vec_store): ditto
(generic_vec_loadstore_seg): ditto
(generic_vec_alu): ditto
(generic_vec_fcmp): ditto
(generic_vec_imul): ditto
(generic_vec_fadd): ditto
(generic_vec_fmul): ditto
(generic_crypto): ditto
(generic_crypto_aes): ditto
(generic_crypto_sha): ditto
(generic_crypto_sm): ditto
(generic_perm): ditto
(generic_vec_reduction): ditto
(generic_vec_ordered_reduction): ditto
(generic_vec_idiv): ditto
(generic_vec_float_divsqrt): ditto
(generic_vec_mask): ditto
(generic_vec_vesetvl): ditto
(generic_vec_setrm): ditto
(generic_vec_readlen): ditto
* config/riscv/sifive-7.md (sifive_7): ditto
(sifive_7_vec_load): ditto
(sifive_7_vec_store): ditto
(sifive_7_vec_loadstore_seg): ditto
(sifive_7_vec_alu): ditto
(sifive_7_vec_fcmp): ditto
(sifive_7_vec_imul): ditto
(sifive_7_vec_fadd): ditto
(sifive_7_vec_fmul): ditto
(sifive_7_crypto): ditto
(sifive_7_crypto_aes): ditto
(sifive_7_crypto_sha): ditto
(sifive_7_crypto_sm): ditto
(sifive_7_perm): ditto
(sifive_7_vec_reduction): ditto
(sifive_7_vec_ordered_reduction): ditto
(sifive_7_vec_idiv): ditto
(sifive_7_vec_float_divsqrt): ditto
(sifive_7_vec_mask): ditto
(sifive_7_vec_vesetvl): ditto
(sifive_7_vec_setrm): ditto
(sifive_7_vec_readlen): ditto

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
V2:
- Remove unnecessary syntax changes in generic-ooo
- Add new vector crypto reservations and types to
  pipelines
---
 gcc/config/riscv/generic-ooo.md |  27 +-
 gcc/config/riscv/generic.md | 143 +++
 gcc/config/riscv/sifive-7.md| 144 
 3 files changed, 311 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index ef8cb96daf4..fb5f34c0ef2 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -195,7 +195,8 @@ (define_insn_reservation "generic_ooo_popcount" 2
 (define_insn_reservation "generic_ooo_vec_alu" 3
   (and (eq_attr "tune" "generic_ooo")
(eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
+   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector,\
+   vandn,vbrev,vbrev8,vrev8,vclz,vctz,vrol,vror,vwsll"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float comparison, conversion etc.
@@ -209,7 +210,8 @@ (define_insn_reservation "generic_ooo_vec_fcmp" 3
 ;; Vector integer multiplication.
 (define_insn_reservation "generic_ooo_vec_imul" 4
   (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vimul,viwmul,vimuladd,viwmuladd,vsmul"))
+   (eq_attr "type" "vimul,viwmul,vimuladd,viwmuladd,vsmul,vclmul,vclmulh,\
+   vghsh,vgmul"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float addition.
@@ -230,6 +232,25 @@ (define_insn_reservation "generic_ooo_crypto" 4
(eq_attr "type" "crypto"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
+;; Vector crypto, AES
+(define_insn_reservation "generic_ooo_crypto_aes" 4
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "vaesef,vaesem,vaesdf,vaesdm,vaeskf1,vaeskf2,vaesz"))
+  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
+
+;; Vector crypto, sha
+(define_insn_reservation "generic_ooo_crypto_sha" 4
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "vsha2ms,vsha2ch,vsha2cl"))
+  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
+
+;; Vector crypto, SM3/4
+(define_insn_reservation "generic_ooo_crypto_sm" 4
+  (and (eq_attr "tune" "generic_ooo")
+   (eq_attr "type" "vsm4k,vsm4r,vsm3me,vsm3c"))
+  "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
+
+
 ;; Vector permute.
 (define_insn_reservation "generic_ooo_perm" 3

Re: [PATCH 2/3][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

On 12/20/2023 2:55 PM, Edwin Lu wrote:

On 12/20/2023 10:57 AM, Jeff Law wrote:



On 12/15/23 11:53, Edwin Lu wrote:

This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. The vector pipelines are
necessary to avoid an ICE from the assert


I forgot to get clarification earlier but this patch would introduce 
many scan-dump failures for both vector and non-vector targets 
(https://github.com/ewlu/gcc-precommit-ci/issues/950#issuecomment-1858392181). 
I haven't identified any execution errors that would be introduced on 
mtune=rocket aside from one ICE which I'm currently working on fixing.


Additionally, as mentioned in PR113035, there are significant testsuite 
differences between mtune=rocket and mtune=sifive-7-series. I haven't 
gone through all of the differences and I don't know if they are a 
problem with the patch or a result of the cost modeling assumptions.


Is there a problem with the current way mtune=rocket is modeled with 
generic.md?


Edwin

Re: [PATCH 2/3][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

On 12/20/2023 10:57 AM, Jeff Law wrote:



On 12/15/23 11:53, Edwin Lu wrote:

This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. The vector pipelines are
necessary to avoid an ICE from the assert




gcc/ChangeLog:

* config/riscv/generic-ooo.md: syntax
* config/riscv/generic.md (pipe0): new reservation
(generic_vec_load): ditto
(generic_vec_store): ditto
(generic_vec_loadstore_seg): ditto
(generic_generic_vec_alu): ditto
(generic_vec_fcmp): ditto
(generic_vec_imul): ditto
(generic_vec_fadd): ditto
(generic_vec_fmul): ditto
(generic_crypto): ditto
(generic_vec_perm): ditto
(generic_vec_reduction): ditto
(generic_vec_ordered_reduction): ditto
(generic_vec_idiv): ditto
(generic_vec_float_divsqrt): ditto
(generic_vec_mask): ditto
(generic_vec_vesetvl): ditto
(generic_vec_setrm): ditto
(generic_vec_readlen): ditto
* config/riscv/sifive-7.md (sifive_7): new reservation
(sifive_7_vec_load): ditto
(sifive_7_vec_store): ditto
(sifive_7_vec_loadstore_seg): ditto
(sifive_7_sifive_7_vec_alu): ditto
(sifive_7_vec_fcmp): ditto
(sifive_7_vec_imul): ditto
(sifive_7_vec_fadd): ditto
(sifive_7_vec_fmul): ditto
(sifive_7_crypto): ditto
(sifive_7_vec_perm): ditto
(sifive_7_vec_reduction): ditto
(sifive_7_vec_ordered_reduction): ditto
(sifive_7_vec_idiv): ditto
(sifive_7_vec_float_divsqrt): ditto
(sifive_7_vec_mask): ditto
(sifive_7_vec_vesetvl): ditto
(sifive_7_vec_setrm): ditto
(sifive_7_vec_readlen): ditto

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
  gcc/config/riscv/generic-ooo.md |  19 ++---
  gcc/config/riscv/generic.md | 118 
  gcc/config/riscv/sifive-7.md    | 118 
  3 files changed, 242 insertions(+), 13 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md 
b/gcc/config/riscv/generic-ooo.md

index de93245f965..18b606bb981 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
I'm not sure why you changed these.  In general we try to keep lines 
under 80 columns in the source.  Things like insn reservations are in a 
grey area as the lists sometimes get very long.  In general I'd leave 
this stuff alone if it doesn't have a function change.


Hmm when I was testing things before, I encountered an error where the 
scheduler had a problem with "\ " with the assert enabled, but now 
I can't reproduce it. I'll revert it back to what it originally was and 
experiment some more.


index 3e49d942495..7ac974ad634 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
Note that some of the stuff pointed out on patch #1 applies here to, 
like rdfrm not being a vector load/store.  So as you clean up patch #1, 
make sure to mirror the cleanups in patch #2 of the series.



Will do!

Edwin

Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines

[Edwin Lu]

On 12/20/2023 10:50 AM, Jeff Law wrote:



On 12/15/23 11:53, Edwin Lu wrote:

This patch does not create vector related insn reservations for
generic.md and sifive-7.md. It updates/creates insn reservations
for all non-vector typed insns

gcc/ChangeLog:

* config/riscv/generic-ooo.md (generic_ooo_sfb_alu): create/update 
reservation

(generic_ooo_branch): ditto
* config/riscv/generic.md (generic_sfb_alu): ditto
* config/riscv/sifive-7.md (sifive_7_popcount): ditto

Signed-off-by: Edwin Lu 
---
  gcc/config/riscv/generic-ooo.md | 16 +---
  gcc/config/riscv/generic.md | 13 +
  gcc/config/riscv/sifive-7.md    | 12 +---
  3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md 
b/gcc/config/riscv/generic-ooo.md

index 78b9e48f935..de93245f965 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -95,7 +95,7 @@ (define_insn_reservation "generic_ooo_float_store" 6
  ;; Vector load/store
  (define_insn_reservation "generic_ooo_vec_load" 6
    (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr"))
+   (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr,rdfrm"))
    "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
Hmm, I don't think "rdfrm" is really a vector load.  It's really a read 
of some bits in the fpcsr which elsewhere is handled as type fmove.  I'd 
actually suggest fixing vector.md to use fmove on the appropriate insn, 
then dropping rdfrm entirely.

Sounds good!



  (define_insn_reservation "generic_xfer" 3
    (and (eq_attr "tune" "generic")
-   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp"))
+   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo"))
    "alu")

cbo is probably closer to a load/store than it is a transfer operation.

That makes sense. I wasn't sure where exactly to put it since we have 
two separate insn reservations for load and store and from my 
understanding, the same type cannot be in two separate insn 
reservations. Would a new insn reservation like

(define_insn_reservation "generic_load_store" 2 ...) work?


  (define_insn_reservation "generic_branch" 1
    (and (eq_attr "tune" "generic")
-   (eq_attr "type" "branch,jump,call,jalr"))
+   (eq_attr "type" "branch,jump,call,jalr,ret,trap,pushpop"))
+  "alu")
pushpop are a mix of some pure memory operations and some mixed memory + 
branch.


However, from a scheduling standpoint the branch isn't particularly 
interesting.  So I'd have pushpop as a load/store.



Same as above

Edwin

[PATCH 3/3][RFC] RISC-V: Enable assert for insn_has_dfa_reservation

[Edwin Lu]

Enables assert that every typed instruction is associated with a
dfa reservation

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ab0f95e5fe9..3adeb415bec 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8048,9 +8048,7 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
 
   /* If we ever encounter an insn without an insn reservation, trip
  an assert so we can find and fix this problem.  */
-#if 0
   gcc_assert (insn_has_dfa_reservation_p (insn));
-#endif
 
   return more - 1;
 }
-- 
2.34.1

[PATCH 2/3][RFC] RISC-V: Add vector related reservations

[Edwin Lu]

This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. The vector pipelines are
necessary to avoid an ICE from the assert

gcc/ChangeLog:

* config/riscv/generic-ooo.md: syntax
* config/riscv/generic.md (pipe0): new reservation
(generic_vec_load): ditto
(generic_vec_store): ditto
(generic_vec_loadstore_seg): ditto
(generic_generic_vec_alu): ditto
(generic_vec_fcmp): ditto
(generic_vec_imul): ditto
(generic_vec_fadd): ditto
(generic_vec_fmul): ditto
(generic_crypto): ditto
(generic_vec_perm): ditto
(generic_vec_reduction): ditto
(generic_vec_ordered_reduction): ditto
(generic_vec_idiv): ditto
(generic_vec_float_divsqrt): ditto
(generic_vec_mask): ditto
(generic_vec_vesetvl): ditto
(generic_vec_setrm): ditto
(generic_vec_readlen): ditto
* config/riscv/sifive-7.md (sifive_7): new reservation
(sifive_7_vec_load): ditto
(sifive_7_vec_store): ditto
(sifive_7_vec_loadstore_seg): ditto
(sifive_7_sifive_7_vec_alu): ditto
(sifive_7_vec_fcmp): ditto
(sifive_7_vec_imul): ditto
(sifive_7_vec_fadd): ditto
(sifive_7_vec_fmul): ditto
(sifive_7_crypto): ditto
(sifive_7_vec_perm): ditto
(sifive_7_vec_reduction): ditto
(sifive_7_vec_ordered_reduction): ditto
(sifive_7_vec_idiv): ditto
(sifive_7_vec_float_divsqrt): ditto
(sifive_7_vec_mask): ditto
(sifive_7_vec_vesetvl): ditto
(sifive_7_vec_setrm): ditto
(sifive_7_vec_readlen): ditto

Signed-off-by: Edwin Lu 
Co-authored-by: Robin Dapp 
---
 gcc/config/riscv/generic-ooo.md |  19 ++---
 gcc/config/riscv/generic.md | 118 
 gcc/config/riscv/sifive-7.md| 118 
 3 files changed, 242 insertions(+), 13 deletions(-)

diff --git a/gcc/config/riscv/generic-ooo.md b/gcc/config/riscv/generic-ooo.md
index de93245f965..18b606bb981 100644
--- a/gcc/config/riscv/generic-ooo.md
+++ b/gcc/config/riscv/generic-ooo.md
@@ -106,16 +106,14 @@ (define_insn_reservation "generic_ooo_vec_store" 6
 ;; Vector segment loads/stores.
 (define_insn_reservation "generic_ooo_vec_loadstore_seg" 10
   (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,\
-   vssegte,vssegts,vssegtux,vssegtox"))
+   (eq_attr "type" 
"vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,vssegte,vssegts,vssegtux,vssegtox"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 
 ;; Generic integer instructions.
 (define_insn_reservation "generic_ooo_alu" 1
   (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "unknown,const,arith,shift,slt,multi,auipc,nop,logical,\
-   
move,bitmanip,rotate,min,max,minu,maxu,clz,ctz,atomic,condmove,cbo,mvpair,zicond"))
+   (eq_attr "type" 
"unknown,const,arith,shift,slt,multi,auipc,nop,logical,move,bitmanip,rotate,min,max,minu,maxu,clz,ctz,atomic,condmove,cbo,mvpair,zicond"))
   "generic_ooo_issue,generic_ooo_ixu_alu")
 
 (define_insn_reservation "generic_ooo_sfb_alu" 2
@@ -193,16 +191,13 @@ (define_insn_reservation "generic_ooo_popcount" 2
 ;; Regular vector operations and integer comparisons.
 (define_insn_reservation "generic_ooo_vec_alu" 3
   (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,\
-   vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
+   (eq_attr "type" 
"vialu,viwalu,vext,vicalu,vshift,vnshift,viminmax,vicmp,vimov,vsalu,vaalu,vsshift,vnclip,vmov,vfmov,vector"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector float comparison, conversion etc.
 (define_insn_reservation "generic_ooo_vec_fcmp" 3
   (and (eq_attr "tune" "generic_ooo")
-   (eq_attr "type" "vfrecp,vfminmax,vfcmp,vfsgnj,vfclass,vfcvtitof,\
-   vfcvtftoi,vfwcvtitof,vfwcvtftoi,vfwcvtftof,vfncvtitof,\
-   vfncvtftoi,vfncvtftof"))
+   (eq_attr "type" 
"vfrecp,vfminmax,vfcmp,vfsgnj,vfclass,vfcvtitof,vfcvtftoi,vfwcvtitof,vfwcvtftoi,vfwcvtftof,vfncvtitof,vfncvtftoi,vfncvtftof"))
   "generic_ooo_vxu_issue,generic_ooo_vxu_alu")
 
 ;; Vector integer multiplication.
@@ -232,8 +227,7 @@ (define_insn_reservation "generic_ooo_crypto" 4
 ;; Vector permute.
 (define_insn_reservation "generic_ooo_perm" 3
   (and (eq_attr "tune" "generic_ooo")
-   (eq_at