[PATCH] Fix canonicalization of addresses

Richard Guenther richard.guenther@gmail.com
Wed Jan 7 11:07:00 GMT 2009


On Wed, Jan 7, 2009 at 11:09 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Ok, I guess I can agree with that one (it makes it more obvious
>> what happens).  I'll bootstrap & test & apply this.
>
> Thanks.  Please remove the obsolete comment in extract_muldiv, see my patch.

Ok.

> What about the canonicalization of offsets just before RTL expansion?  Your
> 2005 patch has de factor changed it and this can be harmful too.  I have an
> Ada testcase on PowerPC with a lot of consecutive, perturbated multi-dim
> accesses
>
>  A[i1+1][i2][i3][i4][i5][i6]
>  A[i1][i2+1][i3][i4][i5][i6]
>  A[i1][i2][i3+1][i4][i5][i6]
>  A[i1][i2][i3][i4-1][i5][i6]
>
> and so on for which it's a performance killer at -O2 because RTL CSE is
> seriously hampered and cannot factorize all the (base + index) expressions.
> The factorization is *optimal* with GCC 4.1, all the accesses use the same
> (base + index) expression, only the displacements vary.

The performance should be "killed" only from within loops, right?  So
I still think that IVOPTs should properly handle this case.

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."

I still am interested in why this only manifests with -Os - does RTL
forwprop "fix" it?

>> Is there a bugzilla I can reference for the problem?
>
> Andrew?

This is what I applied after bootstrapping and testing on
x86_64-unknown-linux-gnu.

Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-plusminusmult-neg
Type: application/octet-stream
Size: 1601 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090107/d0e434f9/attachment.obj>


More information about the Gcc-patches mailing list