Thanks Richi.
>> both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
Sorry I made a mistake here. They are not the same nunits.
wrapv-vect-reduc-dot-s8b.c:29:14: note: get vectype for scalar type: short
int
wrapv-vect-reduc-dot-s8b.c:29:14: note: vectype: vector([8,8]) short int
wrapv-vect-reduc-dot-s8b.c:29:14: note: nunits = [8,8]
wrapv-vect-reduc-dot-s8b.c:29:14: note: ==> examining statement: _1 = X[i_14];
wrapv-vect-reduc-dot-s8b.c:29:14: note: precomputed vectype: vector([16,16])
signed char
wrapv-vect-reduc-dot-s8b.c:29:14: note: nunits = [16,16]
wrapv-vect-reduc-dot-s8b.c:29:14: note: ==> examining statement: _2 = (short
int) _1;
wrapv-vect-reduc-dot-s8b.c:29:14: note: get vectype for scalar type: short int
wrapv-vect-reduc-dot-s8b.c:29:14: note: vectype: vector([8,8]) short int
wrapv-vect-reduc-dot-s8b.c:29:14: note: get vectype for smallest scalar type:
signed char
wrapv-vect-reduc-dot-s8b.c:29:14: note: nunits vectype: vector([16,16])
signed char
wrapv-vect-reduc-dot-s8b.c:29:14: note: nunits = [16,16]
Turns out for _2, it picks vector([8,8]) short int and _1, it picks
vector([16,16]) signed char
at the first time analysis.
It seems that because we don't support vec_unpacks so that the first time
analysis failed ?
Then we end up with "2" times these 2 checks:
> FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vect_recog_dot_prod_pattern: detected" 1
> FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vect_recog_widen_mult_pattern: detected" 1
[email protected]
From: Richard Biener
Date: 2023-08-30 15:45
To: [email protected]
CC: gcc; Robin Dapp
Subject: Re: Question about wrapv-vect-reduc-dot-s8b.c
On Wed, 30 Aug 2023, [email protected] wrote:
> Hi, I start to enable "vect" testsuite for RISC-V.
>
> I have a question when analyzing the 'wrapv-vect-reduc-dot-s8b.c'
> It failed at:
> FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vect_recog_dot_prod_pattern: detected" 1
> FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vect_recog_widen_mult_pattern: detected" 1
>
> They are found "2" times.
>
> Since at the first time, it failed at the vectorization of conversion:
>
> wrapv-vect-reduc-dot-s8b.c:29:14: missed: conversion not supported by
> target.
> wrapv-vect-reduc-dot-s8b.c:29:14: note: vect_is_simple_use: operand
> X[i_14], type of def: internal
> wrapv-vect-reduc-dot-s8b.c:29:14: note: vect_is_simple_use: vectype
> vector([16,16]) signed char
> wrapv-vect-reduc-dot-s8b.c:29:14: note: vect_is_simple_use: operand
> X[i_14], type of def: internal
> wrapv-vect-reduc-dot-s8b.c:29:14: note: vect_is_simple_use: vectype
> vector([16,16]) signed char
> wrapv-vect-reduc-dot-s8b.c:30:17: missed: not vectorized: relevant stmt not
> supported: _2 = (short int) _1;
> wrapv-vect-reduc-dot-s8b.c:29:14: missed: bad operation or unsupported loop
> bound.
>
> Here loop vectorizer is trying to do the conversion from char -> short with
> both same nunits.
> But we don't support 'vec_unpack' stuff in RISC-V backend since I don't see
> the case that vec_unpack can optimize the codegen of autovectorizatio for RVV.
>
> To fix it, is it necessary to support 'vec_unpack' ?
both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
ties its hands by choosing vector types early and based on the number
of incoming/outgoing vectors it chooses one or the other method.
More precise dumping would probably help here but somewhere earlier you
should be able to see the vector type used for _2
Richard.
