RFA: tuples merge for GIMPLE_MODIFY_STMT

Diego Novillo dnovillo@redhat.com
Thu Nov 9 17:46:00 GMT 2006


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.



More information about the Gcc-patches mailing list