On 08/31/11 20:43, Richard Sandiford wrote:
> Bernd Schmidt <ber...@codesourcery.com> writes:
>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>> inconsistent information and aborts.
>>
>> Tested on mips64-elf together with the rest of the shrink-wrapping
>> patches. Ok?
> 
> It looks like the current code doesn't handle the RESTORE instruction.
> Could you also test that somehow?  A mipsisa32-elf run with -mips16
> ought to work, but some sort of spot-checking of shrink-wrapping +
> RESTORE would be fine if that's easier.

Will look into that. You mean the mips16e_build_save_restore function?

> 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:

CC'ing rth, as I'm still not terribly familiar with these issues. I've
tried to follow alpha.c, which seems to ignore this issue.

>> @@ -10324,12 +10330,26 @@ mips_expand_epilogue (bool sibcall_p)
>>        if (!TARGET_MIPS16)
>>      target = stack_pointer_rtx;
>>  
>> -      emit_insn (gen_add3_insn (target, base, adjust));
>> +      insn = emit_insn (gen_add3_insn (target, base, adjust));
>> +      if (!frame_pointer_needed && target == stack_pointer_rtx)
>> +    {
>> +      RTX_FRAME_RELATED_P (insn) = 1;
>> +      add_reg_note (insn, REG_CFA_DEF_CFA,
>> +                    plus_constant (stack_pointer_rtx, step2));
>> +    }

Here, with !frame_pointer_needed, SP should be the CFA register, so if
we modify it we have to use REG_CFA_DEF_CFA. Either that, or I'm confused.

> ?  If the window is significant, could we avoid it by removing the
> !frame_pointer_needed checks from the code above?

That causes aborts due to inconsistent information in dwarf2cfi, since
we can reach the same instruction with either fp or sp as the CFA register.


Bernd

Reply via email to