On Mon, 9 Oct 2023, Robin Dapp wrote: > > Maybe I should pretend RVV support vect_pack/vect_unpack and enable > > all the tests in target-supports.exp? > > The problem is that vect_pack/unpack is an overloaded term in the > moment meaning "vector conversion" (promotion/demotion) or so. This > test does not require pack/unpack for successful vectorization but our > method of keeping the number of elements the same works as well. The > naming probably precedes vectorizer support for that. > I can't imagine cases where vectorization would fail because of this > as we can always work around it some way. So from that point of view > "pretending" to support it would work. However in case somebody wants > to really write a specific test cases that relies on pack/unpack > (maybe there are already some?) "pretending" would fail.
I suspect that for VLS you need to provide the respective patterns because of the single vector-size restriction. > I lean towards "pretending" at the moment ;) The other option would be > to rename that and audit all test cases. > > Note there are also vect_intfloat_cvt as well as others that don't have > pack/unpack in the name (that we also probably still need to enable). Yeah well - the dejagnu "targets" are mostly too broad, but as usual time is spent elsewhere instead of at cleaning up the mess ;) It might be more useful to provide vect_<optab><mode>.. dg targets because then it's at least obvious what is meant. Or group things as vect_<optab>float vect_<optab>int. Richard. > 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)
