[Bug debug/54693] New: VTA guality issues with loops

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Sep 24 13:41:00 GMT 2012


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: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: aoliva@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.



More information about the Gcc-bugs mailing list