On Wed, 30 Aug 2023, juzhe.zh...@rivai.ai wrote:
> I am wondering whether we do have some situations that
> vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be beneficial for RVV ?
> I have ever met some situation that vec_unpack can be beneficial when working
> on SELECT_VL but I don't which case....
With fixed size vectors you'll face the situation that the vectorizer
chooses the "wrong" vector type so yes, I think implementing
vec_unpack[s]_{lo,hi} might be useful. But I wouldn't prioritize this
until you have a more clear picture of how useful it would be.
Richard.
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-08-30 16:06
> To: Richard Biener; juzhe.zh...@rivai.ai
> CC: rdapp.gcc; gcc
> Subject: Re: Question about wrapv-vect-reduc-dot-s8b.c
> >> 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
> We usually try with a "normal" mode like VNx4SI (RVVM1SI or so) and
> then switch to VNx4QI (i.e. a mode that only determines the number of
> units/elements) and have vectorize_related_mode return modes with the
> same number of units. This will then result in the sext/zext patterns
> matching. The first round where we try the normal mode will not match
> those because the related mode has a different number of units.
>
> So it's somewhat expected that the first try fails.
>
> My dump shows that we vectorize, so IMHO no problem. I can take a look
> at this but it doesn't look like a case for pack/unpack.
>
> Regards
> Robin
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
