On Tue, 16 Oct 2018 at 11:48, Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> Iain Buclaw <ibuc...@gdcproject.org> writes:
> > + /* The LHS expression could be an assignment, to which it's operation
> > gets
> > + lost during gimplification. */
> > + if (TREE_CODE (lhs) == MODIFY_EXPR)
> > + {
> > + lexpr = compound_expr (lexpr, lhs);
> > + lhs = TREE_OPERAND (lhs, 0);
> > + }
>
> s/it's/its/. But the code looks a bit odd -- won't you end up with
> double evaluation of the lhs of the MODIFY_EXPR? Or is the creator of
> the MODIFY_EXPR already guaranteed to have wrapped the lhs in a SAVE_EXPR
> where necessary? Probably worth a comment if so.
>
So, this particular block, the sort of code that we're handling looks like this:
(a = 42) += 64;
(foo() = 42) += 64; // foo() returns a reference
Where the LHS of the left assignment is stripped out and re-written as:
a = 42, a = a + 64;
*SAVE_EXPR <foo ()> = 42, *SAVE_EXPR <foo ()> = *SAVE_EXPR <foo ()> + 64;
LHS is guaranteed to be side-effect free here, else it's a bug. I'll
add a comment about this however.
Regards
--
Iain
