Re: [tree-ssa]: Loop LICM, take 2

[Diego Novillo <dnovillo at redhat dot com>]

On Wed, 2003-08-27 at 09:10, Daniel Berlin wrote:

> Technically, yes, but this is a problem we can't really fix right now.
> We'd have to go searching all over creation for a scope to use.
> 
Hmm, true.  Does this ever happen?  I'm wondering if we shouldn't
abort() if this occurs.  Alternately, we could do a quick traversal from
the block predecessors fixing up the statement's scope, much like we
have fixup_var_scope.

> >> +  bbs = get_loop_body (loop);
> >> +  for (i = 0; i < loop->num_nodes; i++)
> >> +    if (bbs[i]->index >= 0)
> >> +      bitmap_set_bit (loop_body, bbs[i]->index);
> >> +
> >> +  for (i = 0; i < loop->num_nodes; i++)
> >> +    {
> >> +      block_stmt_iterator bsi;
> >> +      if (bsi_end_p (bsi_start (bbs[i])))
> >> +	continue;
> >> +
> > This doesn't seem necessary.
> 
> It is, or i wouldn't have added it.
> I can tell you where we crash if we remove it, if you like.
> 
> >
> >> +      for (bsi = bsi_start (bbs[i]); !bsi_end_p (bsi); bsi_next 
> >> (&bsi))
> >> +	{
>
Please do, because it seems to me that the !bsi_end_p (bsi) check at the
top of the loop should have the same effect (ie, do nothing if bbs[i] is
empty).


> >> +	  tree stmt = bsi_stmt (bsi);
> >> +	  varray_type uses;
> >> +	  varray_type vuses;
> >> +	  size_t j;
> >> +	  bool can_hoist = true;
> >> +
> >> +	  if (IS_EMPTY_STMT (stmt)
> >> +	      || contains_unrenamed_variables (stmt)
> >> +	      || TREE_CODE (stmt) != MODIFY_EXPR
> >> +	      || TREE_CODE (TREE_OPERAND (stmt, 0)) != SSA_NAME)
> >> +
> >> +	    continue;
> >>
> > Why are you making all these checks?  What I had in mind is something
> > like: if all the uses and vuses of the statement come from outside the
> > loop and the statement has no volatile operands, lift it (which is
> > roughly what you do below).  Why are you checking for unrenamed
> > variables?
> 
> Because we can't lift statements with unrenamed variables.
> 
Why?  Those unrenamed variables will have VUSE/VDEF operands.  If they
don't, the statement will be marked as having volatile operands.  Do you
have a test case that would fail without this?


> >  Why do you care whether the LHS of the assignment is an SSA
> > name?
> 
> Because we can't lift stores.
> 
Again.  Why?

	for (i = 0; i < 10; i++)
	  {
	     A[3] = x + y;
	     B[i] += A[3] + i;
	  }

A[3] can be lifted.  It has no reaching defs within the loop.
B[i] can't.  It has one reaching def within the loop.

I think I need to see a test case here as well.  I may be missing
something.


Thanks.  Diego.


Diego.