This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix 14844/15459/21608: Forward-propagate casts thatwill collapse
- From: Jeffrey A Law <law at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 May 2005 14:53:36 -0600
- Subject: Re: [PATCH] Fix 14844/15459/21608: Forward-propagate casts thatwill collapse
- References: <429309A3.2050000@tat.physik.uni-tuebingen.de> <20050524202151.GB21956@redhat.com>
- Reply-to: law at redhat dot com
On Tue, 2005-05-24 at 13:21 -0700, Richard Henderson wrote:
> On Tue, May 24, 2005 at 01:01:55PM +0200, Richard Guenther wrote:
> > + /* We require that the SSA_NAME holding the result of the NOP_EXPR
> > + be used only once. That may be overly conservative in that we
> > + could propagate into multiple uses. However, that would effectively
> > + be un-cseing the NOP_EXPR, which is probably not what we want. */
>
> Yes we do want to uncse the NOP_EXPR -- it's suppoesd to be a no-op,
> after all.
I agree on this. There are critical differences between a NOP_EXPR
and an ADDR_EXPR. In theory a NOP_EXPR generates no code -- or at
least in its worst case it generates a copy. An ADDR_EXPR can
generate significant amounts of code. Consider &x->y->z->a[20].
> Forwprop is not the place for this optimization.
I'm less sure about this. Ultimately everything in forwprop.c is
just tree combination (run forward rather than reverse). At least
some cases of NOP_EXPR removal clearly fall under the category of
tree combination.
We're certainly running the risk of not tackling the combine problem
by continuing to enhance forwprop.c -- that was my single biggest
concern when I added the ADDR_EXPR cases to forwprop.c
jeff