On Wed, 12 Feb 2020, Segher Boessenkool wrote: > On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote: > > On Tue, 11 Feb 2020, Segher Boessenkool wrote: > > > Basic block partitioning has wildly disproportionate fallout in all > > > later passes, both in terms of what those *do* (or don't, if partitioning > > > is enabled), and of impact on the code (not to mention developer time). > > > > > > Maybe the implementation can be improved, but probably we should do this > > > in a different way altogether. The current situation is not good. > > > > I think the expectation that you can go back to CFG layout mode > > and then work with CFG layout tools after we've lowered to CFG RTL > > is simply bogus. > > Partitioning is also quite problematic if you do not use cfglayout > mode. For example, in shrink-wrapping. It prevents a lot there. > > > Yeah, you can probably do analysis things but > > I wouldn't be surprised if a CFG RTL -> CFG layout -> CFG RTL cycle > > can wreck things. Undoubtedly doing CFG manipulations is not going > > to work since CFG layout does not respect CFG RTL restrictions. > > Doing CFG manipulations on CFG RTL mode directly is almost impossible > to do correctly. > > For example, bb-reorder. Which is a much more important optimisation > than partitioning, btw.
BB reorder switches back and forth as well ... :/ I think both are closely enough related that we probably should do partitioning from within the same framework? OTOH BB reorder happens _much_ later. > > Partitioning simply uncovered latent bugs, there's nothing wrong > > with it IMHO. > > I don't agree. The whole way EDGE_CROSSING works hinders all other > optimisations a lot. I'm not sure if it's there for correctness reasons or just to help checking that nothing "undoes" the partitioning decision. Richard. > > Segher
