This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] rs6000: Use SAVE_MULTIPLE only if we restore what it saves (PR80938)
- From: Alan Modra <amodra at gmail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Thu, 10 Aug 2017 10:33:05 +0930
- Subject: Re: [PATCH] rs6000: Use SAVE_MULTIPLE only if we restore what it saves (PR80938)
- Authentication-results: sourceware.org; auth=none
- References: <21f6fe5be45ca917a46e204c4382c67ebfbb742f.1502310090.git.segher@kernel.crashing.org>
On Wed, Aug 09, 2017 at 09:06:18PM +0000, Segher Boessenkool wrote:
> We can have SAVE_MULTIPLE while we do not have REST_MULTIPLE. If the
> inline restore does not restore all registers, the CFI for the save
> and restore can conflict if things are shrink-wrapped.
>
> We could restore all registers that are saved (not ideal),
No, we can't do that. A -ffixed-reg register should not be restored
even if it is saved, as such regs should never be written. For
example, a fixed reg might be counting interrupts. If you restore it,
you may lose count. Another example is a fixed reg used as some sort
of context pointer. If you restore in a function that sets a new
context you're obviously breaking user code.
> or emit
> the CFI notes to say we did (which will work fine,
No, you can't do that either. Unwinding might then restore a
-ffixed-reg register.
> but is also not
> so great); instead, let's not save the registers that are unused.
Ick, looks like papering over the real problem to me, and will no
doubt cause -Os size regressions. Also, if SAVE_MULTIPLE causes this
bad interaction with shrink-wrap, does using the out-of-line register
save functions cause the same problem?
I haven't looked yet, but at a guess I suspect the correct solution is
to modify cfa_restores in rs6000_emit_epilogue.
--
Alan Modra
Australia Development Lab, IBM