[Bug debug/100960] New: var-tracking: parameter location in subregister not tracked

[Bug debug/100960] New: var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

            Bug ID: 100960
           Summary: var-tracking: parameter location in subregister not
                    tracked
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---
            Target: s390x-*-*

Created attachment 50960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50960&action=edit
var-tracking dump

On IBM Z we often have the case that debug information for a parameter points
to the entry value only although the value is held in a register, too.

__attribute__((noinline, noclone)) void
f1 (int x)
{
  __asm volatile ("" : "+r" (x) : : "memory");
}

__attribute__((noinline, noclone)) int
f2 (int x)
{
  f1 (x);
  return x;  // (*)
}

__attribute__((noinline, noclone)) int
f3 (int x)
{
  f2 (x);
  return 3;
}

int
main ()
{
  f3 (42);
  return 0;
}

0x1000600 <f2>          stmg    %r12,%r15,96(%r15)
0x1000606 <f2+6>        lay     %r15,-160(%r15)
0x100060c <f2+12>       lgr     %r12,%r2
0x1000610 <f2+16>       brasl   %r14,0x10005f8 <f1>
0x1000616 <f2+22>       lgr     %r2,%r12
0x100061a <f2+26>       lmg     %r12,%r15,256(%r15)
0x1000620 <f2+32>       br      %r14

At program point (*) debug information for parameter x points to the entry
value only. Thus it gets neglected that the value was moved to call-saved
register r12 prior function call f1.

Having a look at var-tracking this seems to boil down to the fact that register
r2 is saved (lgr %r12,%r2) and restored (lgr %r2,%r12) in DI mode whereas
parameter x has only SI mode and the relation is not tracked. In other words,
for parameter x var-tracking is looking after the function call f1 for an SI
value and doesn't find it although it is a subvalue held in register r12.

Is this a known deficiency or am I missing something?

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
sounds like an implementation oversight to me.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have two different VALUEs here,
(value/u:SI 5:5 @0x4a99810/0x4a402e0)
 locs:
  from insn 1 (value/u:SI 6:261 @0x4a99828/0x4a40310)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ x ]))
  from insn 1 (reg:SI 2 %r2 [ x ])
 no addrs
and
(value/u:DI 15:15 @0x4a99900/0x4a404c0)
 locs:
  from insn 17 (reg:DI 12 %r12 [63])
  from insn 17 (reg:DI 2 %r2 [ x+-4 ])
 no addrs
and cselib doesn't record that when insn 17 copies the 15:15 value to a new
location it effectively copies also the 5:5 value which is present in its low
bits.
Maybe it would be better to record among the locs of 5:5 that it is equivalent
to
lowpart subreg of (value:DI 15:15), perhaps at the point where the value 15:15
is created or so?

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly related was
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-03/msg01379.html
So, perhaps for the case where we do not track the source register in the wider
mode we could for var-tracking purpose also pretend the move is not a DImode
copy, but a SImode copy.
But what I wrote above is also an option, record permanent equivalency that the
narrower value is lowpart subreg of the wider value.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

--- Comment #4 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
I really like the idea of enhancing cselib since there is a chance that other
passes might profit from it, too. The following patch fixes the initial
reported problem:

diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 6a5609786fa..64b6996a299 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -1569,6 +1569,25 @@ new_cselib_val (unsigned int hash, machine_mode mode,
rtx x)
   e->locs = 0;
   e->next_containing_mem = 0;

+  scalar_int_mode int_mode;
+  if (REG_P (x) && is_int_mode (mode, &int_mode) && REG_VALUES (REGNO (x)) !=
NULL
+      && (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
+    {
+      rtx copy = shallow_copy_rtx (x);
+      scalar_int_mode narrow_mode;
+      FOR_EACH_MODE_UNTIL(narrow_mode, int_mode)
+       {
+         PUT_MODE_RAW (copy, narrow_mode);
+         cselib_val *v = cselib_lookup (copy, narrow_mode, 0, VOIDmode);
+         if (v)
+           {
+             rtx sub = lowpart_subreg (narrow_mode, e->val_rtx, int_mode);
+             if (sub)
+               new_elt_loc_list (v, sub);
+           }
+       }
+    }
+
   if (dump_file && (dump_flags & TDF_CSELIB))
     {
       fprintf (dump_file, "cselib value %u:%u ", e->uid, hash);

So I get the subvalue relation between 5:5 and 14:14 (was initially 15:15 but
changed meanwhile due to new GCC version)

(value/u:SI 5:5 @0x4f906e0/0x4f80730)
 locs:
  from insn 17 (subreg:SI (value/u:DI 14:14 @0x4f907b8/0x4f808e0) 4)
  from insn 1 (value/u:SI 6:263 @0x4f906f8/0x4f80760)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
 no addrs

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

--- Comment #5 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
However, I found another example (see attachment a-t2.c.325r.vartrack) which
does not profit from the patch:

__attribute__((noinline, noclone)) void
fn1 (int x)
{
  __asm volatile ("" : "+r" (x) : : "memory");
}

__attribute__((noinline, noclone)) int
fn2 (int x, int y)
{
  if (x)
    {
      // x is copied into call-saved r11
      fn1 (x);
      // locs of x point to entry value only
      // ignoring r11
      fn1 (x);
    }
  return y;
}

__attribute__((noinline, noclone)) int
fn3 (int x, int y)
{
  return fn2 (x, y);
}

int
main ()
{
  fn3 (36, 25);
  return 0;
}

For fn2 the value for parameter x is 5:5

cselib hash table:
...
(value/u:SI 5:5 @0x5fb9420/0x5f5e600)
 locs:
  from insn 1 (value/u:SI 6:263 @0x5fb9438/0x5f5e630)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
  from insn 1 (reg:SI 2 %r2 [ xD.2274 ])
 no addrs

which is recorded in bb 2. In bb 4 (the true branch of the if) register r2 is
saved in r11:

bb 4 op 0 insn 36 MO_VAL_USE (concat/v:DI (value/u:DI 26:26
@0x5fb9618/0x5f5e9f0)
        (reg:DI 2 %r2 [64]))
bb 4 op 1 insn 36 MO_VAL_SET (concat/u:DI (value/u:DI 26:26
@0x5fb9618/0x5f5e9f0)
        (set (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
            (reg:DI 2 %r2 [64])))
(insn 36 10 11 4 (set (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
        (reg:DI 2 %r2 [64])) 1472 {*movdi_64}
     (nil))
cselib hash table:
(value/u:DI 26:26 @0x5fb9618/0x5f5e9f0)
 locs:
  from insn 36 (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
  from insn 36 (reg:DI 2 %r2 [64])
 no addrs
cselib preserved hash table:
...
(value/u:SI 5:5 @0x5fb9420/0x5f5e600)
 locs:
  from insn 1 (value/u:SI 6:263 @0x5fb9438/0x5f5e630)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
 no addrs

However at bb 4 the relation between r2 and value 5:5 is lost (except the entry
value relation). Thus I cannot record the subvalue relation between 5:5 and
26:26 at least not during creation of 26:26. Since cselib resets its table
after jumps I'm not sure how to proceed here. Any ideas?

I would be also up for the second idea and pretend that the move is not a
DImode copy but a SImode copy. However, I'm not sure how to look up the mode of
the actual type. Any pointers?

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960

--- Comment #6 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
Created attachment 53433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53433&action=edit
a-t2.c.325r.vartrack