[Bug debug/60756] New: var-tracking selects wrong registers

["rth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 60756
           Summary: var-tracking selects wrong registers
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rth at gcc dot gnu.org

The smallest example I can find is gcc.dg/guality/param-3.c.

The parameter "str" is passed in x0+x1, and immediately copied into
the call-saved registers x22+x23, where they stay for the duration
of the function.

But var-tracking works (or appears to work) back-to-front, taking
the location of the variable from the src rather than the dest of
a copy.  Thus we get

(note 43 1 44 (var_location str (reg:TI 0 x0 [ str ])) NOTE_INSN_VAR_LOCATION)
...
(note 35 34 28 NOTE_INSN_PROLOGUE_END)
(insn 28 35 46 (set (reg:DI 22 x22 [orig:75 str ] [75])
        (reg:DI 0 x0 [ str ])) z.c:18 34 {*movdi_aarch64}
     (expr_list:REG_DEAD (reg:DI 0 x0 [ str ])
        (nil)))
(note 46 28 29 (var_location str (reg:TI 0 x0 [ str ])) NOTE_INSN_VAR_LOCATION)
(insn 29 46 3 (set (reg:DI 23 x23 [ str+8 ])
        (reg:DI 1 x1 [ str+8 ])) z.c:18 34 {*movdi_aarch64}
     (expr_list:REG_DEAD (reg:DI 1 x1 [ str+8 ])
        (nil)))
...
(insn 8 5 47 (set (reg:SI 0 x0)
        (reg:SI 2 x2 [orig:76 a ] [76])) z.c:19 33 {*movsi_aarch64}
     (nil))
(note 47 8 9 (var_location str (nil)) NOTE_INSN_VAR_LOCATION)
...
(note 53 16 26 (var_location str (nil)) NOTE_INSN_VAR_LOCATION)
(insn 26 53 54 (set (reg:DI 0 x0)
        (reg:DI 22 x22 [orig:75 str ] [75])) z.c:21 34 {*movdi_aarch64}
     (expr_list:REG_DEAD (reg:DI 22 x22 [orig:75 str ] [75])
        (nil)))
(note 55 54 27 (var_location str (reg:TI 22 x22 [orig:75 str ] [75]))
NOTE_INSN_VAR_LOCATION)

where we have the initial prologue describing str as residing in x0,
a clobber of x0 and the death of str, then the copy of str back to
an outgoing parameter and suddenly str is once again live in x22.

At minimum it would seem that taking DECL_RTL into account when
examining these assignments would be a good start.  When copying into
its canonical location, it would seem a great time to alter the
live range.