On Thu, Feb 13, 2020 at 08:48:33AM +0100, Richard Biener wrote: > On Wed, 12 Feb 2020, Segher Boessenkool wrote: > > On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote: > > > BB reorder switches back and forth as well ... :/ > > > > Yes. It is extremely hard to change any jumps in cfgrtl mode. > > > > The goal is to use cfglayout mode more, ideally *always*, not to use > > it less! > > Sure! It must be that split requires CFG RTL (it doesn't say so, but > we don't have a PROP_rtllayout or a "cannot work with" set of > properties). Otherwise I'm not sure why we go out of CFG layout > mode so early. Passes not messing with the CFG at all should be > ignorant of what mode we are in.
Well, split can split jump insns as well, so it currently cannot use cfglayout mode. We could probably make split not split jumps, only do that in split2 and later, which is after reload. Getting IRA and LRA to work with cfglayout mode will be fun. Right after split2 is pro_and_epilogue. Everything after that doesn't want cfglayout mode I'd say. So we don't even have to move out_of_cfglayout all that far, but there are some big nasties it has to move over. > > > I think both are closely enough related that we probably should do > > > partitioning from within the same framework? OTOH BB reorder > > > happens _much_ later. > > > > This may be doable. What we need to do first though is to find a better > > thing to use than EDGE_CROSSING. > > > > Maybe we can determine which blocks should be hot and cold early, but > > actually make that happen only very late (maybe adjusting the decision > > if we have to to make things work)? That way, intervening passes do not > > have to care (much). > > The question is whether we can even preserve things like BB counts > and edge frequencies once we've gone out of CFG layout mode for once. Why not? cfglayout mode simply does not include simple branches and jump instructions, and fallthrough is not necessarily to the next bb in the insn stream, but that is all (basically). The cfg is just the same in both rtl modes. What destroys the bb and edge frequencies? > > > > 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. > > > > The latter. (It may also make it easier for the former, of course, but > > that can be solved anyway). And that makes live very hard for all later > > passes, while it is doubtful that it even give the best decisions: for > > example it prevents a lot of shrink-wrapping, which you dearly *want* to > > do on cold code! > > Sure. So do that earlier ;) You cannot. It has to stay after RA, obviously. And you cannot move RA earlier, to before combine. We do shrink-wrapping (and all other *logue work) pretty much as early as possible, already. Segher
