This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower


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!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]