Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes

[Richard Sandiford <richard dot sandiford at arm dot com>]

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.

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