https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 28 Feb 2018, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 > > --- Comment #22 from amker at gcc dot gnu.org --- > (In reply to Richard Biener from comment #21) > > One major flaw here is that IVOPTs does nothing on this loop because it > > doesn't find any induction variables. So basically this is highlighting the > > fact that > > we leave addressing mode computation to the RTL combiner. SLSR was supposed > > to be driving the way to do addressing mode computation on non-loopy code > > and what it does is make using autoinc/dec easier (but as you saw later > > forwprop passes wreck somewhat with this). It would be nice if IVOPTs > > could consider 'ind' as "induction variable" and be able to do addressing > > mode selection on scalar code. Bin, what would be required to do this? > it depends on scev for this. I don't think this can (or easily) be modeled in > scev, ind could be arbitrarily changed by cond(). But... Ah. Note that SCEV can now handle SESE regions (which includes a single basic-block). It should instantiate all ind+CST uses up to a common BB "invariant" ind SSA name. > > We'd basically consider all SSA names used in addresses as IVs (or maybe > > only multi-uses?). > > > > So my suggestion would be to see if you can make SLSR generate > > TARGET_MEM_REFs > > based on some common infrastructure with IVOPTs. > Yes, I also believe strength reduction infrastructure in IVOPTs could be > (easily?) extended to cover this case. Either export interface from IVOPTs > and > do it in SLSR etc., or simply handle such loops specially in IVOPTs it self. > Then it would be something like vect vs slp. I have time now and can play > with > this idea. Great!
