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