On 09/05/2011 01:36 PM, Richard Sandiford wrote: > Richard Henderson <r...@redhat.com> writes: >> On 09/01/2011 12:13 AM, Richard Sandiford wrote: >>> Also, for the frame_pointer_required case, it looks like there's a >>> window between the restoration of the frame pointer and the deallocation >>> of the stack in which the CFA is still defined in terms of the frame >>> pointer register. Is that significant? If not (e.g. because we >>> should never need to unwind at that point) then why do we still >>> update the CFA here: >> >> What window are you referring to? >> >> Best I can tell from looking at the patch we restore the CFA to the >> stack pointer before anything else. > > Well, I'm probably showing my ignorance here, but what I meant was: > we attach the DEF_CFA and the CFA_RESTORE notes to the final stack > deallocation. I was just worried that, immediately before that > deallocation, the CFA is still defined in terms of the frame pointer, > even though the frame pointer has already been restored. So it seemed > like someone trying to unwind at that point would get the wrong CFA.
I don't see that. I'm pasting from mainline but not the patch, but here: > /* Copy TARGET into the stack pointer. */ > if (target != stack_pointer_rtx) > mips_emit_move (stack_pointer_rtx, target); We restore the stack pointer from the frame pointer before restoring the frame pointer. The patch changes this spot with DEF_CFA. So the problem you're suggesting ought not be true. r~
