diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2019-11-14 14:36:26 +0000 |
---|---|---|
committer | Richard Sandiford <rsandifo@gcc.gnu.org> | 2019-11-14 14:36:26 +0000 |
commit | f09552335030433018fd5f7f6b9848339b5ca2da (patch) | |
tree | 78e267da95a352d5303bc66b513ab10e2f5979a9 /gcc/stor-layout.c | |
parent | 89cd5050928afa2d2e9cf836ae39f6cb947f5602 (diff) | |
download | gcc-f09552335030433018fd5f7f6b9848339b5ca2da.zip gcc-f09552335030433018fd5f7f6b9848339b5ca2da.tar.gz gcc-f09552335030433018fd5f7f6b9848339b5ca2da.tar.bz2 |
Add a targetm.vectorize.related_mode hook
This patch is the first of a series that tries to remove two
assumptions:
(1) that all vectors involved in vectorisation must be the same size
(2) that there is only one vector mode for a given element mode and
number of elements
Relaxing (1) helps with targets that support multiple vector sizes or
that require the number of elements to stay the same. E.g. if we're
vectorising code that operates on narrow and wide elements, and the
narrow elements use 64-bit vectors, then on AArch64 it would normally
be better to use 128-bit vectors rather than pairs of 64-bit vectors
for the wide elements.
Relaxing (2) makes it possible for -msve-vector-bits=128 to produce
fixed-length code for SVE. It also allows unpacked/half-size SVE
vectors to work with -msve-vector-bits=256.
The patch adds a new hook that targets can use to control how we
move from one vector mode to another. The hook takes a starting vector
mode, a new element mode, and (optionally) a new number of elements.
The flexibility needed for (1) comes in when the number of elements
isn't specified.
All callers in this patch specify the number of elements, but a later
vectoriser patch doesn't.
2019-11-14 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* target.def (related_mode): New hook.
* doc/tm.texi.in (TARGET_VECTORIZE_RELATED_MODE): New hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_vectorize_related_mode): Declare.
* targhooks.c (default_vectorize_related_mode): New function.
* machmode.h (related_vector_mode): Declare.
* stor-layout.c (related_vector_mode): New function.
* expmed.c (extract_bit_field_1): Use it instead of mode_for_vector.
* optabs-query.c (qimode_for_vec_perm): Likewise.
* tree-vect-stmts.c (get_group_load_store_type): Likewise.
(vectorizable_store, vectorizable_load): Likewise
From-SVN: r278229
Diffstat (limited to 'gcc/stor-layout.c')
-rw-r--r-- | gcc/stor-layout.c | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index 9aada97..c1b724f 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -530,6 +530,26 @@ mode_for_int_vector (unsigned int int_bits, poly_uint64 nunits) return opt_machine_mode (); } +/* If a piece of code is using vector mode VECTOR_MODE and also wants + to operate on elements of mode ELEMENT_MODE, return the vector mode + it should use for those elements. If NUNITS is nonzero, ensure that + the mode has exactly NUNITS elements, otherwise pick whichever vector + size pairs the most naturally with VECTOR_MODE; this may mean choosing + a mode with a different size and/or number of elements, depending on + what the target prefers. Return an empty opt_machine_mode if there + is no supported vector mode with the required properties. + + Unlike mode_for_vector. any returned mode is guaranteed to satisfy + both VECTOR_MODE_P and targetm.vector_mode_supported_p. */ + +opt_machine_mode +related_vector_mode (machine_mode vector_mode, scalar_mode element_mode, + poly_uint64 nunits) +{ + gcc_assert (VECTOR_MODE_P (vector_mode)); + return targetm.vectorize.related_mode (vector_mode, element_mode, nunits); +} + /* Return the alignment of MODE. This will be bounded by 1 and BIGGEST_ALIGNMENT. */ |