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. > >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? And if even that is not good enough for any target then that target can elect not to do separate shrink-wrapping at all ;-) > 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. We probably need to be able to calculate that offset at the edges of any BB for other reasons, already. Segher
