https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116338
--- Comment #3 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> The issue is the recurrence
>
> <bb 2> [local count: 10737416]:
> x_10 = b[31999];
> y_11 = b[31998];
>
> <bb 3> [local count: 1063004408]:
> # x_18 = PHI <_1(5), x_10(2)>
> # y_19 = PHI <x_18(5), y_11(2)>
> _1 = b[i_20];
> ..
>
> <bb 5> [local count: 1052266995]:
> goto <bb 3>; [100.00%]
>
> we handle some cases via vect_phi_first_order_recurrence_p, somebody needs
> to dig in why this one isn't (or can't be) handled with that mechanism.
/* Ensure the loop latch definition is from within the loop. */
edge latch = loop_latch_edge (loop);
tree ldef = PHI_ARG_DEF_FROM_EDGE (phi, latch);
if (TREE_CODE (ldef) != SSA_NAME
|| SSA_NAME_IS_DEFAULT_DEF (ldef)
|| is_a <gphi *> (SSA_NAME_DEF_STMT (ldef))
|| !flow_bb_inside_loop_p (loop, gimple_bb (SSA_NAME_DEF_STMT (ldef))))
return false;
(gdb) p debug_tree (ldef)
<ssa_name 0xfffff7979900
type <real_type 0xfffff796d0a8 real_t sizes-gimplified SF
size <integer_cst 0xfffff7a86150 constant 32>
unit-size <integer_cst 0xfffff7a86168 constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xfffff7a8b2a0 precision:32
pointer_to_this <pointer_type 0xfffff79b2b28>>
visited var <var_decl 0xfffff79b1510 x>
def_stmt x_18 = PHI <_1(5), x_10(2)>
version:18>
$1 = void
That is PHI arg defined along the loop latch is also PHI stmt in the case.
