https://bugzilla.novell.com/show_bug.cgi?id=326866#c10
--- Comment #10 from Michael Matz 2007-09-28 13:01:59 MST ---
RTL propagates copies into the asms, hence we have exactly the same problem
as on GIMPLE. It works a bit better because var-tracking is clever, and
hence can work-around some of those propagation, but in the namei.i testcase
the inner 'name' decl (the one for the formal parameter of the inlined
function) was completely gone and had no location list associated. Even
in the -mregparm=3 case it did have a location list, but an incomplete one
(in particular it didn't overlap the special asm).
So we generally also need to avoid propagation into these special asms
on RTL, which the attached patch does. Now it seems to work. At least the
location lists overlap the asms.
Now the problem is, that in instructions where the inner parameter is known
to be in a register the outer parameter isn't anymore, although in reality
both are the same. Perhaps some deficiency in var-tracking. After renaming
the 'name' parameter of real_lookup to '_name' the varloc notes look like so:
(note 452 55 453 10 ( _name (expr_list:REG_DEP_TRUE (reg:SI 5 di
[orig:60 _name] [60]) (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 453 452 454 10 ( name (nil)) NOTE_INSN_VAR_LOCATION)
(note 454 453 455 10 ( nd (nil)) NOTE_INSN_VAR_LOCATION)
(note 455 454 56 10 ( nd (expr_list:REG_DEP_TRUE (reg:SI 4 si
[orig:61 nd ] [61]) (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
Note how _name gets the place of name, which in turn is evicted from it.
Same for 'nd' (these are not the same decls, just named the same).
Theoretically this isn't necessary, as at least in this case they hold
the same value, and hence can both be placed in that register.
That might influence debuggability, or might not. Conceptually during
that instruction the outer 'nd' and 'name' really isn't accessible.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.