Re: RFA: tuples merge for GIMPLE_MODIFY_STMT

[Aldy Hernandez <aldyh at redhat dot com>]

Hi Diego.  Hi folks.

Sorry about the delay, but I'm now ready to address all the issues raised,
and hopefully start the merge march of death.

Diego, I have fixed everything you pointed out, with the exception of the
two (related) issues I will discuss below.

> > +	/* If we re-gimplify a set to an SSA_NAME, we must change the
> > +	   SSA name's DEF_STMT link.  */
> > +	if (def_stmt_self_p)
> > +	  SSA_NAME_DEF_STMT (GIMPLE_STMT_OPERAND (*tp, 0)) = *tp;
> > +
> >
> But that would mean that the optimizers are generating MODIFY_EXPRs.
> Isn't this papering over something?  We do allow the optimizers to
> emit non-GIMPLE code, but when they emit an assignment, it had better
> be a GIMPLE_MODIFY_STMT.

As I mentioned further in this thread, we are creating INIT_EXPRs after
gimplification in internal_get_tmp_var().  These end up as MODIFY_EXPRs
in statement annotations.

We can do one of two:
	1. Leave things as they are.
	2. Have internal_get_tmp_var() generate GIMPLE_MODIFY_STMT.

As pinskia has pointed out, we still perform optimizations on INIT_EXPRs,
so we will miss these.  I am not overly concerned here because we are about
to convert INIT_EXPRs to MODIFY_EXPRs by this point anyhow.

Either #1 or #2 work, but perhaps Jason or you can comment?

> > +  /* FIXME tuples: We need to gimplify into GIMPLE_MODIFY_STMT right
> > +     away, so the helper functions below can be made to only handle
> > +     GIMPLE_MODIFY_STMT's, not MODIFY_EXPR as well.  */
> > +
> >
> What's needed to fix this one?  I'd like to address these FIXMEs right
> away.

This FIXME turned out to be a non-issue.  We can't convert to
GIMPLE_MODIFY_STMT right away, because we still want to preserve the
INIT_EXPR/{MODIFY_EXPR,GIMPLE_MODIFY_STMT} distinction this early on.  So
even if we changed MODIFY_EXPRs to GIMPLE_MODIFY_STMTs early on, supporting
functions to gimplify_expr() would still need to handle INIT_EXPR with
PROTECTED_TREE_OPERAND (or GENERIC_TREE_OPERAND :)).

So... this FIXME isn't a fixme.

And that, good sirs, is hopefully it.

Aldy

p.s. There's the issue of PROTECTED_TREE_OPERAND vs GENERIC_TREE_OPERAND.
     I'm testing a patch right now.