Bernd Schmidt <bernds_...@t-online.de> writes:
>>> +/* Return true if INSN requires the stack frame to be set up.
>>> + PROLOGUE_USED contains the hard registers used in the function
>>> + prologue. */
>>> +static bool
>>> +requires_stack_frame_p (rtx insn, HARD_REG_SET prologue_used)
>>> +{
>>> [...]
>>> + if (for_each_rtx (&PATTERN (insn), frame_required_for_rtx, NULL))
>>> + return true;
>>> + CLEAR_HARD_REG_SET (hardregs);
>>> + note_stores (PATTERN (insn), record_hard_reg_sets, &hardregs);
>>> + if (hard_reg_set_intersect_p (hardregs, prologue_used))
>>> + return true;
>>> + AND_COMPL_HARD_REG_SET (hardregs, call_used_reg_set);
>>> + for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
>>> + if (TEST_HARD_REG_BIT (hardregs, regno)
>>> + && df_regs_ever_live_p (regno))
>>> + return true;
>>
>> ...I suppose this ought to use DF instead.
>
> Here, I kind of disagree. Most of the new code works on unemitted
> sequences, and df doesn't work for that, so we rely on note_stores and
> such quite a lot. I've changed the one note_stores call in this function
> to use df, but IMO it's not an improvement. As for
> frame_required_for_rtx, I'd much rather test for equality with
> hard_frame_pointer_rtx than muck about with register numbers and
> frame_pointer_needed tests.
Seems like checking for HARD_FRAME_POINTER_REGNUM would be OK regardless.
Even if it isn't being used as a frame pointer, the hard frame pointer
still needs to be saved and restored, so references would still need the
protection of the prologue. I don't know off-hand whether targets like
AVR ever need to generate QImode parts of the frame pointer (in which
case checking for register numbers seems like the right thing).
But I agree it's borderline, so I won't insist.
> Also, it turns out I need to pretend that trap_if requires the prologue
> due to the testcase you also ran across, so a for_each_rtx walk is
> required anyway.
Why does TRAP_IF inherently need a prologue though? The CFA information
should be correct regardless. Do we really want this behaviour for
conditional TRAP_IFs, such as you might get to trap division by zero?
Seems odd to treat explicit traps (on architectures that need them)
differently from a plain div (in cases where that traps).
Richard
