On Tue, Nov 12, 2019 at 6:54 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Richard Biener <richard.guent...@gmail.com> writes: > > 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? > > It isn't supported as things stand. It shouldn't be hard to make > it work, but I'm not sure what the best semantics would be. > > AIUI, before the series, returning word_mode from preferred_simd_mode > just means that vectors should have the same size as word_mode. If the > target defines V2SI, we'll use that as the raw type mode for SI vectors, > regardless of whether V2SI is enabled. If the mode *is* enabled, > the TYPE_MODE will also be V2SI and so returning word_mode from > preferred_simd_mode is equivalent to returning V2SImode. If the mode > isn't enabled, the TYPE_MODE will be word_mode if that's suitable and > BLKmode otherwise. > > The situation's similar for SF; if the target defines and supports V2SF, > returning word_mode would be equivalent to returning V2SFmode. > > But it sounds like returning word_mode for the new hook would behave > differently, in that we'd force the raw type mode to be DImode even > if V2SImode is defined and supported.
Yes. > So what should happen for float > types? Should we reject those, or behave as above and apply the usual > mode_for_vector treatment for a word_mode-sized vector? I wasn't aware we're doing this mode_for_vector dance, certainly we didn't that before? I expected targets would return vector modes that are enabled only. What's the reason to not do that? > If code contains a mixture of HImode and SImode elements, should > we use DImode for both of them, or SImode for HImode elements? > Should the modes be passed to the target's related_vector_mode > hook in the same way as for vectors, or handled before then? I'd say SImode and HImode are naturally "related" "vector" modes for word_mode - so word_mode ideally is just a placeholder for "try to vectorize w/o actual SIMD instructions" which we can do for a small set of operations. > I could implement one of these. I'm just not sure it'd turn out > to be the right one, once someone actually tries to use it. :-) Heh. I was merely trying to make sure we're not designing us into a corner where we can't mix the word_mode vectorization facility with the SIMD one (because on GIMPLE it's still all vectors, only vector lowering exposes the ints IIRC). > FWIW, another way of doing the same thing would be to define > emulated vector modes, e.g. EMUL_V2SI, giving them a lower > priority than the real V2SI. This is already possible with > VECTOR_MODES_WITH_PREFIX. Because these emulated modes would > be permanently unsupported, the associated TYPE_MODE would always > be the equivalent integer mode (if appropriate). So we could force > integer modes that way too. This has the advantage that we never lose > sight of what the element type is, and so can choose between pairing > EMUL_V2SI and EMUL_V4HI vs. pairing EMUL_V2SI and EMUL_V2HI, > just like we can for "real" vector modes. > > Of course that's "a bit" of a hack. But then so IMO is using integer > modes for this kind of choice. :-) > > Another option I'd considered was having the hook return a list of > abstract identifiers that are only meaningful to the target, either > with accompanying information like the maximum size and maximum nunits, > or with a separate hook to provide that information. Or we could even > return a list of virtual objects. But that seemed like an abstraction > too far when in practice a vector mode should be descriptive enough. Anyway, I think we have testsuite coverage for word_mode vectorization and IIRC i?86 enables that when there's no SSE support via the preferred_simd_mode hook which you do not change (and at the moment that doesn't have to be in the list of sizes we should iterate over). When I understand you correctly what is not yet supported with your patch is adding word_mode (or other integer modes) to autovectorize_vector_modes but behavior could be emulated via non-enabled vector modes that get mapped to integer modes. Thus the patch is OK. Thanks, Richard. > Thanks, > Richard
