Richard Biener <richard.guent...@gmail.com> writes:
> 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?
We do that without the series too, just a bit more indirectly.
get_vectype_for_scalar_type_and_size has:
/* If no size was supplied use the mode the target prefers. Otherwise
lookup a vector mode of the specified size. */
if (known_eq (size, 0U))
simd_mode = targetm.vectorize.preferred_simd_mode (inner_mode);
else if (!multiple_p (size, nbytes, &nunits)
|| !mode_for_vector (inner_mode, nunits).exists (&simd_mode))
return NULL_TREE;
/* NOTE: nunits == 1 is allowed to support single element vector types. */
if (!multiple_p (GET_MODE_SIZE (simd_mode), nbytes, &nunits))
return NULL_TREE;
vectype = build_vector_type (scalar_type, nunits);
So all we use the simd_mode for is to get a size. Then that size
determines the nunits, and build_vector_type picks whichever mode
works best for that nunits and element type. That mode might not
have anything to do with simd_mode, except for having the same size.
So although the new mode_for_vector calls make that explicit,
it was the behaviour before the series too.
> I expected targets would return vector modes that
> are enabled only. What's the reason to not do that?
I think all current targets do only return supported modes or
word_mode from preferred_simd_mode. But returning word_mode
isn't for example an effective way of preventing V2SI being used,
since if V2SI is enabled for 64-bit targets, word_mode would actually
choose V2SI rather than DI.
>> 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).
Yeah.
> 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.
Right. And we could support word_mode with its current meaning
from autovectorize_vector_modes too if that turns out to be the
best way of handling it.
Thanks,
Richard
