On 09/09/2016 09:04 AM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 12:58:11PM +0200, Bernd Schmidt wrote:
Hmm? The problem is that you can't generally emit a save/restore
independent of placement, because you may not know which offset to use
from whichever base register. But these offsets aren't necessarily
constant throughout the function. Segher explained that the algorithm
deals with this by giving up in many cases, which of course limits the
usefulness. It probably makes it unusable entirely on targets that want
to use pushes for function args.
It's not the generic algorithm that gives up; it's the target hook.
Specifically, at least for the PowerPC one I wrote, the
TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS hook gives up on register
components that need an offset from the base reg (stack or frame pointer)
that cannot be used in a single instruction (i.e. won't fit in 16 bits).
The generic code only does
+ /* We don't handle "strange" functions. */
+ if (cfun->calls_alloca
+ || cfun->calls_setjmp
+ || cfun->can_throw_non_call_exceptions
+ || crtl->calls_eh_return
+ || crtl->has_nonlocal_goto
+ || crtl->saves_all_registers)
+ return;
so that does not give up in "many" cases.
Doesn't seem like a lot to me either.
Targets that push function args can handle things fine as far as I see?
Targets that normally use push insns in the prologue will just have to
not do that for the components that are separately wrapped. Or they can
still use pushes to reserve that space, if that works better.
To me it's more about the fact that the offset to the slot where the
register should be saved varies (unless you have a frame pointer) and I
don't think there's enough information in any of the hook arguments to
allow derivation of that offset.
But I don't consider that a flaw that should block this feature. If
someday we want to implement on such a target, we'll have to figure out
how to compute that offset at an arbitrary location and pass along the
needed information to the hooks.
jeff
