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

[Diego Novillo <dnovillo at redhat dot com>]

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'.

>  >If we mark it VARYING due to limitations in the nondestructive
>  >folder, we may end up blocking further propagation of constants.
>  >In the case of '1 && 1', the variable that the expression was
>  >being assigned to was never considered constant.
> Then you should find out why that wasn't folded earlier (ie, before ccp).
> 
Precisely because the original expression was 'a && b'  :)

>  >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?


Diego.