Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

[Jeff Law <law at redhat dot com>]

On 09/09/2016 02:33 PM, Segher Boessenkool wrote:
> On Fri, Sep 09, 2016 at 12:28:12PM -0600, Jeff Law wrote:
> > > 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.
>
> A few of those could be handled, perhaps with some extra hooks, but it
> didn't look useful to me so far.
Agreed.  I don't think this is worth spending time on.


> > > 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.
>
> I think knowing in front of what BB to insert the prologue (or after what
> BB, the epilogue) is all info we need?
Maybe.  I'd be worried about things like deferred pops and 
combine-stack-adjustments.  The former are probably OK as I suspect we 
cleaned things up at basic block boundaries.  The latter I've never 
really looked at.

> And if even that is not good enough for any target then that target can
> elect not to do separate shrink-wrapping at all ;-)
Exactly.

Jeff