On Fri, 25 Jul 2025, Robin Dapp wrote: > > 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.
True. There might be SLP restrictions and in the end we want to handle VF > 1 for partial vectorized loops as well. If it's beneficial enough the target hook could tell to prefer the vector(1) mode. > > > > 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... I've folded the "vectorizer status" into the beginning of the BoF, so "only" two slots from my side. Richard.
