On Fri, 25 Jul 2025, Robin Dapp wrote: > > So what was prevailing_mode then? > > RVVM2SI, so != word_mode, and basically two glued 32-bit vector regs. > We get that from the first call with innermode SI. > > > > > But > > > > /* Fall back to using mode_for_vector, mostly in the hope of being > > able to use an integer mode. */ > > if (known_eq (nunits, 0U) > > && !multiple_p (GET_MODE_SIZE (prevailing_mode), nbytes, &nunits)) > > return NULL_TREE; > > > > should have made this fail similarly. So I suppose prevailing_mode > > had an appropriate size and was not word_mode. > > yes. > > > I suppose if you have vector(1) modes your preferred_simd_mode > > hook should return that, not the too small integer mode? > > We disable 64-bit vector modes for this configuration/target because they > wouldn't fit the smallest possible vector. I guess the difference is that > mode_for_vector only checks targetm.vector_mode_supported_any_target_p (that > we have we just always return true) which makes us fall back to BLKmode in > vector_type_mode? > > So it's not really like we have a vector(1) mode just that it looks like it > for mode_for_vector but not for preferred_simd_mode.
OK, so actually generating code with that vector(1) is bad (slower than using scalar code)? Was that the same for PR121048? > But I'm not familiar with all the cross-dependencies here. If that's a riscv > port issue we can surely change something. 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. 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. Richard.
