Re: [RS6000] PR 80938, Don't emit eh_frame for regs that don't need saving

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Wed, Aug 16, 2017 at 08:05:04AM +0930, Alan Modra wrote:
> Repost with requested changes.  I've extracted the logic that omits
> frame saves from rs6000_frame_related to a new function, because it's
> easier to document that way.  The logic has been simplified a little
> too: fixed_reg_p doesn't need to be called there.
> 
> 	PR target/80938
> 	* config/rs6000/rs6000.c (rs6000_savres_strategy): Revert 2017-08-09.
> 	Don't use store multiple if only one reg needs saving.
> 	(interesting_frame_related_regno): New function.
> 	(rs6000_frame_related): Don't emit eh_frame for regs that
> 	don't need saving.
> 	(rs6000_emit_epilogue): Likewise.

It's not just eh_frame, it's all call frame information.

> +/* This function is called when rs6000_frame_related is processing
> +   SETs within a PARALLEL, and returns whether the REGNO save ought to
> +   be marked RTX_FRAME_RELATED_P.  The PARALLELs involved are those
> +   for out-of-line register save functions, store multiple, and the
> +   Darwin world_save.  They may contain registers that don't really
> +   need saving.  */
> +
> +static bool
> +interesting_frame_related_regno (unsigned int regno)
> +{
> +  /* Saves apparently of r0 are actually saving LR.  */
> +  if (regno == 0)
> +    return true;
> +  /* If we see CR2 then we are here on a Darwin world save.  Saves of
> +     CR2 signify the whole CR is being saved.  */
> +  if (regno == CR2_REGNO)
> +    return true;
> +  /* Omit frame info for any user-defined global regs.  If frame info
> +     is supplied for them, frame unwinding will restore a user reg.
> +     Also omit frame info for any reg we don't need to save, as that
> +     bloats eh_frame and can cause problems with shrink wrapping.
> +     Since global regs won't be seen as needing to be saved, both of
> +     these conditions are covered by save_reg_p.  */
> +  return save_reg_p (regno);
> +}

The function name isn't so great, doesn't say what it does at all.  Not
that I can think of anything better.

Maybe whatever is creating those instructions should set RTX_FRAME_RELATED_P
by itself?  Not sure if that is nicer.

Both this CR2 and R0 handling are pretty nasty hacks.  Could you add a
comment saying that?

Okay for trunk with those improvements (eh_frame and hack comment).
Thanks!


Segher