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

[law at redhat dot com]

In message <1046189775 dot 1694 dot 16 dot camel at shadowfax>, Diego Novillo writes:
 >On Tue, 2003-02-25 at 11:12, law at redhat dot com wrote:
 >> In message <20030225154852 dot GA746 at tornado dot toronto dot redhat dot com>, Diego Novillo
 > wri
 >> tes:
 >>  >On Tue, 25 Feb 2003, Jeff Law wrote:
 >>  >
 >>  >>  >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.
 >>  >> 
 >>  >What should be OK?  The two versions of fold() returning
 >>  >different values?  How is that OK?  I don't follow.
 >>  >
 >>  >> 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.
 >>  >> 
 >>  >Not necessarily.  I agree in cases like 'foo (1, 3)'.  But
 >>  >sometimes the expression does not fold because ccp_fold() didn't
 >>  >know how to fold it.  This also happened to things like '1 && 1'.
 >> This should have been caught *much* earlier.
 >> 
 >Eh?  We got to '1 && 1' from 'a_1 && b_1'.  How can it have been caught
 >much earlier than CCP?  In ccp_fold() we were given the expression 'a_1
 >&& b_1' and the lattice values for each one were '1'.  When we called
 >the non-destructive binary expr folder, it returned '1 && 1' instead of
 >the expected '1'.
My mis-understanding.  I thought the 1 && 1 was an input to CCP, not
the result of propagating constants.

So what this really means is that we are missing the truth values in
the non-destructive folder.  I thought I had convinced myself that
they wouldn't show up.  Clearly I was wrong.

 >>  >The bigger problem here is actually the two diverging
 >>  >implementations of fold().  I think we are making a big mistake.
 >>  >We should factor more code in the two flavours of fold().
 >> I don't think you're going to find any significant factorable code. 
 >> Sharing code was my intent from the start, but reality quickly set in.
 >> 
 >OK.  I trust your jugdement.  I shouldn't feel too bad for having
 >cut-n-pasted from fold(), then?
Depends on how much code you cut-n-pasted (I haven't looked yet :-)


I suspect there really isn't much that's factorable for truth-values as
the tests and result values they generate are trivial.

jeff