[Bug debug/43077] New: VTA issues caused by SSA expand

[Bug debug/43077] New: VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

In the following testcase in both foo and baz functions var[abc] debuginfo
is lost during SSA expansion (unlike e.g. with redhat/gcc-4_4-branch VTA which
doesn't do SSA expansion):

int varb;

int __attribute__((noinline))
foo (void)
{
  int vara = (varb == 3);
  asm volatile ("" : : "g" (vara));
  return 0;
}

int __attribute__((noinline))
bar (unsigned long *p, unsigned long *q)
{
  int ret;
  asm volatile ("" : "=r" (ret), "=r" (*p), "=r" (*q) : "0" (1), "1" (2), "2"
(3));
  return ret;
}

int __attribute__((noinline))
baz (void)
{
  unsigned long a = 0, b = 0, c = 0;
  a = bar (&b, &c);
  unsigned long vara = a;
  unsigned long varb = b;
  unsigned long varc = c;
  __asm__ volatile ("" : : "g" (vara), "g" (varb), "g" (varc));
  return a;
}

int
main (void)
{
  foo ();
  baz ();
  return 0;
}
In *.optimized we have on redhat/gcc-4_4-branch:
foo
  # DEBUG vara => varb == 3
  __asm__ __volatile__("" :  : "g" varb == 3);
baz:
  D.1615D.1615 = bar (&b, &c);
  # DEBUG D#1 => (long unsigned int) D.1615D.1615
  # DEBUG a => D#1
  # DEBUG vara => D#1
  # DEBUG D#2 => b
  # DEBUG varb => D#2
  # DEBUG D#3 => c
  # DEBUG varc => D#3
  __asm__ __volatile__("" :  : "g" (long unsigned int) D.1615D.1615, "g" b, "g"
c);
and on the trunk:
foo:
  varb.0_1 = varb;
  vara_2 = varb.0_1 == 3;
  # DEBUG vara => vara_2
  __asm__ __volatile__("" :  : "g" vara_2);
baz:
  D.2742_2 = bar (&b, &c);
  a_3 = (long unsigned int) D.2742_2;
  # DEBUG a => a_3
  # DEBUG vara => a_3
  varb_5 = b;
  # DEBUG varb => varb_5
  varc_6 = c;
  # DEBUG varc => varc_6
  __asm__ __volatile__("" :  : "g" a_3, "g" varb_5, "g" varc_6);
On redhat/gcc-4_4-branch then expansion has debug insns which still track where
the variables really live:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (eq:SI (mem/c/i:SI
(symbol_ref:DI ("varb")  <var_decl 0x7f668363e820 varb>) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI D.4294967295 (zero_extend:DI
(reg:SI 58 [ D.1615 ]))) -1 (nil))
(debug_insn 15 14 16 3 P.c:23 (var_location:DI a (debug_expr:DI D#1)) -1 (nil))
(debug_insn 16 15 17 3 P.c:24 (var_location:DI vara (debug_expr:DI D#1)) -1
(nil))
(debug_insn 17 16 18 3 P.c:25 (var_location:DI D.4294967294 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8 [0xfffffffffffffff8]))
[3 b+0 S8 A64])) -1 (nil))
(debug_insn 18 17 19 3 P.c:25 (var_location:DI varb (debug_expr:DI D#2)) -1
(nil))
(debug_insn 19 18 20 3 P.c:26 (var_location:DI D.4294967293 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -16 [0xfffffffffffffff0]))
[3 c+0 S8 A64])) -1 (nil))
(debug_insn 20 19 21 3 P.c:26 (var_location:DI varc (debug_expr:DI D#3)) -1
(nil))
but on the trunk in *.expand we have:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (reg/v:SI 59 [ vara ])) -1
(nil))
(insn 6 5 7 3 P.c:7 (set (reg:CCZ 17 flags) (compare:CCZ (mem/c/i:SI
(symbol_ref:DI ("varb")  <var_decl 0x7f158a318000 varb>) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
(insn 7 6 8 3 P.c:7 (set (reg:QI 62) (eq:QI (reg:CCZ 17 flags) (const_int 0
[0x0]))) -1 (nil))
(insn 8 7 9 3 P.c:7 (parallel [(set (reg:SI 61) (zero_extend:SI (reg:QI 62)))
(clobber (reg:CC 17 flags))]) -1 (nil))
(insn 9 8 10 3 P.c:7 (parallel [(asm_operands/v ("") ("") 0 [(reg:SI 61)]...
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI a (reg/v:DI 59 [ a ])) -1 (nil))
(debug_insn 15 14 16 3 P.c:24 (var_location:DI vara (reg/v:DI 59 [ a ])) -1
(nil))
(debug_insn 16 15 17 3 P.c:25 (var_location:DI varb (reg/v:DI 60 [ varb ])) -1
(nil))
(debug_insn 17 16 18 3 P.c:26 (var_location:DI varc (reg/v:DI 61 [ varc ])) -1
(nil))
(insn 18 17 19 3 P.c:27 (set (reg:DI 65) (sign_extend:DI (reg:SI 58 [ D.2742
]))) -1 (nil))
(insn 19 18 20 3 P.c:27 (parallel [(asm_operands/v ("") ("") 0 [(reg:DI 65)
(mem/c/i:DI (plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8
[0xfffffffffffffff8])) [3 b+0 S8 A64]) (mem/c/i:DI (plus:DI (reg/f:DI 54
virtual-stack-vars) (const_int -16 [0xfffffffffffffff0])) [3 c+0 S8 A128])]...

The problem is that pseudo 59 in foo resp. pseudos in 59/60/61 in baz are only
referenced in the debug_insns, never initialized or used in actual code and
therefore are pretty soon just changed into (clobber (const_int 0)).  I believe
this is because SSA expansion in some cases (e.g. for the asm operand "g") does
a TER, so DECL_RTL of the SSA_NAME isn't actually used.  I guess we'd need to
TER in this case also into the DEBUG_INSN locations, but not sure when exactly
to do that.

This is quite important e.g. for SystemTap, as asm "g" input operands with some
short lived vars in a macro is something that is used in user probes, and
SystemTap then expects to find the values of those vars in the debuginfo.


-- 
           Summary: VTA issues caused by SSA expand
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #1 from matz at gcc dot gnu dot org  2010-02-18 15:13 -------
Created an attachment (id=19910)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19910&action=view)
candidate fix

Try this.  I don't know how to write guality tests, but I think it has the 
effects you look for, at least the debug_insn now refer to existing things.


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2010-02-18 15:46 -------
Created an attachment (id=19913)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19913&action=view)
gcc45-pr43077-test.patch

Here is a guality testcase for it.  Before the patch there is just lots of
FAILs, with the patch most of them are gone on both x86_64-linux -m64 and -m32,
though not all.  Will look at those later, I have Alex have some pending
patches so will also try with them.  So the patch looks good, at least on this
testcase.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #3 from matz at gcc dot gnu dot org  2010-02-18 16:12 -------
At least varb isn't printed in fn3, because dse2 (after prologue_epilogue)
makes the expressions in the debug_insn be (clobber 0).  Presumably because
frame elimination rewrites the address-takings, but not the debug instructions,
hence it thinks they are uninited stores, as they still refer
to the frame pointer, not the stack pointer.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #4 from matz at gcc dot gnu dot org  2010-02-18 16:40 -------
Created an attachment (id=19916)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19916&action=view)
do reg elimination

This will fix some more of the var[bc] references by eliminating
all registers in DEBUG_INSN_P.  As I'm ignoring DEBUG_INSNs for effects that
might change elimination results, this should not result in code changes.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #5 from matz at gcc dot gnu dot org  2010-02-18 16:50 -------
That leaves 'c' which isn't printed, because the setup of c (a stackslot)
is schedules to be part of the function call setup, the breakpoint is before
that setup, and hence the location of 'c' does point to the correct one
(namely its stackslot), but that one isn't initialized yet.  One problem might
be that there's no DEBUG_BIND insn generated for c at all.  Or alternatively,
once the stack slot initialization is moved down that no debug_insn is
generated at it's original place to refer to the value 0.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2010-02-18 19:49 -------
I doubt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077#c4 applies cleanly to
the current tree, as
http://gcc.gnu.org/viewcvs?view=revision&revision=156693
changed the same spot as the second hunk.  Will need to see why
eliminate_regs_in_insn doesn't eliminate those.

Regarding a/b/c on the a = foo (&b, &c) line, it is true that the breakpoint on
that line might be on some insn that is scheduled earlier than b = 0 resp. c =
0 store.  Perhaps we could have a DEBUG_INSN very early at the spot where the
variable appear in the scope that would tell the value is 0, but I guess that
should be handled separately from that, so I'll nuke that from the testcase for
now.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-02-19 09:49 -------
Created an attachment (id=19919)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19919&action=view)
gcc45-pr43077-test.patch

Updated test, let's move the initialization before call scheduling issue into a
separate enhancement request.  Your reg elimination patch is not needed, you
probably haven't updated your tree for a few days.  The reason for the
varb/varc failures on i686 seems to be a var-tracking bug (the DEBUG_INSNS in
*.compgotos are still ok, debugging it now).


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19913|0                           |1
        is obsolete|                            |


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2010-02-19 11:23 -------
Details for Alex:
/* { dg-options "-m32 -O2 -g -march=i386 -mtune=generic -dA" } */
int foo (unsigned long *);
int
fn3 (void)
{
  unsigned long a = 0, b = 0;
  a = foo (&b);
  unsigned long varb = b;
  asm volatile ("" : : "g" (varb));
  return a;
}
This has just one bb (plus the special 2), so this is not a bug in
vt_find_locations stuff and is not related to the sp issues either.
At the end of the bb we have:
  name: varb D.1234
    offset 0
      (value/s/u:SI 7:7 @0x1eeca58/0x1eec760)
 (value/s/u:SI 7:7 @0x1eeca58/0x1eec760)
    offset 0
      (mem/c/i:SI (value/s/u:SI 5:3926 @0x1eeca28/0x1eec7f0) [2 bD.1233+0 S4
A32])
but value 5:3926 is not in the hash table (and that's the reason why
var_location for varb is
(note 38 37 13 (var_location varb (nil)) NOTE_INSN_VAR_LOCATION)
) - it is not in the hash table even at the spot where the DEBUG_INSN for varb
has its uops.  varb is present at bp - 12.  Before the call there is
(insn:TI 25 29 6 pr43077.c:7 (set (reg/f:SI 0 ax [61])
        (plus:SI (reg/f:SI 6 bp)
            (const_int -12 [0xfffffffffffffff4]))) 247 {*lea_1} (nil))
...
(insn:TI 8 36 9 pr43077.c:7 (set (mem/f/i:SI (reg/f:SI 7 sp) [0 S4 A32])
        (reg/f:SI 0 ax [61])) 47 {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[61])
        (expr_list:REG_EQUAL (plus:SI (reg/f:SI 20 frame)
                (const_int -4 [0xfffffffffffffffc]))
            (nil))))
value 5:3926 is apparently created while processing insn 25, and during
processing uops for insn 25 value 5:3926 is added to the hash table, with %eax
as the (only) location.  But of course when processing the call
dataflow_set_clear_at_call nukes it, as %eax is cloberred, thus value 5:3926
has no locations and is nuked from the hash table.  When emitting varb location
note, it doesn't find that VALUE in the hash table, so doesn't know that value
5:3926 is actually ebp - 12.  Not sure what is so different for 64-bit
compilation that it figures it out.

For Michael: if you have bootstrapped/regtested your patch, please submit it to
gcc-patches anyway, this will be hopefully resolved afterwards.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2010-02-19 12:32 -------
Initialization before call issue moved to PR43119.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #10 from matz at gcc dot gnu dot org  2010-02-19 12:33 -------
Okay.  You were right, my tree was a outdated.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2010-02-23 14:24 -------
To emit an extra DEBUG_INSN to a D# temporary and using that D# temporary you'd
need to know where exactly to insert the DEBUG_INSN.  I guess we'd need to
remember for MAY_HAVE_DEBUG_INSNS a mapping from each of the SSA names in
SA.values to the insn stream right before first rtl expanded from that
statement.


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #12 from matz at gcc dot gnu dot org  2010-02-23 14:31 -------
Yeah, I have a patch already which emits it before the last real use of an
SSA name (which by design of TER is a point where all constituent
subexpressions still have their correct value).


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #13 from matz at gcc dot gnu dot org  2010-02-23 16:42 -------
Subject: Bug 43077

Author: matz
Date: Tue Feb 23 16:41:52 2010
New Revision: 157009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157009
Log:
        PR debug/43077
        * cfgexpand (expand_debug_expr): Expand TERed ssa names in place.
        (expand_gimple_basic_block): Generate and use debug temps if there
        are debug uses left after the last real use of TERed ssa names.
        Unlink debug immediate uses when they are expanded.

testsuite/
        PR debug/43077
        * gcc.dg/guality/pr43077-1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr43077-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43077] VTA issues caused by SSA expand

[matz at gcc dot gnu dot org]

------- Comment #14 from matz at gcc dot gnu dot org  2010-02-23 16:46 -------
Fixed.


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug debug/43077] VTA issues caused by SSA expand

[hjl dot tools at gmail dot com]

------- Comment #15 from hjl dot tools at gmail dot com  2010-02-23 22:04 -------
The new testcase failed on Fedora 12/i686:

FAIL: gcc.dg/guality/pr43077-1.c  -O2  line 42 varb == 2
FAIL: gcc.dg/guality/pr43077-1.c  -O2  line 42 varc == 3
FAIL: gcc.dg/guality/pr43077-1.c  -O2 -flto  line 42 varb == 2
FAIL: gcc.dg/guality/pr43077-1.c  -O2 -flto  line 42 varc == 3
FAIL: gcc.dg/guality/pr43077-1.c  -O2 -fwhopr  line 42 varb == 2
FAIL: gcc.dg/guality/pr43077-1.c  -O2 -fwhopr  line 42 varc == 3
FAIL: gcc.dg/guality/pr43077-1.c  -O3 -g  line 42 varb == 2
FAIL: gcc.dg/guality/pr43077-1.c  -O3 -g  line 42 varc == 3
FAIL: gcc.dg/guality/pr43077-1.c  -Os  line 42 varb == 2
FAIL: gcc.dg/guality/pr43077-1.c  -Os  line 42 varc == 3


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


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

[Bug debug/43077] VTA issues caused by SSA expand

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2010-02-23 22:32 -------
That doesn't mean this bug isn't fixed.  It is.  There are just additional
issues, during var-tracking, in particular PR43051.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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