[8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes

[Richard Biener]

On Tue, Nov 12, 2019 at 6:54 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener <richard.guenther@gmail.com> writes:
> > On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford
> > <richard.sandiford@arm.com> wrote:
> >>
> >> Richard Biener <richard.guenther@gmail.com> writes:
> >> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
> >> > <richard.sandiford@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