Closed miklos1 closed 7 years ago
t6
and t7
are "the same" in the upper hunk, meaning that they are both zero valued, so that substitution would be OK...
... However, there are two bugs here, and both are due to the replacement routine executed after loop fusion: 1) it doesn't distinguish across entirely different loop nests (this is horrible); 2) doesn't distinguish between AugmentedAssignment and Assign
Fortunately, both can trivially be fixed .
To replace t7[ip_1][i_1] = 0.0;
with t7[ip_1][i_1] = t6[ip_1][i_1];
is correct, because t6[ip_1][i_1]
is still zero at that point. But later they are getting different values accumulated in them (which does not show up in the diff, but you can check the full unoptimised file on the link above), so assuming they are the same is incorrect for the sake of further analysis.
I think this is pretty much what I said above
Same test case as in #98, but not generating spurious empty loops per firedrakeproject/tsfc@509cb75, as you can see here. This time, however, the test fails because the result is numerically wrong. Looking at the change COFFEE does explains why:
It seems that
t6
andt7
are incorrectly recognised to be the same (they are not), thust2[ip_0][i_0] * t6[ip_1][i_0]
seems to be the same ast2[ip_0][i_1] * t7[ip_1][i_1]
, and even then the transformation in the lower hunk is just wrong.