diff options
author | Victor Do Nascimento <victor.donascimento@arm.com> | 2024-12-11 12:00:09 +0000 |
---|---|---|
committer | Tamar Christina <tamar.christina@arm.com> | 2024-12-11 12:00:16 +0000 |
commit | d069eb91d5696a8642bd5fc44a6d47fd7f74d18b (patch) | |
tree | ca8a89c92f2a1c80a73afa32108ea6db5d56e2d3 /gcc/expr.cc | |
parent | 240cbd2f26c0f1c1f83cfc3b69cc0271b56172e2 (diff) | |
download | gcc-d069eb91d5696a8642bd5fc44a6d47fd7f74d18b.zip gcc-d069eb91d5696a8642bd5fc44a6d47fd7f74d18b.tar.gz gcc-d069eb91d5696a8642bd5fc44a6d47fd7f74d18b.tar.bz2 |
middle-end: add vec_init support for variable length subvector concatenation. [PR96342]
For architectures where the vector-length is a compile-time variable,
rather representing a runtime constant, as is the case with SVE it is
perfectly reasonable that such vector be made up of two (or more) subvector
components of a compatible sub-length variable.
One example of this would be the concatenation of two VNx4QI vectors
into a single VNx8QI vector.
This patch adds initial support for the enablement of this feature in
the middle-end, removing the `.is_constant()' constraint on the vector's
number of elements, instead making the constant no. of elements the
multiple of the number of subvectors (which must then also be of
variable length, such that their polynomial ratio then results in a
compile-time constant) required to fill the vector.
gcc/ChangeLog:
PR target/96342
* expr.cc (store_constructor): add support for variable-length
vectors.
Co-authored-by: Tamar Christina <tamar.christina@arm.com>
Diffstat (limited to 'gcc/expr.cc')
-rw-r--r-- | gcc/expr.cc | 38 |
1 files changed, 19 insertions, 19 deletions
diff --git a/gcc/expr.cc b/gcc/expr.cc index 980ac41..88fa56c 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -7966,12 +7966,9 @@ store_constructor (tree exp, rtx target, int cleared, poly_int64 size, n_elts = TYPE_VECTOR_SUBPARTS (type); if (REG_P (target) - && VECTOR_MODE_P (mode) - && n_elts.is_constant (&const_n_elts)) + && VECTOR_MODE_P (mode)) { - machine_mode emode = eltmode; - bool vector_typed_elts_p = false; - + const_n_elts = 0; if (CONSTRUCTOR_NELTS (exp) && (TREE_CODE (TREE_TYPE (CONSTRUCTOR_ELT (exp, 0)->value)) == VECTOR_TYPE)) @@ -7980,23 +7977,26 @@ store_constructor (tree exp, rtx target, int cleared, poly_int64 size, gcc_assert (known_eq (CONSTRUCTOR_NELTS (exp) * TYPE_VECTOR_SUBPARTS (etype), n_elts)); - emode = TYPE_MODE (etype); - vector_typed_elts_p = true; + + icode = convert_optab_handler (vec_init_optab, mode, + TYPE_MODE (etype)); + const_n_elts = CONSTRUCTOR_NELTS (exp); + vec_vec_init_p = icode != CODE_FOR_nothing; } - icode = convert_optab_handler (vec_init_optab, mode, emode); - if (icode != CODE_FOR_nothing) + else if (exact_div (n_elts, GET_MODE_NUNITS (eltmode)) + .is_constant (&const_n_elts)) { - unsigned int n = const_n_elts; - - if (vector_typed_elts_p) - { - n = CONSTRUCTOR_NELTS (exp); - vec_vec_init_p = true; - } - vector = rtvec_alloc (n); - for (unsigned int k = 0; k < n; k++) - RTVEC_ELT (vector, k) = CONST0_RTX (emode); + /* For a non-const type vector, we check it is made up of + similarly non-const type vectors. */ + icode = convert_optab_handler (vec_init_optab, mode, eltmode); } + + if (const_n_elts && icode != CODE_FOR_nothing) + { + vector = rtvec_alloc (const_n_elts); + for (unsigned int k = 0; k < const_n_elts; k++) + RTVEC_ELT (vector, k) = CONST0_RTX (eltmode); + } } /* Compute the size of the elements in the CTOR. It differs |