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 #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...

> 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.

Thanks,

>

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