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

[law at redhat dot com]

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.
It's safe and OK if they return different results in rare cases and 
the results evaluate to the same value at runtime.

Please, so I goof'd and missed the truth-values after convincing myself
that they couldn't happen in gimple (and maybe others), but let's not
go down the rathole of trying to either have two folders always give
the same value or trying to make fold be non-destructive.  It's a
lost cause.

 >> 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'.
If we can't fold it, then we need to mark it is varying.  That's
part of the reason why you were seeing collateral damage.

We're clearly missing some important cases in ccp_fold, namely the
truthops, let's get that fixed, then see if there's anything
important still missing (sans builtins, which are a complete issue
unto themselves.).


 >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.
Yes, but if you don't mark it varying, you end up with an algorithm
that you can't prove completes and with a ton of collateral damage
trying to fix it up.

 >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().
Give it a try.  I think you'll find it's pretty futile.

jeff