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: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 17 Jan 2018 19:48:27 +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
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.