public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: 钟居哲 <juzhe.zhong@rivai.ai>
To: rdapp.gcc <rdapp.gcc@gmail.com>,  gcc-patches <gcc-patches@gcc.gnu.org>
Cc: rdapp.gcc <rdapp.gcc@gmail.com>,
	 kito.cheng <kito.cheng@gmail.com>,
	 kito.cheng <kito.cheng@sifive.com>,
	 "Jeff Law" <jeffreyalaw@gmail.com>
Subject: Re: Re: [PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR
Date: Tue, 5 Dec 2023 22:48:55 +0800	[thread overview]
Message-ID: <016004C9F7197EBC+2023120522485442058610@rivai.ai> (raw)
In-Reply-To: <a34b2a6a-05fc-4713-8f2f-33bde61e407a@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

Hi, Robin.

>> Wouldn't maybe_gt on the mode precision already suffice?  I.e. do we need
>> the ordered_p and the exclusion for masks?  (Sure, masks never exceed
>> one register anyway.)

Currently, I don't see mask mode cause assertion ICE.

>> Couldn't we exclude all VLS modes that exceed our minimum vector size?
>> Or will this exclude too many?

I think the VLS modes are excluded exactly meet we expected.
For example, when zvl128b, LMUL = 1.
We allow allow VLS modes <= 128bit, exclude VLS modes > 128bits.
We have the same behavior as ARM SVE.

>> And could we move this to vls_mode_valid_p?  We already do similar
>> checks for fixed_vlmax there.
This check is already in the vls_mode_valid_p.



juzhe.zhong@rivai.ai
 
From: Robin Dapp
Date: 2023-12-05 22:34
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Block VLSmodes according to TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR
Yes, makes sense. Just one clarifying question.
 
> +    {
> +      if (GET_MODE_CLASS (vls_mode) != MODE_VECTOR_BOOL
> +   && !ordered_p (TARGET_MAX_LMUL * BITS_PER_RISCV_VECTOR,
> + GET_MODE_PRECISION (vls_mode)))
> + /* We enable VLS modes which are aligned with TARGET_MAX_LMUL and
> +    BITS_PER_RISCV_VECTOR.
> +
> +    e.g. When TARGET_MAX_LMUL = 1 and BITS_PER_RISCV_VECTOR = (128,128).
> +    We enable VLS modes have fixed size <= 128bit.  Since ordered_p is
> +    false between VLA modes with size = (128, 128) bits and VLS mode
> +    with size = 128 bits, we will end up with multiple ICEs in
> +    middle-end generic codes.  */
> + return false;
> +      return true;
> +    }
 
Wouldn't maybe_gt on the mode precision already suffice?  I.e. do we need
the ordered_p and the exclusion for masks?  (Sure, masks never exceed
one register anyway.)
Couldn't we exclude all VLS modes that exceed our minimum vector size?
Or will this exclude too many?
 
And could we move this to vls_mode_valid_p?  We already do similar
checks for fixed_vlmax there.
 
Regards
Robin
 
 

  reply	other threads:[~2023-12-05 14:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 12:57 Juzhe-Zhong
2023-12-05 14:34 ` Robin Dapp
2023-12-05 14:48   ` 钟居哲 [this message]
2023-12-05 14:57     ` Robin Dapp
2023-12-20 17:44 ` Palmer Dabbelt
2023-12-20 22:42   ` 钟居哲

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=016004C9F7197EBC+2023120522485442058610@rivai.ai \
    --to=juzhe.zhong@rivai.ai \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.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).