Re: Question on aggregates and GIMPLE

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2004-06-09 at 22:09, Jason Merrill wrote:
> On Wed, 9 Jun 2004 17:27:50 -0700, Richard Henderson <rth@redhat.com> wrote:
> 
> > On Wed, Jun 09, 2004 at 08:20:31PM -0400, Richard Kenner wrote:
> >>     <MODIFY_EXPR <INDIRECT_REF, INDIRECT_REF>> is valid GIMPLE, and shouldn't
> >>     require a temporary.  I think we're just getting confused by the
> >>     VIEW_CONVERT_EXPR.
> >> 
> >> Well, how about <MODIFY_EXPR <COMPONENT_REF, INDIRECT_REF>>?  It appears to
> >> be saying that if the LHS is "complex", the RHS must be a variable and
> >> trying to make a temporary.
> >
> > Hmm.  I don't suppose
> >
> >           || (flag_non_call_exceptions && tree_could_trap_p (*from_p))
> >
> > is true in gimplify_modify_expr?  If so, I'm not sure how to approach
> > this.  Other languages require that MODIFY_EXPRs be atomic.
> 
> I was looking at this earlier today, and thinking that we should probably
> disable this for aggregates, or at least for aggregate_value_p types.
> Do you remember the case which inspired this check?
I believe this is to prevent the optimizers from assuming an
assignment has taken place when an exception is thrown by a call
(or by some other operation that might trap).

ie, given something like

x = blah (args);

The assignment to x only occurs if blah does not throw.  Thus we split
things up so that we use a temporary

temp = blah (args);
x = temp;

We don't actually care how the assignment to "temp" is modeled since
we generate a fresh one everytime we need one.  "x" is (of course)
only assigned if the call to "blah" doesn't throw.

There ought to be a discussion of this problem in the archives.  Look
for posts from me around the time that hunk of code first appeared :-)

jeff