This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RS6000] PR 80938, Don't emit eh_frame for regs that don't need saving
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