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.zh...@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
