[Bug debug/54551] New: DF resets some DEBUG_INSNs unnecessarily

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551

             Bug #: 54551
           Summary: DF resets some DEBUG_INSNs unnecessarily
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: aoliva@gcc.gnu.org, hubicka@gcc.gnu.org,
                    jan.kratochvil@redhat.com, mark@gcc.gnu.org,
                    rguenth@gcc.gnu.org
        Depends on: 54519


+++ This bug was initially created as a clone of Bug #54519 +++

Several of the PR54519 tests fail.  The problem can be reproduced even without
any partial inlining though, e.g. on:
void bar (void);

int
foo (int x, int y, int z)
{
  if (x != z)
    {
      int a = z + 8;
      bar ();
      bar ();
    }
  return y;
}
at -g -O2.  At *.dfinit we still have:
(insn 4 3 5 2 (set (reg/v:SI 62 [ z ])
        (reg:SI 1 dx [ z ])) vu.c:5 65 {*movsi_internal}
     (nil))
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:SI 60 [ x ])
            (reg/v:SI 62 [ z ]))) vu.c:6 7 {*cmpsi_1}
     (nil))
(jump_insn 9 8 10 2 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 14)
            (pc))) vu.c:6 595 {*jcc_1}
     (expr_list:REG_BR_PROB (const_int 3784 [0xec8])
        (nil))
 -> 14)
(note 10 9 11 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(debug_insn 11 10 12 3 (var_location:SI a (plus:SI (reg/v:SI 62 [ z ])
        (const_int 8 [0x8]))) vu.c:8 -1
     (nil))
but during CSE1 when fast DCE is performed, the debug insn for a is reset, as
pseudo 62 isn't live in that basic block.  We have the valtrack.c
infrastructure for this kind of things, but that apparently works only within
basic blocks, while in this case we have a BB (2) where the pseudo dies and a
BB (3) that is dominated by that BB and has a debug insn using that pseudo.
Perhaps in further RTL passes that use DF that is sufficient, but the first
time DF liveness is computed as this testcase or PR54519 shows we drop on the
floor debug insns that could still refer to debug temporaries if we initialized
them in the bbs where they die and that dominate the debug uses.  For this
particular testcase it could still live in %edx on the first call bar insn,
then in DW_OP_GNU_entry_value (%edx).

Alex, what do you think about this?