[Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522

[matz at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192

--- Comment #2 from Michael Matz <matz at gcc dot gnu.org> ---
Unroll-and-jam simply unrolls the outer loop and merged all resulting
inner-loop bodies.  In this situation we have (before unroll-and-jam):

outerloop(i_1) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
    .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
    ... uninteresting things (j) ...
  }
}

Unroll-and-jam then simply does (that's the unrolling):

outerloop(i by 2) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
    .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
    ... uninteresting things (i, j) ...
  }
  i_2 = i_1 + 1
  _15 = i_2 <= 59
  innerloop(i_2, j by 1) {
    .GOMP_SIMD_LANE (simduid.6_16(D), 0, _15);
    ... uninteresting things (i + 1, j) ...
  }
}

and then fuses the two inner loops, which means that the instructions between
them (the original pre-header of the inner loop) become replicated inside
the new inner loop body (here, the loop-invariant condition):

outerloop(i by 2) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
    .GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
    ... uninteresting things (i, j) ...
    i_2 = i_1 + 1
    _15 = i_2 <= 59
    .GOMP_SIMD_LANE (simduid.6_16(D), 0, _15);
    ... uninteresting things (i + 1, j) ...
  }
}

There is nothing which somehow would indicate that this is invalid, and I can't
see why it should be.  If GIMP_SIMD_LANE has properties that make this
transformation invalid I would argue that those properties are correctly
represented.  One could of course hack bb_prevents_fusion_p or
unroll_jam_possible_p to avoid this situation, but that would seem like a
bad hack, as random other CFG transformation might introduce similar things:
namely a GOMP_SIMD_LANE statement that's fed by an unhoisted loop-invariant
condition.

So, I'd argue the assert is too eager.