* [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
@ 2023-11-08 13:27 Lehua Ding
[not found] ` <273AD3EA5CCC79C0+09716C0F-7900-43BD-A3B8-EFE0D3FF3249@rivai.ai>
0 siblings, 1 reply; 4+ messages in thread
From: Lehua Ding @ 2023-11-08 13:27 UTC (permalink / raw)
To: gcc-patches
Cc: juzhe.zhong, kito.cheng, rdapp.gcc, palmer, jeffreyalaw, lehua.ding
Hi,
This patch try to combine bellow two insns and then further remove
unnecessary sign_extend operations. This optimization is borrowed
from LLVM (https://godbolt.org/z/4f6v56xej):
(set (reg:DI 134 [ _1 ])
(unspec:DI [
(const_int 19 [0x13])
(const_int 8 [0x8])
(const_int 5 [0x5])
(const_int 2 [0x2]) repeated x2
] UNSPEC_VSETVL))
(set (reg/v:DI 135 [ <retval> ])
(sign_extend:DI (subreg:SI (reg:DI 134 [ _1 ]) 0)))
The reason we can remove signe_extend is because currently the vl value
returned by the vsetvl instruction ranges from 0 to 65536 (uint16_t), and
bits 17 to 63 (including 31) are always 0, so there is no change after
sign_extend. Note that for HI and QI modes we cannot do this.
Of course, if the range of instructions returned by vsetvl later expands
to 32bits, then this combine pattern needs to be removed. But that could be
a long time from now.
gcc/ChangeLog:
* config/riscv/vector.md (*vsetvldi_no_side_effects_si_extend):
New combine pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vsetvl_int.c: New test.
---
gcc/config/riscv/vector.md | 41 +++++++++++++++++++
.../gcc.target/riscv/rvv/vsetvl/vsetvl_int.c | 31 ++++++++++++++
2 files changed, 72 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_int.c
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index e23f64938b7..d1499d330ff 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -1604,6 +1604,47 @@
[(set_attr "type" "vsetvl")
(set_attr "mode" "SI")])
+;; This pattern use to combine bellow two insns and then further remove
+;; unnecessary sign_extend operations:
+;; (set (reg:DI 134 [ _1 ])
+;; (unspec:DI [
+;; (const_int 19 [0x13])
+;; (const_int 8 [0x8])
+;; (const_int 5 [0x5])
+;; (const_int 2 [0x2]) repeated x2
+;; ] UNSPEC_VSETVL))
+;; (set (reg/v:DI 135 [ <retval> ])
+;; (sign_extend:DI (subreg:SI (reg:DI 134 [ _1 ]) 0)))
+;;
+;; The reason we can remove signe_extend is because currently the vl value
+;; returned by the vsetvl instruction ranges from 0 to 65536 (uint16_t), and
+;; bits 17 to 63 (including 31) are always 0, so there is no change after
+;; sign_extend. Note that for HI and QI modes we cannot do this.
+;; Of course, if the range of instructions returned by vsetvl later expands
+;; to 32bits, then this combine pattern needs to be removed. But that could be
+;; a long time from now.
+(define_insn_and_split "*vsetvldi_no_side_effects_si_extend"
+ [(set (match_operand:DI 0 "register_operand")
+ (sign_extend:DI
+ (subreg:SI
+ (unspec:DI [(match_operand:P 1 "csr_operand")
+ (match_operand 2 "const_int_operand")
+ (match_operand 3 "const_int_operand")
+ (match_operand 4 "const_int_operand")
+ (match_operand 5 "const_int_operand")] UNSPEC_VSETVL) 0)))]
+ "TARGET_VECTOR && TARGET_64BIT"
+ "#"
+ "&& 1"
+ [(set (match_dup 0)
+ (unspec:DI [(match_dup 1)
+ (match_dup 2)
+ (match_dup 3)
+ (match_dup 4)
+ (match_dup 5)] UNSPEC_VSETVL))]
+ ""
+ [(set_attr "type" "vsetvl")
+ (set_attr "mode" "SI")])
+
;; RVV machine description matching format
;; (define_insn ""
;; [(set (match_operand:MODE 0)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_int.c b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_int.c
new file mode 100644
index 00000000000..4cdd5877742
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_int.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d" } */
+
+#include "riscv_vector.h"
+
+void bar1 (int32_t a);
+
+int32_t
+foo1 ()
+{
+ int32_t a = __riscv_vsetvl_e8mf8(19);
+ bar1 (a);
+ return a;
+}
+
+void bar2 (uint32_t a);
+
+uint32_t
+foo2 ()
+{
+ uint32_t a = __riscv_vsetvl_e8mf8(19);
+ bar2 (a);
+ return a;
+}
+
+int32_t foo3 ()
+{
+ return __riscv_vsetvl_e8mf8(19);
+}
+
+/* { dg-final { scan-assembler-not {sext\.w} { target { no-opts "-O0" "-g" } } } } */
--
2.36.3
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
[not found] ` <273AD3EA5CCC79C0+09716C0F-7900-43BD-A3B8-EFE0D3FF3249@rivai.ai>
@ 2023-11-08 13:39 ` Lehua Ding
2023-11-09 9:21 ` Kito Cheng
0 siblings, 1 reply; 4+ messages in thread
From: Lehua Ding @ 2023-11-08 13:39 UTC (permalink / raw)
To: juzhe.zhong; +Cc: gcc-patches, kito.cheng, rdapp.gcc, palmer, jeffreyalaw
Committed, thanks Juzhe.
On 2023/11/8 21:29, juzhe.zhong wrote:
> lgtm
> ---- Replied Message ----
> From Lehua Ding<lehua.ding@rivai.ai> <mailto:lehua.ding@rivai.ai>
> Date 11/08/2023 21:27
> To gcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>
> <mailto:gcc-patches@gcc.gnu.org>
> Cc juzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai> <mailto:juzhe.zhong@rivai.ai>,
> kito.cheng@gmail.com<kito.cheng@gmail.com> <mailto:kito.cheng@gmail.com>,
> rdapp.gcc@gmail.com<rdapp.gcc@gmail.com> <mailto:rdapp.gcc@gmail.com>,
> palmer@rivosinc.com<palmer@rivosinc.com> <mailto:palmer@rivosinc.com>,
> jeffreyalaw@gmail.com<jeffreyalaw@gmail.com> <mailto:jeffreyalaw@gmail.com>,
> lehua.ding@rivai.ai<lehua.ding@rivai.ai> <mailto:lehua.ding@rivai.ai>
> Subject [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
>
--
Best,
Lehua (RiVAI)
lehua.ding@rivai.ai
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
2023-11-08 13:39 ` Lehua Ding
@ 2023-11-09 9:21 ` Kito Cheng
2023-11-09 9:54 ` Lehua Ding
0 siblings, 1 reply; 4+ messages in thread
From: Kito Cheng @ 2023-11-09 9:21 UTC (permalink / raw)
To: Lehua Ding; +Cc: juzhe.zhong, gcc-patches, rdapp.gcc, palmer, jeffreyalaw
Should we need a zero-ext version as well?
On Wed, Nov 8, 2023 at 9:39 PM Lehua Ding <lehua.ding@rivai.ai> wrote:
>
> Committed, thanks Juzhe.
>
> On 2023/11/8 21:29, juzhe.zhong wrote:
> > lgtm
> > ---- Replied Message ----
> > From Lehua Ding<lehua.ding@rivai.ai> <mailto:lehua.ding@rivai.ai>
> > Date 11/08/2023 21:27
> > To gcc-patches@gcc.gnu.org<gcc-patches@gcc.gnu.org>
> > <mailto:gcc-patches@gcc.gnu.org>
> > Cc juzhe.zhong@rivai.ai<juzhe.zhong@rivai.ai> <mailto:juzhe.zhong@rivai.ai>,
> > kito.cheng@gmail.com<kito.cheng@gmail.com> <mailto:kito.cheng@gmail.com>,
> > rdapp.gcc@gmail.com<rdapp.gcc@gmail.com> <mailto:rdapp.gcc@gmail.com>,
> > palmer@rivosinc.com<palmer@rivosinc.com> <mailto:palmer@rivosinc.com>,
> > jeffreyalaw@gmail.com<jeffreyalaw@gmail.com> <mailto:jeffreyalaw@gmail.com>,
> > lehua.ding@rivai.ai<lehua.ding@rivai.ai> <mailto:lehua.ding@rivai.ai>
> > Subject [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
> >
>
> --
> Best,
> Lehua (RiVAI)
> lehua.ding@rivai.ai
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl
2023-11-09 9:21 ` Kito Cheng
@ 2023-11-09 9:54 ` Lehua Ding
0 siblings, 0 replies; 4+ messages in thread
From: Lehua Ding @ 2023-11-09 9:54 UTC (permalink / raw)
To: Kito Cheng; +Cc: juzhe.zhong, gcc-patches, rdapp.gcc, palmer, jeffreyalaw
Hi Kito,
On 2023/11/9 17:21, Kito Cheng wrote:
> Should we need a zero-ext version as well?
It's not needed at the moment, since the sign_extend is currently used
for both int32_t and uint32_t. I can't find a case where zero_extend
would occur.
--
Best,
Lehua (RiVAI)
lehua.ding@rivai.ai
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-09 9:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-08 13:27 [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl Lehua Ding
[not found] ` <273AD3EA5CCC79C0+09716C0F-7900-43BD-A3B8-EFE0D3FF3249@rivai.ai>
2023-11-08 13:39 ` Lehua Ding
2023-11-09 9:21 ` Kito Cheng
2023-11-09 9:54 ` Lehua Ding
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).