Richard Henderson r...@redhat.com writes:
On 02/05/2014 02:30 PM, Ulrich Weigand wrote:
Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value
On 02/06/2014 01:55 AM, Richard Sandiford wrote:
OK, I agree that's not 4.9 material. What about the other change
of replacing:
REF_CFA_DEF_CFA (plus (stack_pointer_rtx) (const_int 160/96))
with:
REF_CFA_ADJUST_CFA (set (stack_pointer_rtx)
(plus
Richard Henderson r...@redhat.com writes:
On 02/06/2014 01:55 AM, Richard Sandiford wrote:
OK, I agree that's not 4.9 material. What about the other change
of replacing:
REF_CFA_DEF_CFA (plus (stack_pointer_rtx) (const_int 160/96))
with:
REF_CFA_ADJUST_CFA (set
On 02/06/2014 06:48 AM, Richard Sandiford wrote:
Richard Henderson r...@redhat.com writes:
On 02/06/2014 01:55 AM, Richard Sandiford wrote:
OK, I agree that's not 4.9 material. What about the other change
of replacing:
REF_CFA_DEF_CFA (plus (stack_pointer_rtx) (const_int 160/96))
with:
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 12:21:14PM +, Richard Sandiford wrote:
Jakub Jelinek ja...@redhat.com writes:
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 ...))
On Wed, Feb 05, 2014 at 03:32:22PM +, 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
On 02/05/2014 07:58 AM, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 03:32:22PM +, Richard Sandiford wrote:
I think at the moment we're relying on the DW_CFA_offset 15s to
provide correct %r15 values on eh_return. Every non-leaf function
saves the stack pointer and the unwind routines
Richard Henderson r...@redhat.com writes:
On 02/05/2014 07:58 AM, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 03:32:22PM +, Richard Sandiford wrote:
I think at the moment we're relying on the DW_CFA_offset 15s to
provide correct %r15 values on eh_return. Every non-leaf function
saves
Richard Sandiford wrote:
In other words, the reason seemed to be that the _Unwind_SetGRPtr in:
#ifdef EH_RETURN_STACKADJ_RTX
/* Special handling here: Many machines do not use a frame pointer,
and track the CFA only through offsets from the stack pointer from
one frame to the
I wrote and forgot to proof-read:
Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value at function entry,
... CFA is not equal to the *SP* value at function entry ...
but biased by 96/160 bytes. So setting the SP to the CFA
On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value at function entry,
but biased by 96/160 bytes. So setting the SP to the CFA is wrong ...
Such biasing
Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value at function entry,
but biased by 96/160 bytes. So setting the SP to the CFA is wrong
On 02/05/2014 02:30 PM, Ulrich Weigand wrote:
Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
Actually, now I think the problem originally described there is still
valid: on s390 the CFA is *not* equal to the value at function entry,
but biased by 96/160
Sorry, looks like I missed the stage 3 deadline by a day, but:
we'd like to add support for shrink-wrapping and conditional returns
to s390(x) for 4.9. Doing this showed up a problem with the way that
var-tracking handles the load-multiple instruction that s390 uses in
many function epilogues.
On Tue, Feb 04, 2014 at 10:47:49AM +, 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
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 10:47:49AM +, 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
On Tue, Feb 04, 2014 at 11:33:57AM +, Richard Sandiford wrote:
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
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 11:33:57AM +, Richard Sandiford wrote:
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
Jakub Jelinek ja...@redhat.com writes:
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
On Tue, Feb 04, 2014 at 12:21:14PM +, Richard Sandiford wrote:
Jakub Jelinek ja...@redhat.com writes:
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
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 12:21:14PM +, Richard Sandiford wrote:
Jakub Jelinek ja...@redhat.com writes:
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 ...))
On Tue, Feb 04, 2014 at 03:38:51PM +, 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
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 03:38:51PM +, 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
On Tue, Feb 04, 2014 at 04:59:54PM +, Richard Sandiford wrote:
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.
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 04, 2014 at 04:59:54PM +, Richard Sandiford wrote:
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
25 matches
Mail list logo
