https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, fails with:
g++ -floop-nest-optimize -Ofast -w tramp3d-v4.cpp -fdump-tree-graphite-details
-$ fdbg-cnt=graphite_scop:4
Problem are following side-by-side loops:
[scheduler] original ast:
{
for (int c0 = 0; c0 <= 2; c0 += 1)
S_3(c0);
for (int c0 = 0; c0 <= 2; c0 += 1)
S_6(c0);
}
[scheduler] AST generated by isl:
{
for (int c0 = 0; c0 <= 2; c0 += 1)
S_6(c0);
for (int c0 = 0; c0 <= 2; c0 += 1)
S_3(c0);
}
which are interchanged. But due to fact that there's a data dependency:
...
<bb 3> [75.00%]:
# i_38 = PHI <i_11(4), 0(2)>
_34 = (sizetype) i_38;
_12 = _34 * 8;
_7 = &retval + _12;
_8 = s1_4(D) + _12;
_9 = MEM[(int *)_8];
MEM[(Element_t[2] &)_7][0] = _9; <----- store to retval
_10 = MEM[(int *)_8 + 4B];
MEM[(Element_t[2] &)_7][1] = _10;
i_11 = i_38 + 1;
if (i_11 == 3)
goto <bb 5>; [33.33%]
else
goto <bb 4>; [66.67%]
<bb 4> [50.00%]:
goto <bb 3>; [100.00%]
<bb 5> [25.00%]:
<bb 10> [25.00%]:
<bb 6> [75.00%]:
# i_39 = PHI <i_17(7), 0(10)>
_37 = (sizetype) i_39;
_35 = _37 * 8;
_13 = _3(D) + _35;
_14 = &retval + _35;
_15 = MEM[(int *)_14];
MEM[(Element_t[2] &)_13][0] = _15; <------ load from retval, stored to _3+x
_16 = MEM[(int *)_14 + 4B];
MEM[(Element_t[2] &)_13][1] = _16;
i_17 = i_39 + 1;
if (i_17 == 3)
goto <bb 8>; [33.33%]
else
goto <bb 7>; [66.67%]
<bb 7> [50.00%]:
goto <bb 6>; [100.00%]
...
return _3(D);
I can work on that, but any hint where such dependency should be caught?
