RFA: tuples merge for GIMPLE_MODIFY_STMT

Andrew Pinski pinskia@physics.uc.edu
Wed Nov 15 19:39:00 GMT 2006

> > 
> > Aldy Hernandez wrote on 11/11/06 04:47:
> > 
> > > I have fixed this in the included patch, by generating a GIMPLE_MODIFY_STMT
> > > instead of INIT_EXPR.  I'm not to gimplifier savvy enough to know if this will
> > > miss out on optimizations, or if I'm side stepping some tenet of the
> > > gimplifier.  This approach fixes the problem, bootstraps, and does not
> > > introduce any regressions.
> > > 
> > > What do you think?
> > > 
> > It shouldn't block anything.  We don't really use INIT_EXPR for anything 
> > these days.
> Or do we: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00771.html ?
> A patch from this year for using the semantics of INIT_EXPR, in fact I think
> this is the same spot which is being changed.


Which mentions the difference between INIT_EXPR and MODIFY_EXPR:
The fix is to take advantage of the difference between MODIFY_EXPR and INIT_EXPR.
In an INIT_EXPR, the lhs is assumed to be uninitialized, so any reference to it
on the rhs is undefined. This means that we can be aggressive about doing the RSO
for INIT_EXPRs, but we can only do it for MODIFY_EXPR if we can be sure that the
lhs will not be referenced in computing the rhs.

Hopefully that patch added a testcase :).

Andrew Pinski

More information about the Gcc-patches mailing list