[PATCH] Fix canonicalization of addresses
Wed Jan 7 13:02:00 GMT 2009
On Wed, Jan 7, 2009 at 12:24 PM, Eric Botcazou <email@example.com> wrote:
>> The performance should be "killed" only from within loops, right? So
>> I still think that IVOPTs should properly handle this case.
> I'm not sure why loops should come into play. Canonicalization and CSE should
> be independent from the presence of loops in the code.
Yes. But then CSE should work on either canonical form - if we change
the canonical form we just treat one missed-optimization for another.
IVOPTs comes into play because IVOPTs has non-local knowledge to
decide which canonical form is better - or rather IVOPTs will try to
generate a target friendly TARGET_MEM_REF operation minimizing
the number of induction variables and the address cost. I just do not
see that we have proper information elsewhere on trees - apart from
the possibility to just decide globally that one form is better than the
>> Note that the original patch just decided for
>> " /* No identical multiplicands; see if we can find a common
>> power-of-two factor in non-power-of-two multiplies. This
>> can help in multi-dimensional array access. */"
>> instead of the conflicting
>> " We also canonicalize (X + 7) * 4 into X * 4 + 28 in the hope that
>> either the machine has a multiply-accumulate insn or that this is part of
>> an addressing calculation."
> Your canonicalization is more tree-oriented, the original canonicalization was
> more RTL-oriented.
Both canonical forms existed before my patch. After the patch I
dropped one and decided to always produce the other. Just because
you cannot have both at the same time (obviously).
> I tried various things in pure RTL (simplify-rtx.c) but,
> in the end, nothing works as effectively as flipping the canonicalization for
> offsets when they are still trees.
So this problem exists with both -Os and -O2 then?
More information about the Gcc-patches