[PATCH] Fix canonicalization of addresses

Richard Guenther richard.guenther@gmail.com
Wed Jan 7 13:02:00 GMT 2009


On Wed, Jan 7, 2009 at 12:24 PM, Eric Botcazou <ebotcazou@adacore.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
other.

>> 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?

Richard.



More information about the Gcc-patches mailing list