var-tracking and s390's LM(G)

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> writes:
> On Tue, Feb 04, 2014 at 03:38:51PM +0000, Richard Sandiford wrote:
>> What do you want var-tracking to do about the __builtin_eh_return case
>> though?  It isn't correct to say that the instruction adds the frame size
>> to the stack pointer then, since the loaded value includes the eh_return
>> adjustment.  Pretending it is a constant addition in order to satisfy the
>> sanity check seems a bit hackish, but there again it'd be a shame to lose
>> tracking for the whole function just because of that.
>
> For __builtin_eh_return the unwind info starting with restoring the stack
> pointer to the landing pad's stack pointer until you actually return/jump to the
> landing pad is wrong in either case, not just on s390, but on various other
> targets.  Saying REG_CFA_ADJUST_CFA by the frame size will result in CFA
> from that point being stack_pointer + 160, which is exactly what you are
> doing anyway, the DW_CFA_offset 15, ... and DW_CFA_restore aren't helpful to
> that at all and don't change anything on it.
>
> Unless you have the old value of the stack pointer saved in some hard
> register, providing correct unwind info there is not possible.

Right, that was my point.  So by relying on unwind info in var-tracking.c
we're getting the wrong answer for the stack offset after the LM(G)
instruction.  It sounds like we're going to pretend it's right anyway
for expediency.  But in that case why not also allow the exit block
offsets to vary on the same basis?  It's not like the current test is
an assert -- it's just silently refusing to do any var-tracking on the
function if the epilogue isn't fully understood.

If these offsets must match on exit for correctness then we should
assert rather than silently bailing out.  But if they're allowed to vary
then we should do our best to carry on.  And since the exit block offset
is never used, it seems expedient to allow varying offsets in that case.

Thanks,
Richard