> Am 23.12.2024 um 10:57 schrieb Robin Dapp :
>
>
>>
>> I don't quite understand - you are checking loop_vinfo->vector_mode, but
>> how can you be sure no chosen vector uses a !VECTOR_MODE_P? It seems
>> fragile to rely on (it might work in this case), instead when any
>> !VECTOR_MODE_P nee
> I don't quite understand - you are checking loop_vinfo->vector_mode, but
> how can you be sure no chosen vector uses a !VECTOR_MODE_P? It seems
> fragile to rely on (it might work in this case), instead when any
> !VECTOR_MODE_P needs a 'len' we should reject it - so why does this
> not happen h
On Thu, 19 Dec 2024, Robin Dapp wrote:
> > I wonder if LOOP_VINFO_LENS is really empty here? If not, who recorded
> > the len and why did that not disable partial vectors?
>
> It's not empty. vectorizable_operation fills it for a vectype of vector short
> (4). Before (in vector_type_mode), we
> I wonder if LOOP_VINFO_LENS is really empty here? If not, who recorded
> the len and why did that not disable partial vectors?
It's not empty. vectorizable_operation fills it for a vectype of vector short
(4). Before (in vector_type_mode), we determined that a vector long (1) has an
integer m
On Wed, Dec 18, 2024 at 6:48 PM Robin Dapp wrote:
>
> Hi,
>
> in PR116351 we try to vectorize with -march=...zve32x which does not
> have 64-bit vector element sizes, don't find a proper mode and end up
> using word_mode = DImode.
>
> vect_verify_loop_lens calls get_len_load_store_mode which asser
Hi,
in PR116351 we try to vectorize with -march=...zve32x which does not
have 64-bit vector element sizes, don't find a proper mode and end up
using word_mode = DImode.
vect_verify_loop_lens calls get_len_load_store_mode which asserts
VECTOR_MODE_P (vecmode) so DImode will cause an ICE.
In check
