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 09:33 AM, Segher Boessenkool wrote:
> On Thu, Sep 08, 2016 at 11:20:41AM -0600, Jeff Law wrote:
> > On 08/29/2016 03:31 AM, Bernd Schmidt wrote:
> > > On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
> > > > +@deftypefn {Target Hook} void
> > > > TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap)
> > > > +Emit prologue insns for the components indicated by the parameter.
> > > > +@end deftypefn
> > > > +
> > > > +@deftypefn {Target Hook} void
> > > > TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS (sbitmap)
> > > > +Emit epilogue insns for the components indicated by the parameter.
> > > > +@end deftypefn
> > >
> > > How do these actually know where to save/restore registers? The frame
> > > pointer may have been eliminated, and SP isn't necessarily constant
> > > during the function. Seems like you'd have to calculate CFA reg/offset
> > > much like dwarf2out does and pass it to this hook.
> > So I think the confusion here is these hooks are independent of
> > placement. ie, the target independent code does something like:
> >
> > FOR_EACH_BB
> >   Build the component bitmap using the incoming edge components
> >   Emit the prologue components at the start of the block
> >   Emit the epilogue components at the end of the block
>
> So you think those hooks need a BB parameter?  If there are ports that
> need that, then sure.  PowerPC doesn't need it.
I wouldn't add it now.  If we find a port that needs it, we can do so at 
that time.  Maybe the port wants to scan the block for a scratch 
register or somesuch.  But let's wait until we actually see a need.

I was mostly trying to highlight the high level structure and that each 
block can have a prologue and/or epilogue associated with it and that 
they are specialized for each block.

jeff