Re: [PATCH] df: Keep return address register undefined until epilogue_completed

[Jeff Law <law@redhat.com>]

On 08/29/2016 10:50 AM, Segher Boessenkool wrote:
> For separate shrink-wrapping we need to find out which basic blocks
> need what components set up by a prologue, so that we can move those
> prologue pieces deeper into the function, so that those pieces are
> executed less frequently, improving performance.
>
> To do this, target code will normally look at the LIVE info: a block
> needs a register set up if that register is in the IN, GEN, or KILL
> sets.  This works fine for the callee-saved registers, since those
> are not in entry_block_defs, but it does not work for the rs6000 link
> register, because df_get_entry_block_def_set unconditinally adds the
> register that is INCOMING_RETURN_ADDR_RTX (if it is a register).
>
> This patch changes that so that that def is only added after
> epilogue_completed.
>
> With that, in the rs6000 backend we can use the same IN+GEN+KILL
> condition to see whether LR is used (in the current patch set, only
> KILL is used, which isn't correct; the backend can write to LR to
> temporarily hold other values; a crazy idea, on modern hardware anyway,
> but it does regardless).
>
> Does this work on all other targets?  Should anything else be done?
>
>
> Segher
>
>
> 2016-08-29  Segher Boessenkool  <segher@kernel.crashing.org>
>
> 	* df-scan.c (df_get_entry_block_def_set): Do not add the
> 	INCOMING_RETURN_ADDR_RTX register until epilogue_completed.
Right now the dataflow is conservatively correct WRT the return register.

If we made the change you want to make than the dataflow becomes overly 
optimistic about the range over which the return register is live prior 
to inserting the prologue/epilogue into the insn chain.

This seems unsafe to me.
jeff