https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120089
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
An the issue that we are not marking this as LOOP_VINFO_EARLY_BREAKS_LIVE_IVS
is because we do not consider it an induction as we get
{(type *) &data.d, +, (sizetype) _5 + 8}_2
and STEP is neither a constant nor an SSA name. This is because we have
two increments in the loop body:
<bb 12> [local count: 477815112]:
# _33 = PHI <0(20), _42(17)>
# nextVertexPtr_9 = PHI <&data.d(20), nextVertexPtr_41(17)>
# vertexIdx_7 = PHI <0(20), vertexIdx_40(17)>
_27 = _33 * 8;
_26 = origVertices_16(D) + _27;
_29 = MEM <unsigned long> [(char * {ref-all})_26];
MEM <unsigned long> [(char * {ref-all})nextVertexPtr_9] = _29;
nextVertexPtr_38 = nextVertexPtr_9 + 8; <--- here
vertexIdx_40 = vertexIdx_7 + 1;
if (vertexCount_11 > vertexIdx_40)
goto <bb 16>; [89.00%]
else
goto <bb 3>; [11.00%]
<bb 16> [local count: 425255450]:
nextVertexPtr_41 = nextVertexPtr_38 + _5; <--- here
_42 = (long unsigned int) vertexIdx_40;
if (_42 > t_10(D))
goto <bb 5>; [0.00%]
else
goto <bb 17>; [100.00%]
as a result from unswitching and not hoisting the resulting invariant
(_5 + 8).
That we "fail" to consider this a vectorizable IV required live for
early-break vectorization is bad. What is worse is that we fail to
then reject vectorizing instead of simply doing the wrong thing.
We can fix this by analyzing all PHIs to be "live" for early break,
resulting in
t.c:17:12: note: init: phi relevant? nextVertexPtr_9 = PHI <&data.d(20),
nextVertexPtr_41(17)>
t.c:17:12: note: vec_stmt_relevant_p: induction forced for early break.
t.c:17:12: note: vec_stmt_relevant_p: stmt live but not relevant.
...
t.c:17:12: note: vect_is_simple_use: operand nextVertexPtr_9 = PHI
<&data.d(20), nextVertexPtr_41(17)>, type of def: unknown
t.c:17:12: missed: Unsupported pattern.
t.c:21:23: missed: not vectorized: unsupported use in stmt.
t.c:17:12: missed: unexpected pattern.
since we don't handle this PHI.
