This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

And:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00733.html

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 :).

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]