https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
--- Comment #10 from Sebastian Pop <spop at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> Yeah, seems to be gone with ISL 0.18 here as well... (but with 0.16.1 I can
> still reproduce it). ISL 0.18 doesn't do anything to the loop. ISL 0.16.1
> just did some IV transforms it seems:
>
> [scheduler] original ast:
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 0; c1 <= 3; c1 += 1) {
> S_5(c0, c1);
> if (c1 <= 2)
> S_6(c0, c1);
> }
>
> [scheduler] AST generated by isl:
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 3 * c0; c1 <= 3 * c0 + 3; c1 += 1) {
> S_5(c0, -3 * c0 + c1);
I don't know why isl started the inner loop at 3*c0:
In the end we have the identity for the array subscript: 3*c0 - 3*c0 = 0
Could be a bug in the older isl.
> if (3 * c0 + 2 >= c1)
> S_6(c0, -3 * c0 + c1);
> }
>
> and with ISL 0.18 we have
>
> [scheduler] isl optimized schedule is identical to the original schedule.
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 0; c1 <= 3; c1 += 1) {
> S_5(c0, c1);
> if (c1 <= 2)
> S_6(c0, c1);
> }
>
> and eventually code generation is not happy with the changed form
> (-fgraphite-identity is fine).
>
> Sebastian, any comment? I think we could still for example require current
> ISL
> for GCC 6 (0.18 or maybe 0.17.1). Or at least drop support for the current
> legacy.
I would like moving away from the older isl versions: newer isl have fewer
bugs, and people also worked on making isl faster.
Moving to a newer isl would allow to also clean up the #ifdef's from the
graphite-*.c files which will make the code easier to read.
