Jakub Jelinek <ja...@redhat.com> writes:
> On Tue, Feb 04, 2014 at 10:47:49AM +0000, Richard Sandiford wrote:
>> I wondered whether we could model the load of the stack pointer as an
>> addition in cases where that is safe (e.g. it would require !calls_eh_return
>> at least).  But that would only work in functions that don't need a frame
>> pointer.  In functions that do need a frame pointer we'd presumably have
>> (plus (hfp) (const_int X)) instead, which stack_adjust_offset_pre_post
>> would again not understand.
>
> But vt_stack_adjustments is only called if frame pointer isn't used.

Sorry, missed that.

>> Another option would be to work out the offset from REG_CFA_DEF_CFA notes,
>> where present, but I'm a bit uncomfortable with the idea of mixing two
>> different methods of calculating the stack offset.
>
> So, how does the lmg insn look like in RTL dump on some problematic
> testcase?
> insn_stack_adjust_offset_pre_post already uses REG_FRAME_RELATED_EXPR,
> which is also a kind of CFI note (the oldest one), so likely the issue
> is just that it hasn't been adjusted to handle other newer REG_CFA_* notes
> that tell how the stack pointer is adjusted.

It's just a (mem ...) access:

 (parallel
   [...
    (set (reg %r14) (mem:[SD]I (plus (reg ...) (const_int X1))))
    (set (reg %r15) (mem:[SD]I (plus (reg ...) (const_int X2))))])

>> The simplest fix seems to be to disable this check for the exit block.
>> We never use its stack_adjust anyway, and dwarf2cfi already checks
>> (using CFA information) that the offsets in a shrink-wrapped function
>> are consistent.
>> 
>> Tested on s390-linux-gnu and s390x-linux-gnu.  OK to install?
>
> I don't like this, my strong preference is to handle REG_CFA_* notes.

But then we wouldn't be able to use var-tracking when __builtin_eh_return
is used, since in that case replacing the (set (reg ...) (mem ...))
with a (plus ...) would be incorrect -- the value we're loading from the
stack will have had a variable adjustment applied.  And I know from painful
experience that being able to debug the unwind code is very useful. :-)

Thanks,
Richard

Reply via email to