Bernd Schmidt <ber...@codesourcery.com> writes:
> 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?
Yeah.
>> 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.
Me too.
>>> @@ -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.
What I meant was: if we can ignore the state between the restoration
of the frame pointer and final stack deallocation, why can't we also
ignore the state between this intermediate deallocation and the final one?
I.e. why isn't it enough to attach a DEF_CFA to the final deallocation only?
In principle, I mean; I realise dwarf2cfi might not like it.
Richard
