------- Comment #1 from jakub at gcc dot gnu dot org 2006-11-14 14:27 -------
lambda_loopnest_to_gcc_loopnest interchanges the loops and we get:
<L12>:;
lletmp.77_46 = 0;
lletmp.77_38 = lletmp.77_46 + 5;
lnivtmp.75_21 = lnivtmp.75_9 + 1;
lnivtmp.75_12 = lnivtmp.75_9 + 1;
if (lletmp.77_38 <= lnivtmp.75_12) goto <L99>; else goto <L86>;
<L86>:;
# lnivtmp.75_9 = PHI <lnivtmp.75_21(13), lletmp.76_162(11)>;
# S.2_165 = PHI <S.2_40(13), 0(11)>;
<L13>:;
lbvtmp.82_18 = 0;
lbvtmp.82_145 = lnivtmp.78_8;
lbvtmp.82_20 = lbvtmp.82_18 + lbvtmp.82_145;
S.2_40 = lbvtmp.82_20 + 1;
lletmp.79_154 = 0;
# lnivtmp.78_8 = PHI <lnivtmp.78_3(16), lletmp.79_154(14)>;
# S.3_171 = PHI <S.3_51(16), 1(14)>;
<L15>:;
lletmp.80_22 = 0;
lletmp.80_56 = lletmp.80_22 + 3;
D.1393_41 = S.2_40 * 6;
lbvtmp.81_31 = 0;
lbvtmp.81_26 = lnivtmp.78_8;
lbvtmp.81_106 = lbvtmp.81_26 + lbvtmp.81_31;
D.1394_43 = 5 - lbvtmp.81_106;
D.1395_44 = D.1394_43 * 6;
pretmp.59_117 = D.1395_44 + -7;
pretmp.59_121 = D.1393_41 + -7;
D.1343_45 = pretmp.59_117;
lbvtmp.84_161 = 0;
lbvtmp.84_105 = lnivtmp.75_9;
lbvtmp.84_120 = lbvtmp.84_105 + lbvtmp.84_161;
D.1397_47 = pretmp.59_117 + lbvtmp.84_120;
D.1342_42 = pretmp.59_121;
lbvtmp.83_157 = 0;
lbvtmp.83_158 = lnivtmp.75_9;
lbvtmp.83_159 = lbvtmp.83_157 + lbvtmp.83_158;
D.1398_48 = pretmp.59_121 + lbvtmp.83_159;
D.1399_49 = a[D.1398_48];
b[D.1397_47] = D.1399_49;
lbvtmp.85_125 = 0;
lbvtmp.85_74 = lnivtmp.75_9;
lbvtmp.85_68 = lbvtmp.85_74 + lbvtmp.85_125;
S.3_51 = lbvtmp.85_68 + 1;
lnivtmp.78_3 = lnivtmp.78_8 + 1;
lnivtmp.78_19 = lnivtmp.78_8 + 1;
if (lletmp.80_56 <= lnivtmp.78_19) goto <L12>; else goto <L87>;
<L87>:;
goto <bb 15> (<L15>);
These basic blocks are the only ones that ever mention lnivtmp.78
variable, it is set from a PHI node at L15, but used both in L15
(ok) and also in L13, which isn't dominated by L15 (L13 is where
the loop is entered).
The lnivtmp.78 use before definition is from the bumper statement which is
considered ok by perfect_nest_p. If the bumper SSA_NAME was only used in
the bumper statement and the PHI node, this wouldn't be a big issue, eventhough
lambda_loopnest_to_gcc_loopnest would reference undefined variable, it would
be quickly optimized away (as the bumper would be optimized out as unused)
- ltrans creates new bumper vars, but unfortunately it is used.
I think either perfect_nest_p should only allow bumper variables which are
solely used in the bumper statement and PHI node and nowhere else (this would
cure this case, either it wouldn't be considered valid for ltrans or
perfect_nestify would need to try harder (e.g. by cloning the bumper statement
within the inner loop's body, in the inner loop's body it would set a different
temporary which would be used there and the original bumper var would be only
used outside of inner loop and in the PHI)), or lambda_loopnest_to_gcc_loopnest
needs to be tought to special case stmt_is_bumper_for_loop statements outside
of the innermost loop.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29832
