From: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
To: jakub <jakub@redhat.com>
Cc: jeffreyalaw <jeffreyalaw@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
kito.cheng <kito.cheng@gmail.com>, palmer <palmer@dabbelt.com>,
richard.sandiford <richard.sandiford@arm.com>,
rguenther <rguenther@suse.de>,
"vmakarov@redhat.com" <vmakarov@redhat.com>
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit
Date: Tue, 11 Apr 2023 18:25:58 +0800 [thread overview]
Message-ID: <69DA441BB95234D8+20230411182558249859230@rivai.ai> (raw)
In-Reply-To: <ZDUyYjRdhzcCwOcK@tucnak>
[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]
Explicit sets multiple VNx1SImode with multiple dest operand and let RA to assign them with continguous regsiters
will make RTL patterns in RVV hard to maintain.
Assume we have a new pattern flag to tell RA assign continguous registers for multiple dest operand, and RA can handle this:
in RVV, we have NF = 2 ~ 8
Then we need to define RTL pattern for "vlseg" as follows:
NF = 2:
define_insn "vlseg2"
[(parallel_with_continguous_reg
(set dest operand 0)
(set dest operand 1)...])
NF = 3:
define_insn "vlseg3"
[(parallel_with_continguous_reg
(set dest operand 0)
(set dest operand 1)
(set dest operand 2)...])
...
NF = 7:
define_insn "vlseg7"
[(parallel_with_continguous_reg
(set dest operand 0)
(set dest operand 1)
(set dest operand 2)
(set dest operand 2)
(set dest operand 2)...])
juzhe.zhong@rivai.ai
From: Jakub Jelinek
Date: 2023-04-11 18:11
To: juzhe.zhong@rivai.ai
CC: jeffreyalaw; gcc-patches; kito.cheng; palmer; richard.sandiford; rguenther; Vladimir Makarov
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zhong@rivai.ai wrote:
> I am not sure whether aggregate type without a tuple mode can work for us.
> Here is the example:
>
> We already had a vector type "vint8mf8_t", the corresponding mode is VNx1SImode.
>
> Now we have an intrinsic as following:
> vint8mf8x2_t test_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl) {
> return __riscv_vlseg2e8_v_i8mf8(base, vl);
> }
>
> This intrinsic is suppose generate a "vlseg2e8.v" instructions and dest operand of the intrinsic should be 2 continguous registers.
>
> Another intrinsic:
> vint8mf8x3_t test_vlseg3e8_v_i8mf8(const int8_t *base, size_t vl) {
> return __riscv_vlseg3e8_v_i8mf8(base, vl);
> }
>
> This intrinsic is suppose generate a "vlseg3e8.v" instructions and dest operand of the intrinsic should be 3 continguous registers.
>
> Now, my plan is to build_array_type for both "vint8mf8x2_t" and "vint8mf8x3_t" and make their TYPE_MODE is "VNx2x1SI" and "VNx3x1SI" corresponding like ARM SVE.
> Then define the RTL pattern which has dest operand is a register_operand with mode "VNx2x1SI" and "VNx3x1SI". Then we can do the codegen.
Another possibility would be just make it explicit in the RTL that it sets 3
VNx1SI mode REGs rather than one, as long as there is some way to tell RA
that they need to be consecutive. CCing Vlad on that.
Jakub
next prev parent reply other threads:[~2023-04-11 10:26 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 14:48 juzhe.zhong
2023-04-10 14:54 ` Jeff Law
2023-04-10 15:02 ` juzhe.zhong
2023-04-10 15:14 ` juzhe.zhong
2023-04-11 9:16 ` Jakub Jelinek
2023-04-11 9:46 ` juzhe.zhong
2023-04-11 10:11 ` Jakub Jelinek
2023-04-11 10:25 ` juzhe.zhong [this message]
2023-04-11 10:52 ` Jakub Jelinek
2023-04-11 9:46 ` Richard Sandiford
2023-04-11 9:59 ` Jakub Jelinek
2023-04-11 10:11 ` juzhe.zhong
2023-04-11 10:05 ` Richard Earnshaw
2023-04-11 10:15 ` Richard Sandiford
2023-04-11 10:59 ` Richard Biener
2023-04-11 11:11 ` Richard Sandiford
2023-04-11 11:19 ` juzhe.zhong
2023-04-11 13:50 ` Kito Cheng
2023-04-12 7:53 ` Richard Biener
2023-04-12 9:06 ` Kito Cheng
2023-04-12 9:21 ` Richard Biener
2023-04-12 9:31 ` Kito Cheng
2023-04-12 23:22 ` 钟居哲
2023-04-13 13:06 ` Richard Sandiford
2023-04-13 14:02 ` Richard Biener
2023-04-15 2:58 ` Hans-Peter Nilsson
2023-04-17 6:38 ` Richard Biener
2023-04-20 5:37 ` Hans-Peter Nilsson
2023-05-05 1:43 ` Li, Pan2
2023-05-05 6:25 ` Richard Biener
2023-05-06 1:10 ` Li, Pan2
2023-05-06 1:53 ` Kito Cheng
2023-05-06 1:59 ` juzhe.zhong
2023-05-06 2:12 ` Li, Pan2
2023-05-06 2:18 ` Kito Cheng
2023-05-06 2:20 ` Li, Pan2
2023-05-06 2:48 ` Li, Pan2
2023-05-07 1:55 ` Li, Pan2
2023-05-07 15:23 ` Jeff Law
2023-05-08 1:07 ` Li, Pan2
2023-05-08 6:29 ` Richard Biener
2023-05-08 6:41 ` Li, Pan2
2023-05-08 6:59 ` Li, Pan2
2023-05-08 7:37 ` Richard Biener
2023-05-08 8:05 ` Li, Pan2
2023-05-09 6:13 ` Li, Pan2
2023-05-09 7:04 ` Richard Biener
2023-05-09 10:16 ` Richard Sandiford
2023-05-09 10:26 ` Richard Biener
2023-05-09 11:50 ` Li, Pan2
2023-05-10 5:09 ` Li, Pan2
2023-05-10 7:22 ` Li, Pan2
2023-05-08 1:35 ` Li, Pan2
2023-04-10 15:18 ` Jakub Jelinek
2023-04-10 15:22 ` juzhe.zhong
2023-04-10 20:42 ` Jeff Law
2023-04-10 23:03 ` juzhe.zhong
2023-04-11 1:36 ` juzhe.zhong
[not found] ` <20230410232205400970205@rivai.ai>
2023-04-10 15:33 ` juzhe.zhong
2023-04-10 20:39 ` Jeff Law
2023-04-10 20:36 ` Jeff Law
2023-04-10 22:53 ` juzhe.zhong
2023-04-10 15:10 ` Jakub Jelinek
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=69DA441BB95234D8+20230411182558249859230@rivai.ai \
--to=juzhe.zhong@rivai.ai \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=kito.cheng@gmail.com \
--cc=palmer@dabbelt.com \
--cc=rguenther@suse.de \
--cc=richard.sandiford@arm.com \
--cc=vmakarov@redhat.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).