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.
> 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.
> 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.
Jakub
