Re: var-tracking and s390's LM(G)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Feb 05, 2014 at 03:32:22PM +0000, Richard Sandiford wrote:
> > In a function that doesn't need frame pointer, I'd say this is a serious
> > bloat of the unwind info, you are saving/restoring %r15 not because you have
> > to, but just that it seems to be cheaper for the target.  So, I'd say you
> > shouldn't emit DW_CFA_offset 15, 5 on the insn 122 in the prologue and
> > DW_CFA_restore 15 in the epilogue (twice in this case), that just waste
> > of .eh_frame/.debug_frame space.  I'd say you should represent in
> > this case the *store_multiple_di as REG_FRAME_RELATED_EXPR
> > with all but the last set in the PARALLEL, and on the *load_multiple_di
> > remove REG_CFA_RESTORE (r15) note and change REG_CFA_DEF_CFA note to
> > REG_CFA_ADJUST_CFA note which would say that stack pointer has been
> > incremented by 160 bytes (epilogue expansion knows that value).
> 
> I think at the moment we're relying on the "DW_CFA_offset 15"s to
> provide correct %r15 values on eh_return.  Every non-leaf function
> saves the stack pointer and the unwind routines track the %r15 save
> slots like they would track any call-saved register.  In other words,
> the final eh_return %r15 comes directly from a save slot, without any
> CFA-specific handling.  If some frames omit the CFI for the %r15 save
> then we'll just keep the save slot from the previous (inner) frame instead.

CCing Richard Henderson into the discussion.

> The new unwind routines would handle 4.9+ and pre-4.9 frames, but pre-4.9
> unwind routines wouldn't handle 4.9+ frames, so would that require a version
> bump on the unwind symbols?

No need to version anything IMHO.  We've never done that for any port
where we've started to emit something the old unwinder wouldn't cope with,
it is user's responsibility to use new enough libgcc_s.

BTW, what is the reason why %r15 is saved/restored from the stack at all say
for simple:
void
foo (void)
{
  int a = 6;
  asm volatile ("# %0" : "+m" (a));
}

Is that some ABI matter where it effectively always uses requires to use
some kind of frame pointer (which the saved previous stack pointer is)?
It can surely make debugging without unwind info easier, ditto backtraces,
on the other side it must have a runtime cost.

	Jakub