Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
Richard Biener writes: > On Tue, Nov 12, 2019 at 6:54 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford >> > wrote: >> >> >> >> Richard Biener writes: >> >> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford >> >> > 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, ) || !mode_for_vector (inner_mode, nunits).exists (_mode)) return NULL_TREE; /* NOTE: nunits == 1 is allowed to support single element vector types. */ if (!multiple_p (GET_MODE_SIZE (simd_mode), nbytes, )) 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
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
On Tue, Nov 12, 2019 at 6:54 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford > > wrote: > >> > >> Richard Biener writes: > >> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford > >> > 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
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
Richard Biener writes: > On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford >> > 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. 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? 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 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. :-) 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
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford > > 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
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
Ping Richard Sandiford writes: > Richard Biener writes: >> On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford >> 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 2019-10-24 Richard Sandiford gcc/ * target.h (vector_sizes, auto_vector_sizes): Delete. (vector_modes, auto_vector_modes): New typedefs. * target.def (autovectorize_vector_sizes): Replace with... (autovectorize_vector_modes): ...this new hook. * doc/tm.texi.in (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Replace with... (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): ...this new hook. * doc/tm.texi: Regenerate. * targhooks.h (default_autovectorize_vector_sizes): Delete. (default_autovectorize_vector_modes): New function. * targhooks.c (default_autovectorize_vector_sizes): Delete. (default_autovectorize_vector_modes): New function. * omp-general.c (omp_max_vf): Use autovectorize_vector_modes instead of autovectorize_vector_sizes. Use the number of units in the mode to calculate the maximum VF. * omp-low.c (omp_clause_aligned_alignment): Use autovectorize_vector_modes instead of autovectorize_vector_sizes. Use a loop based on related_mode to iterate through all supported vector modes for a given scalar mode. * optabs-query.c (can_vec_mask_load_store_p): Use autovectorize_vector_modes instead of autovectorize_vector_sizes. * tree-vect-loop.c (vect_analyze_loop, vect_transform_loop): Likewise. * tree-vect-slp.c (vect_slp_bb_region): Likewise. * config/aarch64/aarch64.c (aarch64_autovectorize_vector_sizes): Replace with... (aarch64_autovectorize_vector_modes): ...this new function. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define. * config/arc/arc.c (arc_autovectorize_vector_sizes): Replace with... (arc_autovectorize_vector_modes): ...this new function. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define. * config/arm/arm.c (arm_autovectorize_vector_sizes): Replace with... (arm_autovectorize_vector_modes): ...this new function. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define. * config/i386/i386.c (ix86_autovectorize_vector_sizes): Replace with... (ix86_autovectorize_vector_modes): ...this new function. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
Richard Biener writes: > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford > 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
Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
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? Note that your
x86 change likely disables word_mode vectorization with -mno-sse?
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?
Thanks,
Richard.
>
> 2019-10-24 Richard Sandiford
>
> gcc/
> * target.h (vector_sizes, auto_vector_sizes): Delete.
> (vector_modes, auto_vector_modes): New typedefs.
> * target.def (autovectorize_vector_sizes): Replace with...
> (autovectorize_vector_modes): ...this new hook.
> * doc/tm.texi.in (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES):
> Replace with...
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): ...this new hook.
> * doc/tm.texi: Regenerate.
> * targhooks.h (default_autovectorize_vector_sizes): Delete.
> (default_autovectorize_vector_modes): New function.
> * targhooks.c (default_autovectorize_vector_sizes): Delete.
> (default_autovectorize_vector_modes): New function.
> * omp-general.c (omp_max_vf): Use autovectorize_vector_modes instead
> of autovectorize_vector_sizes. Use the number of units in the mode
> to calculate the maximum VF.
> * omp-low.c (omp_clause_aligned_alignment): Use
> autovectorize_vector_modes instead of autovectorize_vector_sizes.
> Use a loop based on related_mode to iterate through all supported
> vector modes for a given scalar mode.
> * optabs-query.c (can_vec_mask_load_store_p): Use
> autovectorize_vector_modes instead of autovectorize_vector_sizes.
> * tree-vect-loop.c (vect_analyze_loop, vect_transform_loop): Likewise.
> * tree-vect-slp.c (vect_slp_bb_region): Likewise.
> * config/aarch64/aarch64.c (aarch64_autovectorize_vector_sizes):
> Replace with...
> (aarch64_autovectorize_vector_modes): ...this new function.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
> * config/arc/arc.c (arc_autovectorize_vector_sizes): Replace with...
> (arc_autovectorize_vector_modes): ...this new function.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
> * config/arm/arm.c (arm_autovectorize_vector_sizes): Replace with...
> (arm_autovectorize_vector_modes): ...this new function.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
> * config/i386/i386.c (ix86_autovectorize_vector_sizes): Replace
> with...
> (ix86_autovectorize_vector_modes): ...this new function.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
> * config/mips/mips.c (mips_autovectorize_vector_sizes): Replace
> with...
> (mips_autovectorize_vector_modes): ...this new function.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
> (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
>
> Index: gcc/target.h
> ===
> --- gcc/target.h2019-09-30 17:19:39.843166118 +0100
> +++ gcc/target.h2019-10-25 13:27:15.525762975 +0100
> @@ -205,11 +205,11 @@ enum vect_cost_model_location {
> class vec_perm_indices;
>
> /* The type to use for lists of vector sizes. */
> -typedef vec vector_sizes;
> +typedef vec vector_modes;
>
> /* Same, but can be used to construct local lists that are
> automatically freed. */
> -typedef auto_vec auto_vector_sizes;
> +typedef auto_vec auto_vector_modes;
>
> /* The target structure. This holds all the backend hooks. */
> #define DEFHOOKPOD(NAME, DOC, TYPE, INIT) TYPE NAME;
> Index: gcc/target.def
> ===
> --- gcc/target.def 2019-10-25 13:26:59.309877555 +0100
> +++ gcc/target.def 2019-10-25 13:27:15.525762975 +0100
> @@ -1894,20 +1894,28 @@ reached. The default is @var{mode} whic
> /* Returns a mask of vector sizes to iterate over when auto-vectorizing
> after processing the preferred one derived from
[8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes
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.
2019-10-24 Richard Sandiford
gcc/
* target.h (vector_sizes, auto_vector_sizes): Delete.
(vector_modes, auto_vector_modes): New typedefs.
* target.def (autovectorize_vector_sizes): Replace with...
(autovectorize_vector_modes): ...this new hook.
* doc/tm.texi.in (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES):
Replace with...
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): ...this new hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_autovectorize_vector_sizes): Delete.
(default_autovectorize_vector_modes): New function.
* targhooks.c (default_autovectorize_vector_sizes): Delete.
(default_autovectorize_vector_modes): New function.
* omp-general.c (omp_max_vf): Use autovectorize_vector_modes instead
of autovectorize_vector_sizes. Use the number of units in the mode
to calculate the maximum VF.
* omp-low.c (omp_clause_aligned_alignment): Use
autovectorize_vector_modes instead of autovectorize_vector_sizes.
Use a loop based on related_mode to iterate through all supported
vector modes for a given scalar mode.
* optabs-query.c (can_vec_mask_load_store_p): Use
autovectorize_vector_modes instead of autovectorize_vector_sizes.
* tree-vect-loop.c (vect_analyze_loop, vect_transform_loop): Likewise.
* tree-vect-slp.c (vect_slp_bb_region): Likewise.
* config/aarch64/aarch64.c (aarch64_autovectorize_vector_sizes):
Replace with...
(aarch64_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/arc/arc.c (arc_autovectorize_vector_sizes): Replace with...
(arc_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/arm/arm.c (arm_autovectorize_vector_sizes): Replace with...
(arm_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/i386/i386.c (ix86_autovectorize_vector_sizes): Replace with...
(ix86_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/mips/mips.c (mips_autovectorize_vector_sizes): Replace with...
(mips_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
Index: gcc/target.h
===
--- gcc/target.h2019-09-30 17:19:39.843166118 +0100
+++ gcc/target.h2019-10-25 13:27:15.525762975 +0100
@@ -205,11 +205,11 @@ enum vect_cost_model_location {
class vec_perm_indices;
/* The type to use for lists of vector sizes. */
-typedef vec vector_sizes;
+typedef vec vector_modes;
/* Same, but can be used to construct local lists that are
automatically freed. */
-typedef auto_vec auto_vector_sizes;
+typedef auto_vec auto_vector_modes;
/* The target structure. This holds all the backend hooks. */
#define DEFHOOKPOD(NAME, DOC, TYPE, INIT) TYPE NAME;
Index: gcc/target.def
===
--- gcc/target.def 2019-10-25 13:26:59.309877555 +0100
+++ gcc/target.def 2019-10-25 13:27:15.525762975 +0100
@@ -1894,20 +1894,28 @@ reached. The default is @var{mode} whic
/* Returns a mask of vector sizes to iterate over when auto-vectorizing
after processing the preferred one derived from preferred_simd_mode. */
DEFHOOK
-(autovectorize_vector_sizes,
- "If the mode returned by @code{TARGET_VECTORIZE_PREFERRED_SIMD_MODE} is not\n\
-the only one that is worth considering, this hook should add all suitable\n\
-vector sizes to @var{sizes}, in order of decreasing preference. The first\n\
-one should be the size of @code{TARGET_VECTORIZE_PREFERRED_SIMD_MODE}.\n\
-If @var{all} is true, add suitable vector sizes even when they are generally\n\
+(autovectorize_vector_modes,
+ "If using the mode returned by @code{TARGET_VECTORIZE_PREFERRED_SIMD_MODE}\n\
+is not the only approach worth
