Re: [tree-ssa] CCP fixes

[law at redhat dot com]

In message <1045682262 dot 3748 dot 38 dot camel at frodo>, Diego Novillo writes:
 >They wouldn't be non-gimple once we tell is_simple_val() to return true 
 >if really_constant_p() is true (BTW, we should really do a SIMPLE ->
 >GIMPLE rename).  My point is that once you accept these expression trees
 >into the GIMPLE grammar, passes can treat them as black boxes.  No pass
 >needs to look into them, they can be moved around as atomic things once
 >they're declared constants.
No, it's not that simple.  For example, evaluation of these constants
needs to know that (for example) an operand to a PLUS_EXPR can have an
arbitrary structure.

 >> My only objection to this is code which looks at operands of binary
 >> expressions needs to be able to handle any arbitrary constant as an
 >> operand -- at which point we start to lose one of the nicer properties
 >> of GIMPLE trees.
 >> 
 >But you would still have a BINARY_EXPR that has two children, one (or
 >both) of them is a GIMPLE val, so you don't need to worry about it
 >anymore.  You can treat it as an opaque constant value.  Yeah, it may
 >structurally be horrid, but I don't see a way of breaking it down
 >without making it non-constant.
Yes you still have two children, but you have zero knowledge of the
underlying structure of those children.


 >> No, it's not that simple.  Once you allow those arbitrary constants, you
 >> need to make sure the later passes know how to deal with the arbitrary
 >> constants.  Look carefully at the un-ssa pass, it makes assumptions about
 >> the structure of expression operands.
 >> 
 >Eh?  Not it doesn't.  rewrite_out_of_ssa() doesn't examine expressions,
 >it just rewrites the 'tree *' that get_stmt_operands() returns.  We
 >never re-write nodes of trees for which really_constant_p() returns
 >true, do we?  (/me crosses fingers).
That's what got me looking at this to begin with!  ie, we had something
which passed really_constant_p, but which (due to a bug) had a 
SSA_NAME inside it.  The renaming code assumed that if the toplevel object
wasn't an SSA_NAME, then there was nothing to do.  Thus the SSA_NAME lived
beyond the SSA optimizers and all hell broke loose after that.

Jeff