OK, so actually generating code with that vector(1) is bad (slower
than using scalar code)? Was that the same for PR121048?
The general situation is similar but IIRC we had a real vector mode there.
There the code didn't look terrible apart from using very small vectors
(2 elements). Here I guess it's worse, yeah.
These very small vector extensions (subset of the RVV spec) are clearly
targeting embedded implementations. I have no idea about their
performance characteristics (and frankly I don't care too much).
But I wouldn't expect 2-element vectors to ever be terribly beneficial
except if the scalar side is even worse...
As said, I can change the code to avoid computing a vector type at all
(it's just a compile-time optimization at that point). This series
also needs more work elsewhere, so I'm putting it on hold for now.
I might want to go forward with some of the gather/scatter cleanups
though.
IMHO this zve32 fallout here now shouldn't block anything. As we vectorize
via SLP still anyway it's not even a performance regression so we can just
change the checks. It's niche enough that nobody will complain.
The plan with this series was to get to the point where determining
the vector types to use is delayed to SLP build. But it's a longer
way towards that, also because of patterns.
In the end single-lane early SLP build should happen in place of
the current vect_mark_stmts_to_be_vectorized (and the SLP discovery
algorithm work by merging nodes on that). That's still after
pattern recog ...
In the end the stmt_vinfos should only contain per-gimple stmt
info that's valid over all analyses (with different modes, epilogue
or not, etc.).
I'm currently trying to find where I can incrementally work towards
that, without the need to keep bigger out-of-tree work. So I'm
concentrating on
- removing "redundant" info we have on both SLP node and stmt_info
- moving transform related info elsewhere (the STMT_VINFO_DEF_TYPE
move is an enabler for that)
- trying to sort out the stmt_vinfo vs. DR-info vs. slp_node mess
and things like alignment analysis and alignment enhancement
And of course that's all in preparation for the vectorizer-for-dummies
tutorial I have registered for Cauldron.
Oh, that's great. That's on top of your "vectorizer status" as well as
BoF? I'm still pondering a RISC-V vectorization 101 talk but
didn't make any progress regarding a yes/no...
--
Regards
Robin
