Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate components

[Segher Boessenkool <segher@kernel.crashing.org>]

On Mon, Sep 12, 2016 at 12:02:50PM -0600, Jeff Law wrote:
> >>>As a final optimisation, if a block needs a prologue and its immediate
> >>>dominator has the block as a post-dominator, the dominator gets the
> >>>prologue as well.
> >>So why not just put it in the idom and not in the dominated block?
> >
> >That's what it does :-)
> Then I must have mis-parsed.  Thanks for clarifying.

"As a final optimisation, if a block needs a prologue and its immediate
dominator has the block as a post-dominator, ***that immediate dominator***
gets the prologue as well."

That is clearer I hope :-)

> Hmm, then explain again why DCE is mucking up?  I don't immediately see 
> how EPILOGUE_BEG notes come into play with DCE.  It seems to rely on the 
> DF data and AFAICT DF only cares about the EPILOGUE_BEG note in 
> can_move_insns_across which shouldn't be used by DCE.

The register restore *is* dead code, but we need to have the same CFI
for all convergent paths.

> >>Consider using auto_sbitmap rather than manually managing
> >>allocation/releasing of the per-block structures.  In fact, can't all of
> >>SW become a class and we lose the explicit init/fini routines in favor
> >>of a ctor/dtor?
> >
> >Yes, you can always add indirection.  I do not think the code becomes
> >more readable that way (quite the opposite).  Explicit is *good*.
> The GCC project is moving away from this kind of explicit 
> allocation/deallocation and more towards a RAII.  Unless there is a 
> clear need for the explicit allocation/deallocation, please put this 
> stuff into a class with an appropriate ctor/dtor.
> 
> FWIW, I was a big opponent of how much stuff happens "behind your back" 
> with some languages (including C++).  But over the last few years my 
> personal stance has softened considerably after seeing how cleanly RAII 
> solves certain problems.

We then still cannot get rid of SW, which is a convenience macro to do
a nasty cast on bb->aux.  If bb->aux was some pretty class hierarchy,
easy to use and all that, I would of course agree with your suggestion.
But as it is it is just a bare pointer, so the less we hide the safer
it is.

> >>For the PPC R0 vs LR is the only thing that causes disqualification
> >>right?
> >
> >Currently, yes.
> >
> >>Can't that be handled when we build the set of components we
> >>want to insert for each edge/block?  Is there some advantage to handling
> >>disqualifications after all the potential insertion points have been
> >>handled?
> >
> >We do not know if an edge needs a prologue, epilogue, or neither, until
> >we have decided whether *both* ends of that edge want the component active
> >or not.
> Right.  Hmm, maybe I'm not asking the question clearly.
> 
> Whether or not an edge needs a prologue or epilogue is a function not 
> just of the state at the head or tail of the edge, but instead is a 
> function of global dataflow propagation?  Thus we can't disqualify until 
> after we've done the dataflow propagation?  Right?

We can figure out before we decide what blocks need what components, what
edges can not get a prologue or epilogue for which components.  This
complicates the selection algorithm a whole lot, for not much gain that
I have seen so far, so I just give up in the cases that end up "bad".

It is not easy at all to see what edges will need to get a *logue,
because not always both blocks that edge connects are in the same
dominator subtree (or tree even, for an epilogue-aware placement
algorithm, but this patch doesn't do that yet; it's a more minor
optimisation, only reduces code size a little).


Segher