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)