This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


In message <20030225152722 dot GA32721 at tornado dot toronto dot redhat dot com>, Diego Novillo 
writes:
 >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().
 >
 >(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;'.
 >    
 >    If 'b_2' has an UNDEFINED value at the time, evaluate_stmt
 >    will return VARYING.  If at a later iteration b_2 becomes
 >    CONSTANT, then we will have a VARYING->CONSTANT transition.
[ ... ]
We've hashed through all of this several times.  I'm only going to 
touch on a few items specific to the patch you sent it.

First, I'd rather not have the folders call into any of the simple
routines.  If we really really need to do this, then the code in
question should probably move into tree-simple or somewhere other
than fold().  I'd like to keep fold as independent of the simplifier
as we can as a guiding principle.

A closely related issue is whether we should consider arithmetic 
involving constant addresses as a simple operand.  I think this
is probably on your plate since I think it's something you want
to do.  I'm not convinced it's a good thing, but I'm not going to
object if you make the changes to allow constant address arithmetic
as simple operands.

  Note that folding opportunities in such cases are rare.  I ran into
  I think 2 total cases where exposing the ability to fold address
  arithmetic would have improved the code.  One was something like
  
  &x + 2 > &x

  The other was something like

  &x + 2 - &x + 1

  Note that neither the generic fold nor the non-destructive folders
  will simplify either of those expressions down on a constant.

A general note -- from looking at your patches it appeared that you were
trying to get the two folders to always return the same results.  That's
not a particularly interesting thing to do.

  The (poorly named) nondestructive folder is used for constant discovery,
  and as a result stuff like simplifying var + 0 to var isn't really
  interesting.

  Note that the destructive folder is still used when we actually
  do replacements.  Meaning that stuff like var + 0 will be
  collapsed into just var at that time.

I don't think it's worth the effort to check in your ENABLE_CHECKING
stuff to verify the two folders produce the same constant results.  The
only places I see them differing is in address arithmetic.    The
differences between their results are not significant in terms of allowing
us to find more constants.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]