This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate components
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