On Tue, Sep 10, 2013 at 3:30 AM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Mon, Sep 9, 2013 at 10:01 AM, Richard Biener wrote: >>> >> First, the loop passes that at the moment preceede IVOPTs leave >>> >> around IL that is in desparate need of basic re-optimization >>> >> like CSE, constant propagation and DCE. That puts extra load >>> >> on IVOPTs and its cost model, increasing compile-time and >>> >> possibly confusing it. > > So why not just run DCE and DOM just before IVOPTs? > > >>> >> Second, IVOPTs introduces lowered memory accesses that it >>> >> expects to stay as is, likewise it produces auto-inc/dec >>> >> sequences that it expects to stay as is until RTL expansion. >>> >> Passes such as DOM can break this expectation and make the >>> >> work done by IVOPTs a waste. > > But IVOPTs leaves its own messy code behind (see below). > > >>> >> I remember doing this excercise in the GCC 4.3 timeframe where >>> >> benchmarking on x86_64 showed no gains or losses (but x86_64 >>> >> isn't very sensitive to IV choices). >>> >> >>> >> Any help with benchmarking this on targets other than x86_64 >>> >> is appreciated (I'll re-do x86_64). > > Targets like POWER and ARM would be interesting to test on. Yes, I will benchmark on ARM 32bit. > > >> We already run LIM twice, moving the one that is currently after >> IVOPTs as well should be easy. But of course as you note IVOPTs >> may introduce loop invariant code it also may introduce full >> redundancies in the way it re-writes IVs. And for both people may >> claim that we have both CSE and LIM on the RTL level, too. > > I would claim that relying on RTL (G)CSE and RTL LIM is a step in the > wrong direction. You end up creating a lot of garbage RTL, and many > transformations that are easy on GIMPLE cannot be performed anymore on > RTL. > > Is it possible to make IVOPTs clean up after itself? It should be easy > for IVOPTs to notice that it creates loop-invariant code, and position It would be even better to have some loop-invariant sensitive re-association, because IVOPT (by using general tree association) splits loop-invariant expression into different gimple, making lim's life hard.
> it on the loop pre-header edge. I suppose full redundancies are > harder, but I would expect that to happen less frequently (the only > situation I can think of right now is where a loop is rewritten with > two IVs where the two IVs share a common sub-expression). > > Ciao! > Steven -- Best Regards.
