From: "Lehua Ding" <lehua.ding@rivai.ai>
To: "Jeff Law" <jeffreyalaw@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Cc: "juzhe.zhong" <juzhe.zhong@rivai.ai>,
"kito.cheng" <kito.cheng@gmail.com>,
"rdapp.gcc" <rdapp.gcc@gmail.com>, palmer <palmer@rivosinc.com>
Subject: Re: [PATCH] RISC-V: Revert the convert from vmv.s.x to vmv.v.i
Date: Sat, 12 Aug 2023 12:09:17 +0800 [thread overview]
Message-ID: <D1724A6457B16F9A+tencent_2A89EA9576E33929EDEE3EA4AF05679A9009@qq.com> (raw)
In-Reply-To: <dde62e7c-7493-2a57-43e3-468db6a47877@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7132 bytes --]
> If we encounter a uarch where the other sequence is better, then I think
> we can do something like query costs or the like and select between the
> approaches -- but no need to do that now.
> So OK for the trunk.
Thanks, patch will be committed soon.
------------------ Original ------------------
From: "Jeff Law" <gcc-patches@gcc.gnu.org>;
Date: Sat, Aug 12, 2023 07:02 AM
To: "Lehua Ding"<lehua.ding@rivai.ai>;"gcc-patches"<gcc-patches@gcc.gnu.org>;
Cc: "juzhe.zhong"<juzhe.zhong@rivai.ai>;"kito.cheng"<kito.cheng@gmail.com>;"rdapp.gcc"<rdapp.gcc@gmail.com>;"palmer"<palmer@rivosinc.com>;
Subject: Re: [PATCH] RISC-V: Revert the convert from vmv.s.x to vmv.v.i
On 8/11/23 03:01, Lehua Ding wrote:
> Hi,
>
> This patch revert the convert from vmv.s.x to vmv.v.i and add new pattern
> optimize the special case when the scalar operand is zero.
>
> Currently, the broadcast pattern where the scalar operand is a imm
> will be converted to vmv.v.i from vmv.s.x and the mask operand will be
> converted from 00..01 to 11..11. There are some advantages and
> disadvantages before and after the conversion after discussing
> with Juzhe offline and we chose not to do this transform.
>
> Before:
>
> Advantages: The vsetvli info required by vmv.s.x has better compatibility since
> vmv.s.x only required SEW and VLEN be zero or one. That mean there
> is more opportunities to combine with other vsetlv infos in vsetvl pass.
>
> Disadvantages: For non-zero scalar imm, one more `li rd, imm` instruction
> will be needed.
>
> After:
>
> Advantages: No need `li rd, imm` instruction since vmv.v.i support imm operand.
>
> Disadvantages: Like before's advantages. Worse compatibility leads to more
> vsetvl instrunctions need.
>
> Consider the bellow C code and asm after autovec.
> there is an extra insn (vsetivli zero, 1, e32, m1, ta, ma)
> after converted vmv.s.x to vmv.v.i.
>
> ```
> int foo1(int* restrict a, int* restrict b, int *restrict c, int n) {
> int sum = 0;
> for (int i = 0; i < n; i++)
> sum += a[i] * b[i];
>
> return sum;
> }
> ```
>
> asm (Before):
>
> ```
> foo1:
> ble a3,zero,.L7
> vsetvli a2,zero,e32,m1,ta,ma
> vmv.v.i v1,0
> .L6:
> vsetvli a5,a3,e32,m1,tu,ma
> slli a4,a5,2
> sub a3,a3,a5
> vle32.v v2,0(a0)
> vle32.v v3,0(a1)
> add a0,a0,a4
> add a1,a1,a4
> vmacc.vv v1,v3,v2
> bne a3,zero,.L6
> vsetvli a2,zero,e32,m1,ta,ma
> vmv.s.x v2,zero
> vredsum.vs v1,v1,v2
> vmv.x.s a0,v1
> ret
> .L7:
> li a0,0
> ret
> ```
>
> asm (After):
>
> ```
> foo1:
> ble a3,zero,.L4
> vsetvli a2,zero,e32,m1,ta,ma
> vmv.v.i v1,0
> .L3:
> vsetvli a5,a3,e32,m1,tu,ma
> slli a4,a5,2
> sub a3,a3,a5
> vle32.v v2,0(a0)
> vle32.v v3,0(a1)
> add a0,a0,a4
> add a1,a1,a4
> vmacc.vv v1,v3,v2
> bne a3,zero,.L3
> vsetivli zero,1,e32,m1,ta,ma
> vmv.v.i v2,0
> vsetvli a2,zero,e32,m1,ta,ma
> vredsum.vs v1,v1,v2
> vmv.x.s a0,v1
> ret
> .L4:
> li a0,0
> ret
> ```
>
> Best,
> Lehua
>
> Co-Authored-By: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
>
> gcc/ChangeLog:
>
>* config/riscv/predicates.md (vector_const_0_operand): New.
>* config/riscv/vector.md (*pred_broadcast<mode>_zero): Ditto.
>
> gcc/testsuite/ChangeLog:
>
>* gcc.target/riscv/rvv/base/scalar_move-5.c: Update.
>* gcc.target/riscv/rvv/base/scalar_move-6.c: Ditto.
If we encounter a uarch where the other sequence is better, then I think
we can do something like query costs or the like and select between the
approaches -- but no need to do that now.
So OK for the trunk.
jeff
next prev parent reply other threads:[~2023-08-12 4:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 9:01 Lehua Ding
2023-08-11 15:04 ` Jeff Law
2023-08-11 15:43 ` Lehua Ding
2023-08-11 15:48 ` Jeff Law
2023-08-11 23:02 ` Jeff Law
2023-08-12 4:09 ` Lehua Ding [this message]
2024-02-20 4:15 Alexandre Oliva
2024-02-23 7:37 ` Jeff Law
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=D1724A6457B16F9A+tencent_2A89EA9576E33929EDEE3EA4AF05679A9009@qq.com \
--to=lehua.ding@rivai.ai \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@gmail.com \
--cc=palmer@rivosinc.com \
--cc=rdapp.gcc@gmail.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).