public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@gmail.com>
To: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: Robin Dapp <rdapp.gcc@gmail.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	 palmer <palmer@dabbelt.com>, jeffreyalaw <jeffreyalaw@gmail.com>
Subject: Re: Re: [PATCH 2/3 V2] RISC-V: Enable basic auto-vectorization for RVV
Date: Thu, 20 Apr 2023 18:37:28 +0800	[thread overview]
Message-ID: <CA+yXCZB5gNqss7UCjeyZgKjgi5vY4YTMKkbxaAE0XBMOHLcnMQ@mail.gmail.com> (raw)
In-Reply-To: <725B830310EE18AA+2023042017471261876972@rivai.ai>

Hi Robin:

Share with you more context that I've discussed with Ju-Zhe, and look
for comments from you :)

There is 3 different auto vectorization flavor:
- VLA
- VLS fixed-vlmax (Name TBD)
- (Traditional) VLS

I think I don't need to explain too much on VLA.
So let we focus on second and third:

VLS fixed-vlmax, that's something like -mriscv-vector-bits= or
-msve-vector-bits, assume VLEN is a static length, and evaluate
scalable vector mode as fixed length vector mode (e.g. evaluate (8x +
8) byte to 16 byte), so that stack allocation could be done by static
instead computed by vlenb register, and vlvmax could be evaluate to a
static value too, but the code generated by this mode is not portable,
when you compile with -mriscv-vector-bits=128, then the code can't run
on machine which VLEN is not exactly equal to 128.

(Traditional) VLS, vectorized to something like int32x4_t, stack
allocation can be determined in static too since the size is fixed,
but size of vector register size is still a poly_int16 value (scalable
vector), not evaluated to fixed length vector like VLS fixed-vlmax
mode, this mode could be useful to handle those loop can't vectorized
by VLA mode, or used by SLP vectorizor, and this mode is more portable
than VLS fixed-vlmax mode since it only require VLEN is larger than
specific length, rather than require must equal to specific length.





On Thu, Apr 20, 2023 at 5:47 PM juzhe.zhong@rivai.ai
<juzhe.zhong@rivai.ai> wrote:
>
> Ahhh. These compile options are not finalized.
> I just ask kito provide me some compile option that I can specify LMUL && auto-vectorization mode && vector-length (scalable or fixed-length)
> in order to have chances test auto-vectorizaiton fully for example: fully testing LMUL = 1/2/4/8 auto-vectorization (You can see the codes in rvv.exp).
> Then, he let me add --param options.
>
> I can change compile option as you suggested.
>
> Thanks.
>
>
> juzhe.zhong@rivai.ai
>
> From: Robin Dapp
> Date: 2023-04-20 17:42
> To: juzhe.zhong@rivai.ai; kito.cheng
> CC: gcc-patches; palmer; jeffreyalaw
> Subject: Re: [PATCH 2/3 V2] RISC-V: Enable basic auto-vectorization for RVV
> > Can you give more comments about Robin's opinion that he want to change into
> > "fixed" vs "varying" or "fixed vector size" vs "dynamic vector size" ?
>
> It's not necessary to decide on this now as --params are not supposed
> to be stable and can be changed quickly.  I was just curious if this had
> already been discussed or finalized elsewhere.
>
> Regards
> Robin
>

  reply	other threads:[~2023-04-20 10:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19 16:42 [PATCH 0/3 V2] RISC-V: Basic enable RVV auto-vectorizaiton juzhe.zhong
2023-04-19 16:42 ` [PATCH 1/3 V2] RISC-V: Add auto-vectorization compile option for RVV juzhe.zhong
2023-04-26  3:07   ` Jeff Law
2023-04-19 16:42 ` [PATCH 2/3 V2] RISC-V: Enable basic auto-vectorization " juzhe.zhong
2023-04-20  2:26   ` Kito Cheng
2023-04-20  2:55     ` juzhe.zhong
2023-04-20  2:59       ` Kito Cheng
2023-04-20  8:58     ` Robin Dapp
2023-04-20  9:07       ` juzhe.zhong
2023-04-20  9:31         ` Kito Cheng
2023-04-20  9:34           ` juzhe.zhong
2023-04-20  9:42             ` Robin Dapp
2023-04-20  9:47               ` juzhe.zhong
2023-04-20 10:37                 ` Kito Cheng [this message]
2023-04-20  9:30       ` juzhe.zhong
2023-04-19 16:42 ` [PATCH 3/3 V2] RISC-V: Add sanity testcases for RVV auto-vectorization juzhe.zhong
2023-04-20  6:03   ` Kito Cheng

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+yXCZB5gNqss7UCjeyZgKjgi5vY4YTMKkbxaAE0XBMOHLcnMQ@mail.gmail.com \
    --to=kito.cheng@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=palmer@dabbelt.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).