This is the mail archive of the
mailing list for the GCC project.
Re: RFA: tuples merge for GIMPLE_MODIFY_STMT
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: pinskia at physics dot uc dot edu (Andrew Pinski)
- Cc: dnovillo at redhat dot com (Diego Novillo), aldyh at redhat dot com (Aldy Hernandez), gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, rth at redhat dot com
- Date: Wed, 15 Nov 2006 14:33:35 -0500 (EST)
- Subject: Re: RFA: tuples merge for GIMPLE_MODIFY_STMT
> > 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 :).