This is the mail archive of the gcc-patches@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] More CCP fixes [patch]


On Mon, 12 Aug 2002, Jason Merrill wrote:

> > That would only paper over the problem.  The real bug is that when we
> > try to do replacements, we call find_expr_in_tree(), which returns the
> > first VAR_DECL i that it finds.  The function does not know which
> > sub-tree to return.
> 
> Yes, I'm suggesting it should.
> 
I'm arguing that it should be eliminated :)

> > On the other hand, if we tell every varref to store a pointer to its
> > parent expression, the optimizers can replace these expressions without
> > having to walk the expression tree again.
> 
> But how would you decide which expressions to remember?  I can't think of
> any scheme which would avoid requiring us to decide at some point that it's
> OK to replace the rhs of a MODIFY_EXPR, but not the lhs.
> 
For that we have the varref structure (tree-flow.h).  After
simplification, we build the flowgraph and find all the variables
referenced in the program (tree-dfa.c:tree_find_varrefs).

The varref structure is the fundamental building block of the SSA
form of the program.  These objects represent definitions and
uses of program variables, PHI nodes and even expressions (for
PRE).  The SSA builder creates a web of these varrefs that the
optimizers later navigate and modify.

Each varref knows its type and also its location (basic block,
statement and expression).  For instance, in the following
SIMPLE program there are 3 references to i:

	i = 3;
	i = i + 2;

Right now, each varref knows the expression and statement that
contains it.  So, in this case, we would have:

	D1(i) = 3;
	D2(i) = U3(i) + 2;

When doing CCP, we find that U3(i) is reached by the constant
value 3 from D1(i).  However, U3(i) knows that its parent
expression is the '+' node.  What it doesn't know is that it is
operand 0 of '+'.

So, when replacing constants, we need to recurse into '+' to find
U3(i) *again* (we had done this already when finding variable
references).  So, my proposal is that instead of having the
varrefs store their parent tree, they should store the address of
the operand that contains them (in this case &TREE_OPERAND('+',
0)).

This way, when we want to replace the reference, we don't need to
do a new recursive search.  The same idea can be used for PRE,
where we have expression references.


Diego.


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