Re: Semantics of MODIFY_EXPR with CONSTRUCTOR rhs

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I'd have been surprised if you'd told me we had supported this
    in the rtl expanders, but I can only assume from the context of
    this message that we did.

Yeah.  We call safe_from_p and make a new target.  Note that there's a kludge
with variable-sized things since we can't make a temporary in that case.

    I suppose it makes logical sense to support it -- as if we're creating
    a temporary object with the CONSTRUCTOR.  The tricky bit will be to
    not pessimize the common case in which we do not have overlap between
    the lhs and the rhs.

Right.  Is there already a tree analog of safe_from_p or does something
have to be written?

    I suppose I can take a look at this problem this week...

I can do it, if we agree on the approach.   We don't actually need to make
a temporary for the target: we can make a temporary for any conflicting
element.  That can just be done by gimplifying it.  I tried it and it blew
up due to variable-sized temporaries, but I think the right approach is
to gimplify each element in a separate loop if it's not variable sized
and is either a scalar (so it's not worth checking) or an aggregate that
conflicts with the target.  Does that sound right?

So the key is the "does not conflict" function.  It can be written with
tree walks fairly easily, but I want to make sure it doesn't exist since
there can be tricky issues with indirects via pointers and alias sets.