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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |law at redhat dot com

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
I wonder if this could be addressed with a more reasonable address computation
reassociation.

  _14 = index.6_13 * 8;                     <- here
  _16 = x_15(D) + _14;
  _17 = *_16;
  _20 = _14 + 8;
  _21 = x_15(D) + _20;
  _22 = *_21;
  _23 = _17 + _22;
  _26 = _14 + 16;
  _27 = x_15(D) + _26;

ISTM that we associating as (x + (y + c)) which seems like a mistake in this
case.

If we associated as (x + y) + c, then the (x + y) would become a common
subexpression eliminating a bunch of unnecessary address computations.

Of course, I'm sure there are cases where (x + (y + c)) is better.  Though ISTM
that generally (x + y) + c ought to be better for the addressing modes
available on most targets.

Anyway, something to think about.

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