Re: RFA: tuples merge for GIMPLE_MODIFY_STMT

[Diego Novillo <dnovillo at redhat dot com>]

I have looked over the whole patch.  As expected, it's 95%
mind-numbingly mechanic.  I have a couple of notes about it, but
mostly I think it's ready to go in.

However, I would really like to get consensus from other maintainers
regarding this.  I also cannot really approve all of it as it covers a
lot of ground.

It would be good to commit this earlier rather than later.  But I'm
biased, and there will be integration pains regardless of when this
goes in.


> +	if (TREE_CODE (lhs) == SSA_NAME)
> +	  {
> +	    if (SSA_NAME_DEF_STMT (lhs) == *tp)
> +	      def_stmt_self_p = true;
> +	    else
> +	      debug_tree (*tp);
>             ^^^^^^^^^^^^^^^^^
Leftover debugging code?

> +	/* 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.


> +  /* 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.

> +  if (code == MODIFY_EXPR && cfun && cfun->gimplified)
> +    {
> +      /* WTF?  We should be talking GIMPLE_MODIFY_STMT by now.  */
> +      gcc_unreachable ();
>
s/WTF//

> +  /* ...except perhaps side_effects and volatility.  ?? */
> +  TREE_SIDE_EFFECTS (t) = side_effects;
> +  TREE_THIS_VOLATILE (t) = (TREE_CODE_CLASS (code) == tcc_reference
> +	             	    && arg0 && TREE_THIS_VOLATILE (arg0));
> +
>
arg1 could also be volatile.