https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79483
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sebpop at gmail dot com
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so what is missing seems to be notifying ISL of the scalar write in
pretmp_38 = e[f_20][2];
as we convert the loop-around reg
prephitmp_39 = PHI <pretmp_38(6), 1.0e+0(2)>
to memory.
Converting dr: pdr_4 (read
in gimple stmt: prephitmp_39 = PHI <pretmp_38(6), 1.0e+0(2)>
data accesses: { S_7[i1] -> [138] }
subscript sizes: { S_7[i1] -> [138] : i1 >= 0 }
)
To polyhedral representation:
- access functions: { S_7[i1] -> [138] }
- subscripts: { S_7[i1] -> [138] : i1 >= 0 }
...
Converting dr: pdr_11 (write
in gimple stmt: pretmp_38 = e[f_20][2];
data accesses: { S_6[i1] -> [138] }
subscript sizes: { S_6[i1] -> [138] : i1 >= 0 }
)
To polyhedral representation:
- access functions: { S_6[i1] -> [138] }
- subscripts: { S_6[i1] -> [138] : i1 >= 0 }
not sure what has to match up here but I see S_6 vs. S_7 and [138].
Then:
[sese-to-poly] original schedule:
domain: "{ S_5[i1] : 0 <= i1 <= 1; S_6[i1 = 0]; S_8[]; S_7[i1] : 0 <= i1 <= 1;
S_4[i1, i2] : 0 <= i1 <= 1 and 0 <= i2 <= 5 }"
child:
sequence:
- filter: "{ S_4[i1, i2]; S_5[i1]; S_7[i1] }"
child:
schedule: "L_1[{ S_4[i1, i2] -> [(i1)]; S_5[i1] -> [(i1)]; S_7[i1] ->
[(i1)] }]"
child:
sequence:
- filter: "{ S_7[i1] }"
- filter: "{ S_4[i1, i2] }"
child:
schedule: "L_2[{ S_4[i1, i2] -> [(i2)] }]"
- filter: "{ S_5[i1] }"
- filter: "{ S_8[] }"
- filter: "{ S_6[i1] }"
child:
schedule: "L_1[{ S_6[i1] -> [(i1)] }]"
which I can't really decipher.
[scheduler] original ast:
{
for (int c0 = 0; c0 <= 1; c0 += 1) {
S_7(c0);
for (int c1 = 0; c1 <= 5; c1 += 1)
S_4(c0, c1);
S_5(c0);
}
S_8();
S_6(0);
}
has S_6 in bogus position AFAICS. It should be inside the outer loop.
Sebastian - any hint where things go wrong? Code-gen inserts S_6 outside
of the loop (as expected from the above AST) leading to wrong-code or
SSA verification failure.
Testcase in comment#4 on the GCC 7 branch, ISL 0.18.
We do build_schedule_loop_nest twice for the outer loop and the intermediate
pbb seems to confuse add_in_sequence or embed_in_surrounding_loops.
In particular the pbb for the loop-closed PHI block of the outer loop is
before the latch block of the outer loop in the pbbs array. Not sure if
that matters...
So it might be that the change using RPO order to sort the dominator children
instead of postorder on the inverted CFG triggered this as regression.
In any case relying on this order seems fishy so either we need to sort pbbs
or rewrite schedule generation to not rely on such order?
