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: "aldyh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 27 Feb 2018 18:30:55 +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
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Coming out of SSA for hand_benchmark_cache_ronly(), we seem to be
> calculating:
>
> ((index + 1) * 8) + x
> ((index + 2) * 8) + x
> ((index + 3) * 8) + x
> etc
>
> After slsr we have:
>
> (index * 8) + x
> (((index * 8) + 8) + x)
> ((((index * 8) + 8) + 8) + x)
>
> And finally after forwprop4:
>
> (index * 8) + x
> (((index * 8) + 8) + x)
> (((index * 8) + 16) + x)
>
> Are you suggesting we reassociate the above as:
>
> ((index * 8) + CONSTANT) + x
Err, what I meant is that we should reassociate as (index * 8 + x) + CONSTANT.
It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
design (because of signed overflows):
/* For non-bit or min/max operations we can't associate
all types. Verify that here. */
(After the following:
PR tree-optimization/45232
* tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
for types with undefined overflow.
(reassociate_bb): Allow re-associating of bit and min/max
operations for types with undefined overflow.
* tree-ssa-forwprop.c (associate_plusminus): New function.
)
The code that introduced the above, moved some arithmetic reassociation to
reassociate_plusminus() in forwprop, which eventually landed in match.md. So
instead of whacking tree-ssa-reassoc.c to handle POINTER_PLUS_EXPR and
PLUS_EXPR, etc, perhaps we can reassociate from match.pd early in the
compilation process.
So, reassociate:
(ind + 3) * 8 + x
into:
(8*ind + x) + 24
And pray for the best. I'll take a look.