Re: [tree-ssa] CCP and non-destructive folding problems

[law at redhat dot com]

In message <20030225152722 dot GA32721 at tornado dot toronto dot redhat dot com>, Diego Novillo w
rites:
 >My recent change to the flowgraph exposed a couple of problems in
 >CCP:
 >
 >(1) ccp_fold() and fold() are not always returning the same
 >    value.   For instance, strlen("abc") is folded to 3 by
 >    fold(), but not folded by ccp_fold().
This *should* be OK.  If it isn't then we've got a design issue in
CCP.


 >(2) The evaluation of statements (evaluate_stmt) always returns
 >    VARYING when it can't fold it.  Suppose that evaluate_stmt is
 >    called with 'a_1 = b_2 + 3;'.
Yup.  We discussed this one privately last week :-)


 >The attached patch started as a fix for (2).  Now, evaluate_stmt
 >will return UNDEFINED when the expression has a chance of
 >becoming CONSTANT at a later time.  However, this exposes a bug
 >in the non-destructive folder.  Returning UNDEFINED is a
 >dangerous proposition because of the optimistic evaluation of PHI
 >nodes.  Suppose we have the following code:
 >
 >	    1	p_1 = "abcdef";
 >	    2	while (1)
 >	    3	  {
 >	    4	    p_2 = PHI (p_1, p_3);
 >	    5	    if (...)
 >	    6	      break;
 >	    7	    ...
 >	    8	    p_3 = p_2 + 1;
 >	    9	  }
 >
 >When CCP visits the PHI expression at line 4 for the first time,
 >it determines that p_1 has a CONSTANT value and, since p_3 comes
 >from an unexecutable edge, it has an UNDEFINED value.  Therefore,
 >it assigns p_2 the CONSTANT value "abcdef".
 >
 >We then get to the assignment at line 8.  Since p_2 is "abcdef",
 >we call the non-destructive fold, which can't handle "abcdef" + 1
 >and returns the expression unmodified.  Since all the operands of
 >the expression are constants, evaluate_stmt() returns UNDEFINED
 >because it thinks the evaluation may fold at a later time.
Err, that's the problem.  If none of the operands are undefined, but 
the expression does not fold, then the expression *must* be marked as
varying.

Jeff