public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@sifive.com>
To: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	palmer <palmer@dabbelt.com>,  "kito.cheng" <kito.cheng@gmail.com>,
	jeffreyalaw <jeffreyalaw@gmail.com>,
	 Robin Dapp <rdapp.gcc@gmail.com>, "pan2.li" <pan2.li@intel.com>
Subject: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V
Date: Tue, 30 May 2023 14:51:46 +0800	[thread overview]
Message-ID: <CALLt3Tj=ifS=PXS+XDKjKxdFwZx3rrrzbVKDyLe8cPW8xarDTA@mail.gmail.com> (raw)
In-Reply-To: <9FD4D8ADEB8D8E67+20230530143233786291327@rivai.ai>

> >> /* Return true if MODE is true VLS mode.  */
> >> bool
> >> vls_mode_p (machine_mode mode)
> >> {
> >>   switch (mode)
> >>     {
> >>     case E_V4SImode:
> >>     case E_V2DImode:
> >>     case E_V8HImode:
> >>     case E_V16QImode:
> >>       return true;
> >>     default:
> >>       return false;
> >>     }
> >> }
>
> To be consistent, you should put these into riscv-vector-switching.def.
> It can make the function easier extend,change it like this:
> change name into riscv_v_ext_vls_mode_p
>
> bool
> riscv_v_ext_vls_mode_p (machine_mode mode)
> {
> #define VLS_ENTRY(MODE, REQUIREMENT, ...)                                          \
>   case MODE##mode:                                                             \
>     return REQUIREMENT;
>   switch (mode)
>     {
> #include "riscv-vector-switch.def"
>     default:
>       return false;
>     }
>   return false;
> }
>
> Then in riscv-vector-switch.def
> VLS_ENTRY (V4SI...
> VLS_ENTRY (V2DI..
> ...
> In the future, we extend more VLS modes in riscv-vector-switch.def

Good point, we should make this more consistent :)

> >>(define_insn_and_split "<optab><mode>3"
> >>  [(set (match_operand:VLS 0 "register_operand" "=vr")
> >> (any_int_binop_no_shift:VLS
> >>  (match_operand:VLS 1 "register_operand" "vr")
> >>  (match_operand:VLS 2 "register_operand" "vr")))]
> >>  "TARGET_VECTOR"
> >>  "#"
> >>  "reload_completed"
> >>  [(const_int 0)]
> >>+{
> >>  machine_mode vla_mode = riscv_vector::minimal_vla_mode (<MODE>mode);
> >>  riscv_vector::vls_insn_expander (
> >>    code_for_pred (<CODE>, vla_mode), riscv_vector::RVV_BINOP,
> >>    operands, <MODE>mode, vla_mode);
> >>  DONE;
> >>})
>
> This pattern can work for current VLS modes so far since they are within 0~31, if we add more VLSmodes such as V32QImode, V64QImode,
> it can't work . I am ok with this, but I should remind you early.

Yeah, I Know the problem, my thought is we will have another set of
VLS patterns for those NUNITS >= 32, and require one clobber with GPR.

> Add tests with -march=rv64gcv_zvl256b to see whether your testcase can generate LMUL = mf2 vsetvli
>
> and -march=rv64gcv_zvl2048 make sure your testcase will not go into the VLS modes (2048 * 1 / 8 > 128)

I guess I should make a loop to test those combinations instead of
spearted file but with different options.

>
>
> For VSETVL part, I didn't see you define attribute sew/vlmul ...ratio for VLS modes.
>
> I wonder how these VLS modes emit correct VSETVL?

That's the magic I made here, I split the pattern after RA, but before
vsetvli, and convert all operands to VLA mode and use VLA pattern, so
that we don't need to modify any line of vsetvli stuff.

  reply	other threads:[~2023-05-30  6:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30  6:06 Kito Cheng
2023-05-30  6:32 ` juzhe.zhong
2023-05-30  6:51   ` Kito Cheng [this message]
2023-05-30  6:59     ` juzhe.zhong
2023-05-30  7:13 ` Richard Biener
2023-05-30  7:45   ` juzhe.zhong
2023-05-30  9:05     ` Robin Dapp
2023-05-30  9:11       ` Kito Cheng
2023-05-30  9:16         ` Kito Cheng
2023-05-30  9:16       ` juzhe.zhong
2023-05-30  9:29         ` Richard Biener
2023-05-30  9:37           ` juzhe.zhong
2023-05-30  9:44           ` juzhe.zhong
2023-05-30 15:45             ` Kito Cheng
2023-05-30 23:19               ` 钟居哲
     [not found]             ` <DC99791C4B2B4D40+106F137E-2B0D-4732-A7C5-8EE0242F9F5A@rivai.ai>
2023-06-12 23:34               ` Jeff Law
     [not found]               ` <529320C359BE5467+690CDE73-D54E-48E2-81C4-B742060D7F28@rivai.ai>
2023-06-13 16:10                 ` Jeff Law
2023-05-30  7:27 ` Robin Dapp
2023-05-30  7:40   ` juzhe.zhong

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='CALLt3Tj=ifS=PXS+XDKjKxdFwZx3rrrzbVKDyLe8cPW8xarDTA@mail.gmail.com' \
    --to=kito.cheng@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=pan2.li@intel.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).