public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@gmail.com>
To: Richard Biener <rguenther@suse.de>
Cc: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
	"richard.sandiford" <richard.sandiford@arm.com>,
	 jeffreyalaw <jeffreyalaw@gmail.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	 palmer <palmer@dabbelt.com>, jakub <jakub@redhat.com>
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit
Date: Wed, 12 Apr 2023 17:06:08 +0800	[thread overview]
Message-ID: <CA+yXCZCVd3c3c6KWf_t5x714T0brKu7Swh3AXXy+Z3PQ+1Y02A@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.77.849.2304120743360.4466@jbgna.fhfr.qr>

Hi Richard:

> > In order to model LMUL in backend, we have to the combination of
> > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
> > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
> > so basically we'll have 7 (LMUL type) * 7 (scalar type) here.
>
> Other archs have load/store-multiple instructions, IIRC those
> are modeled with the appropriate set of operands. Do RVV LMUL
> group inputs/outputs overlap with the non-LMUL grouped registers
> and can they be used as aliases or is this supposed to be
> implemented transparently on the register file level only?

LMUL and non-LMUL (or LMUL=1) modes use the same vector register file.

Reg for LMUL=1/2 : { {v0, v1, ...v31} }
Reg for LMUL=1 : { {v0, v1, ...v31} }
Reg for LMUL=2 : { {v0, v1}, {v2, v3}, ... {v30, v31} } // reg. must
align to multiple of 2.
Reg for LMUL=4 : { {v0, v1, v2, v3}, {v4, v5, v6, v7}, ... {v28, v29,
v30, v31} } // reg. must align to multiple of 4.
..
Reg for 2-tuples of LMUL=1 : { {v0, v1}, {v1, v2}, ... {v29, v30}, {v30, v31} }
Reg for 2-tuples of LMUL=2 : { {v0, v1, v2, v3}, {v2, v3, v4, v5}, ...
{v28, v29, v30, v31}, {v28, v29, v30, v31} } // reg. must align to
multiple of 2.
...

> But yes, implementing this as operations on multi-register
> ops with large modes is probably the only sensible approach.
>
> I don't see how LMUL of 1/2, 1/4 or 1/8 is useful though? Can you
> explain? Is that supposed to virtually increase the number of
> registers? How do you represent r0:1/8:0 vs r0:1/8:3 (the first
> and the third "virtual" register decomposed from r0) in GCC? To
> me the natural way would be a subreg of r0?
>
> Somehow RVV seems to have more knobs than necessary for tuning
> the actual vector register layout (aka N axes but only N-1 dimensions
> thus the axes are

The concept of fractional LMUL is the same as the concept of AArch64's
partial SVE vectors,
so they can only access the lowest part, like SVE's partial vector.

We want to spill/restore the exact size of those modes (1/2, 1/4,
1/8), so adding dedicated modes for those partial vector modes should
be unavoidable IMO.

And even if we use sub-vector, we still need to define those partial
vector types.

  reply	other threads:[~2023-04-12  9:06 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
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 [this message]
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=CA+yXCZCVd3c3c6KWf_t5x714T0brKu7Swh3AXXy+Z3PQ+1Y02A@mail.gmail.com \
    --to=kito.cheng@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=palmer@dabbelt.com \
    --cc=rguenther@suse.de \
    --cc=richard.sandiford@arm.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).