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

[Diego Novillo]

On Tue, 2003-02-25 at 12:48, law@redhat.com wrote:

> Noted.  I'll probably pick them up after the bootstrap & test is finished
> which fixes how we handled undefined expressions and re-enables the
> VARYING->CONSTANT state checking.
> 
OK.

>  >Au contraire.  The algorithm completes in fewer iterations.  Remember
>  >that UNDEFINED values are short circuit for PHI expression evaluations. 
>  >They imply no change of state.  Ergo, the main loop finishes sooner.
> But if you've got a transition from VARYING back to CONSTANT, what's to
> stop you from ping-ponging between VARYING and CONSTANT?  That's one of
> the key concepts behind the algorithm and its allowable state changes.
> 
I was talking about evaluate_stmt() returning UNDEFINED.  There are two
cases:

(a) If evaluate_stmt() returns UNDEFINED on something that really is
VARYING or CONSTANT, we have a hard bug.  The short circuit evaluation
of PHI nodes for UNDEFINED values will cut CCP short and produce wrong
results.

(b) If evaluate_stmt() returns VARYING on something that really is
UNDEFINED or VARYING, we have a soft bug.  We will merely be producing
worse code because we won't propagate as many constants.  We will also
probably abort compilation if CCP tries to do a VARYING->anything
transition (I'm assuming that you will reinstate the checks that I
#ifdef'd out).

It's (a) that I'm more concerned about.


>  >Alternately, we can preserve the status quo and allow VARYING->CONSTANT
>  >and VARYING->UNDEFINED transitions.
> I can't tell you how strongly I feel this is a mistake.
>
Agreed.  That's why it is important for evaluate_stmt() to accurately
return UNDEFINED or VARYING when appropriate.


Diego.