Re: Semantics of MODIFY_EXPR with CONSTRUCTOR rhs

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

    I'm thinking it's a big mistake for SAVE_EXPR to have TREE_INVARIANT set.

I didn't care much for that either, but wanted to work around it for now.

    TREE_INVARIANT should mean "valid anywhere in the current function".
    But for SAVE_EXPR that isn't so -- it's only valid in places
    post-dominated by its first evaluation.  A significant difference in
    my opinion.

Except that SAVE_EXPR doesn't survive gimplification.  So the old "first
evaluation" concept doesn't exist.  If I have a variable that's marked
TREE_INVARIANT, that's similar semantics: the variable is invariant only
when it exists.  But how does that differ from the SAVE_EXPR case?

So I don't see that as an argument.

My argument against it is that it seems very peculiar to have something
both "invariant" and have side-effects. 

So I'm inclined to agree that it shouldn't be set for a SAVE_EXPR,
except, as you point out, that the code in stabilize_reference_1 seems
to depend on that behavior.

This is indeed really tricky.

    Please commit the patch with the grammer nit mentioned elsewhere fixed.

I haven't run full testing, just ACATS, so this will be a while.