We were using the wrong loop to figure the latch arg of a
double-reduction PHI. Which isn't a problem in case ->dest_idx
match up with the outer loop edges - but that's of course not guaranteed.
Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
2020-10-20 Richard Biener <rguent...@suse.de>
* tree-vect-loop.c (vectorizable_reduction): Use the correct
loops latch edge for the PHI arg lookup.
---
gcc/tree-vect-loop.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index dceb65c934a..c8747595a63 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6359,8 +6359,10 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
/* Verify following REDUC_IDX from the latch def leads us back to the PHI
and compute the reduction chain length. Discover the real
reduction operation stmt on the way (stmt_info and slp_for_stmt_info). */
- tree reduc_def = PHI_ARG_DEF_FROM_EDGE (reduc_def_phi,
- loop_latch_edge (loop));
+ tree reduc_def
+ = PHI_ARG_DEF_FROM_EDGE (reduc_def_phi,
+ loop_latch_edge
+ (gimple_bb (reduc_def_phi)->loop_father));
unsigned reduc_chain_length = 0;
bool only_slp_reduc_chain = true;
stmt_info = NULL;
--
2.26.2
