This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 28 Feb 2018 10:52:13 +0000
- Subject: [Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
- Auto-submitted: auto-generated
- References: <bug-57534-4@http.gcc.gnu.org/bugzilla/>
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!