Re: Initial shrink-wrapping patch

[Richard Sandiford <richard dot sandiford at linaro dot org>]

Bernd Schmidt <bernds_cb1@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