http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693
Bug #: 54693
Summary: VTA guality issues with loops
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
Something that has been reported privately to me - gcc -g -O2:
__attribute__((noinline, noclone)) void
foo (char *str, char c)
{
asm volatile ("" : : "r" (str), "r" (c) : "memory");
*str = c;
}
int
main ()
{
int i;
char c;
char arr[11];
for (i = 0; i < 10; i++)
{
c = 0x30 + i;
foo (&arr[i], c);
}
__builtin_printf ("arr = %s\n", arr);
return 0;
}
In 4.7.x the c variable in main is available in the whole loop (just not in the
prologue, but that is kind of expected when it is not initialized there), but
the i variable is available only in the prologue (0, correctly) and very short
part of the loop. In 4.8.0
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185129
change made it even worse, the ivopts pass changes there the debug insns for i
to point to D#2 which is initialized to NULL right away.
As for the problem common to 4.7.x and 4.8.0, I think the issue is that vrp1
transforms:
<bb 2>:
# DEBUG i => 0
goto <bb 4>;
<bb 3>:
...
# DEBUG i => i_10
<bb 4>:
# i_1 = PHI <0(2), i_10(3)>
# DEBUG i => i_1
if (i_1 <= 9)
goto <bb 3>;
else
goto <bb 5>;
into:
<bb 2>:
# DEBUG i => 0
goto <bb 6>;
<bb 3>:
# i_16 = PHI <i_1(4), i_14(6)>
...
# DEBUG i => i_10
<bb 4>:
# i_1 = PHI <i_10(3)>
# DEBUG i => i_1
if (i_1 != 10)
goto <bb 3>;
else
goto <bb 5>;
...
<bb 6>:
# i_14 = PHI <0(2)>
# DEBUG i => i_14
goto <bb 3>;
(still fine), but the debug insn no longer references the PHI), then dce1 comes
in, and I guess in some cfg cleanup makes this into:
<bb 2>:
# DEBUG i => 0
# DEBUG i => 0
<bb 3>:
# i_16 = PHI <i_10(3), 0(2)>
...
# DEBUG i => i_10
# DEBUG i => i_10
if (i_10 != 10)
goto <bb 3>;
else
goto <bb 4>;
Note, in neither case ... contains any # DEBUG i => something stmts.
The problem with this is that vrp together with dce transformations effectively
moved the almost the end of the bb only, it is no longer at the start of the
loop where it used to be before the transformations. Would be nice if we could
figure out that for the two blocks we have DEBUG stmts that refer to
corresponding PHI arguments (i_16 above) and that we should insert
# DEBUG i => i_16
at the start of bb 3, because previously if going from bb 2 there is # DEBUG i
=> 0 and if going from bb 3 there is # DEBUG i => i_10.
Alex, what do you think? As for IVOPTS, haven't looked at that at all yet.
