On Wed, 30 Aug 2023, Robin Dapp wrote:
> >> 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.
it's target dependent what we choose first so it's going to be
a bit difficult to adjust testcases like this (and it looks like
a testsuite issue). I think for this specific testcase changing
scan-tree-dump-times to scan-tree-dump is reasonable. Note we
really want to check that for the case we choose finally
we use the sdot pattern, but I don't see how we can easily constrain
the dump-scans. Can we do sth like
"vect_recog_dot_prod_pattern: detected\n(!FAILED)*SUCCEEDED", thus
after the dot-prod pattern dumping allow arbitrary stuff but _not_
a "failed" and then require a "succeeded"?
The other way would be to somehow add a dump flag that produces
dumps only for the succeeded part. Of course we have targets that
evaluate multiple succeeded parts for costing (but luckily costing
is disabled for most tests).
Richard.
