The following occured to me - hope it doesn't hide anything real.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Move
bitsize compute down to where it is used and consistently
use vectype1 for element extraction.
---
gcc/tree-vect-loop.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index ac30352b630..8ff8dc2ddda 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -5264,7 +5264,6 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
tree new_temp = NULL_TREE, new_name, new_scalar_dest;
gimple *epilog_stmt = NULL;
gimple *exit_phi;
- tree bitsize;
tree def;
tree orig_name, scalar_result;
imm_use_iterator imm_iter;
@@ -5481,7 +5480,6 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
scalar_results.truncate (0);
scalar_results.reserve_exact (group_size);
new_scalar_dest = vect_create_destination_var (scalar_dest, NULL);
- bitsize = TYPE_SIZE (scalar_type);
/* True if we should implement SLP_REDUC using native reduction operations
instead of scalar operations. */
@@ -5903,6 +5901,7 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
if (reduce_with_shift && (!slp_reduc || group_size == 1))
{
+ tree bitsize = TYPE_SIZE (TREE_TYPE (vectype1));
int element_bitsize = tree_to_uhwi (bitsize);
/* Enforced by vectorizable_reduction, which disallows SLP reductions
for variable-length vectors and also requires direct target support
@@ -5971,9 +5970,10 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
dump_printf_loc (MSG_NOTE, vect_location,
"Reduce using scalar code.\n");
+ tree compute_type = TREE_TYPE (vectype1);
+ tree bitsize = TYPE_SIZE (compute_type);
int vec_size_in_bits = tree_to_uhwi (TYPE_SIZE (vectype1));
int element_bitsize = tree_to_uhwi (bitsize);
- tree compute_type = TREE_TYPE (vectype);
gimple_seq stmts = NULL;
FOR_EACH_VEC_ELT (reduc_inputs, i, vec_temp)
{
--
2.51.0
