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.
