On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Richard Biener <richard.guent...@gmail.com> writes: > > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford > > <richard.sandif...@arm.com> wrote: > >> > >> This is another patch in the series to remove the assumption that > >> all modes involved in vectorisation have to be the same size. > >> Rather than have the target provide a list of vector sizes, > >> it makes the target provide a list of vector "approaches", > >> with each approach represented by a mode. > >> > >> A later patch will pass this mode to targetm.vectorize.related_mode > >> to get the vector mode for a given element mode. Until then, the modes > >> simply act as an alternative way of specifying the vector size. > > > > Is there a restriction to use integer vector modes for the hook > > or would FP vector modes be OK as well? > > Conceptually, each mode returned by the hook represents a set of vector > modes, with the set containing one member for each supported element > type. The idea is to represent the set using the member with the > smallest element type, preferring integer modes over floating-point > modes in the event of a tie. So using a floating-point mode as the > representative mode is fine if floating-point elements are the smallest > (or only) supported element type. > > > Note that your x86 change likely disables word_mode vectorization with > > -mno-sse? > > No, that still works, because... > > > That is, how do we represent GPR vectorization "size" here? > > The preferred SIMD mode hook may return an integer mode, > > are non-vector modes OK for autovectorize_vector_modes? > > ...at least with all current targets, preferred_simd_mode is only > an integer mode if the target has no "real" vectorisation support > for that element type. There's no need to handle that case in > autovectorize_vector_sizes/modes, and e.g. the x86 hook does nothing > when SSE is disabled. > > So while preferred_simd_mode can continue to return integer modes, > autovectorize_vector_modes always returns vector modes.
Hmm, I see. IIRC I was playing with a patch for x86 that enabled word-mode vectorization (64bits) for SSE before (I see we don't do that at the moment). The MMX-with-SSE has made that somewhat moot but with iterating over modes we could even make MMX-with-SSE (MMX modes) and word-mode vectors coexist by allowing the hook to return V4SI, V2SI, DImode? Because MMX-with-SSE might be more costly than word-mode but can of course handle more cases. So you say the above isn't supported and cannot be made supported? Thanks, Richard. > This patch just treats the mode as an alternative way of specifying > the vector size. 11/n then tries to use related_vector_mode to choose > the vector mode for each element type instead. But 11/n only uses > related_vector_mode if vec_info::vector_mode is a vector mode. If it's > an integer mode (as for -mno-sse), or if related_vector_mode fails to > find a vector mode, then we still fall back to mode_for_vector and so > pick an integer mode in the same cases as before. > > Thanks, > Richard
