This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix canonicalization of addresses
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: "Richard Guenther" <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "Andrew Pinski" <pinskia at gmail dot com>, "Richard Earnshaw" <rearnsha at arm dot com>, "Andrew Haley" <aph at redhat dot com>
- Date: Wed, 7 Jan 2009 12:24:06 +0100
- Subject: Re: [PATCH] Fix canonicalization of addresses
- References: <200812231211.50787.ebotcazou@adacore.com> <200901071109.30959.ebotcazou@adacore.com> <84fc9c000901070252v7073c5c7xc026d09cd7926fbe@mail.gmail.com>
> 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.
> 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. 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.
--
Eric Botcazou