public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: pan2.li@intel.com
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai, kito.cheng@sifive.com, pan2.li@intel.com,
	rguenther@suse.de, yanzhang.wang@intel.com
Subject: [PATCH] [RISC-V]: Bugfix for RVV vbool*_t vn_reference_equal.
Date: Wed, 29 Mar 2023 15:52:22 +0800	[thread overview]
Message-ID: <20230329075222.2888608-1-pan2.li@intel.com> (raw)

From: Pan Li <pan2.li@intel.com>

In most architecture the precision_size of vbool*_t types are caculated
like as the multiple of the type size.  For example:
precision_size = type_size * 8 (aka, bit count per bytes).

Unfortunately, some architecture like RISC-V will adjust the precision_size
for the vbool*_t in order to align the ISA. For example as below.
type_size      = [1, 1, 1, 1,  2,  4,  8]
precision_size = [1, 2, 4, 8, 16, 32, 64]

Then the precision_size of RISC-V vbool*_t will not be the multiple of the
type_size. This PATCH try to enrich this case when comparing the vn_reference.

Given we have the below code:
void test_vbool8_then_vbool16(int8_t * restrict in, int8_t * restrict out) {
    vbool8_t v1 = *(vbool8_t*)in;
    vbool16_t v2 = *(vbool16_t*)in;

    *(vbool8_t*)(out + 100) = v1;
    *(vbool16_t*)(out + 200) = v2;
}

Before this PATCH:
csrr    t0,vlenb
slli    t1,t0,1
csrr    a3,vlenb
sub     sp,sp,t1
slli    a4,a3,1
add     a4,a4,sp
addi    a2,a1,100
vsetvli a5,zero,e8,m1,ta,ma
sub     a3,a4,a3
vlm.v   v24,0(a0)
vsm.v   v24,0(a2)
vsm.v   v24,0(a3)
addi    a1,a1,200
csrr    t0,vlenb
vsetvli a4,zero,e8,mf2,ta,ma
slli    t1,t0,1
vlm.v   v24,0(a3)
vsm.v   v24,0(a1)
add     sp,sp,t1
jr      ra

After this PATCH:
addi    a3,a1,100
vsetvli a4,zero,e8,m1,ta,ma
addi    a1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
vsetvli a5,zero,e8,mf2,ta,ma
vlm.v   v24,0(a0)
vsm.v   v24,0(a1)
ret

	PR 109272

gcc/ChangeLog:

	* tree-ssa-sccvn.cc (vn_reference_eq):

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr108185-4.c:
	* gcc.target/riscv/rvv/base/pr108185-5.c:
	* gcc.target/riscv/rvv/base/pr108185-6.c:
---
 .../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/tree-ssa-sccvn.cc                               | 13 +++++++++++++
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-4.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-4.c
index ea3c360d756..e70284fada8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-4.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-4.c
@@ -65,4 +65,4 @@ test_vbool8_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*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 {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]+\)} 15 } } */
+/* { dg-final { scan-assembler-times {vsm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-5.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-5.c
index 9fc659d2402..575a7842cdf 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-5.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-5.c
@@ -65,4 +65,4 @@ test_vbool16_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*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 {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]+\)} 14 } } */
+/* { dg-final { scan-assembler-times {vsm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-6.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-6.c
index 98275e5267d..95a11d37016 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-6.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-6.c
@@ -65,4 +65,4 @@ test_vbool32_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*mf2,\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 {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]+\)} 13 } } */
+/* { dg-final { scan-assembler-times {vsm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 6b8d38b270c..c6dfa8fd9a3 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -799,6 +799,19 @@ vn_reference_eq (const_vn_reference_t const vr1, const_vn_reference_t const vr2)
 	   && (TYPE_PRECISION (vr2->type)
 	       != TREE_INT_CST_LOW (TYPE_SIZE (vr2->type))))
     return false;
+  else if (VECTOR_BOOLEAN_TYPE_P (vr1->type)
+	   && VECTOR_BOOLEAN_TYPE_P (vr2->type)
+	   && expressions_equal_p (TYPE_SIZE (vr1->type),
+				   TYPE_SIZE (vr2->type))
+	   && TYPE_PRECISION (vr1->type) != TYPE_PRECISION (vr2->type))
+    /* For the vbool*_t types in most architectures, the precision size is
+       caculated as the multiple of the type size.  For example,
+       precision_size = type_size * 8 (aka, bit count per bytes).
+       Unfortunately, some architecture like RISC-V will adjust the
+       precision for the vbool*_t in order to align the ISA and the
+       precision will not be the multiple of the type size.  Thus, enrich
+       the type comparation for this case here.  */
+    return false;
 
   i = 0;
   j = 0;
-- 
2.34.1


             reply	other threads:[~2023-03-29  7:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29  7:52 pan2.li [this message]
2023-03-29  8:10 ` Richard Biener
2023-03-29  8:56   ` Li, Pan2
2023-03-29  8:53 ` [PATCH v2] RISC-V: " pan2.li
2023-03-29  9:24   ` Richard Biener
2023-03-29  9:35     ` juzhe.zhong
2023-03-29 10:38       ` Li, Pan2
2023-04-20 13:56         ` Li, Pan2
2023-04-24 11:13           ` Li, Pan2
2023-04-25 14:05             ` Kito Cheng
2023-04-25 14:10               ` Li, Pan2
2023-04-25 14:31                 ` Li, Pan2
     [not found] <Message-Id: <20230329075222.2888608-1-pan2.li@intel.com>
2023-04-25 14:29 ` [PATCH v3] " pan2.li
2023-04-26  3:29   ` Kito Cheng
2023-04-26  3:33     ` Li, Pan2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230329075222.2888608-1-pan2.li@intel.com \
    --to=pan2.li@intel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@sifive.com \
    --cc=rguenther@suse.de \
    --cc=yanzhang.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).