[PATCH] Fix 14844/15459/21608: Forward-propagate casts that will collapse

[Richard Guenther]

Jeffrey A Law wrote:
> 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].

Ok, I can look to improve the patch in this regard.  Need to find
some place to copy&paste from, though :)


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

Forwprop is the easiest place for doing this optimization.  And it's
better to do it somewhere cheap instead of waiting for the tree-combiner
to arrive.

But of course it's not my call.

Richard.