PR42917 (make lambda-code VTA aware)

[Aldy Hernandez]

On Mon, Mar 15, 2010 at 04:43:49AM -0300, Alexandre Oliva wrote:
> On Mar 12, 2010, Aldy Hernandez <aldyh@redhat.com> wrote:
> 
> > The problem is in perfect_nestify().  Here we create a new induction
> > variable (lnivtmp below) and move it along with its uses into the inner
> > loop.  However, we neglect to reset the DEBUG statement associated with
> > the original induction variable in the outer loop.
> 
> Ideally, we shouldn't have to reset them all.  Those that end up after
> the inner loop could still be replaced by the dominating definition in
> the inner loop.  However, those that are before the inner loop would
> need resetting for sure.

I am resetting those before the inner loop (the outer loop).  So am I
not doing exactly what you're saying?

> Although in this particular case you could probably get away with it,
> because the loop nesting requirements make for very little room for
> variable substitutions, coalescing, propagation, etc, that could result
> in a debug bind stmt binding variable X to an SSA_NAME unrelated to
> variable X, it would set a bad precedent of mixing up source-level
> concepts, such as the variable in the debug bind stmt, with
> compiler-internal concepts, such as expressions involving SSA_NAMEs.
> That SSA_NAMEs happen to be vaguely related to some source-level
> variable is sort of a historical artifact, that is helpful to some
> extent when looking at tree dumps, but that's also confusing because it
> induces to this very mistake.  In this sense, we might be better off
> doing away with the link from SSA_NAME to VAR_DECL, and use partition
> numbers or somesuch.

I thought the purpose of placing debug statements was to annotate
equivalence relationships.  In any case, either I'm being incredibly
dense or this is VTA thing is somewhat confusing.  

Is there some FAQ explaining how best to adapt individual passes/etc to
VTA, because so far you're the only one who seems to understand it
enough to review/correct patches.

> To sidestep the debate on correctness (at the risk of turning it into a
> debate on completeness :-), here's the further simplified patch.  How
> does it look for you?

*shrug*, it's your patch now :).  No regressions.  PR fixed.  ltrans-7
is fixed as well.

OK for trunk?

> 

> for gcc/ChangeLog
> from  Aldy Hernandez  <aldyh@redhat.com>, Alexandre Oliva  <aoliva@redhat.com>
> 
> 	PR tree-optimization/42917
> 	* lambda-code.c (remove_iv): Skip debug statements.
> 	(lambda_loopnest_to_gcc_loopnest): Likewise.
> 	(not_interesting_stmt): Debug statements are not interesting.
> 
> for gcc/testsuite/ChangeLog
> from  Aldy Hernandez  <aldyh@redhat.com>
> 
> 	PR tree-optimization/42917
> 	* gcc.dg/pr42917.c: New.
> 
> Index: gcc/lambda-code.c
> ===================================================================
> --- gcc/lambda-code.c.orig	2009-11-29 17:04:22.000000000 -0200
> +++ gcc/lambda-code.c	2010-03-15 04:37:18.000000000 -0300
> @@ -1657,7 +1657,7 @@ remove_iv (gimple iv_stmt)
>  	    continue;
>  
>  	  FOR_EACH_IMM_USE_STMT (stmt, imm_iter, arg)
> -	    if (stmt != iv_stmt)
> +	    if (stmt != iv_stmt && !is_gimple_debug (stmt))
>  	      used = true;
>  
>  	  if (!used)
> @@ -1839,6 +1839,9 @@ lambda_loopnest_to_gcc_loopnest (struct 
>  	  gimple_seq stmts;
>  	  lambda_body_vector lbv, newlbv;
>  
> +	  if (is_gimple_debug (stmt))
> +	    continue;
> +
>  	  /* Compute the new expression for the induction
>  	     variable.  */
>  	  depth = VEC_length (tree, new_ivs);
> @@ -1885,7 +1888,8 @@ not_interesting_stmt (gimple stmt)
>       loop, we would have already failed the number of exits tests.  */
>    if (gimple_code (stmt) == GIMPLE_LABEL
>        || gimple_code (stmt) == GIMPLE_GOTO
> -      || gimple_code (stmt) == GIMPLE_COND)
> +      || gimple_code (stmt) == GIMPLE_COND
> +      || is_gimple_debug (stmt))
>      return true;
>    return false;
>  }
> Index: gcc/testsuite/gcc.dg/pr42917.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ gcc/testsuite/gcc.dg/pr42917.c	2010-03-12 06:05:07.000000000 -0300
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1 -ftree-loop-linear -fcompare-debug -fdump-tree-ltrans" } */
> +
> +extern int A[];
> +
> +void
> +foo ()
> +{
> +  int i, j;
> +  for (i = 0; i < 4; i++)
> +    for (j = 255; j >= 0; j--)
> +      A[j] = 0;
> +}
> +
> +/* { dg-final { scan-tree-dump "Successfully transformed loop" "ltrans" } } */
> +/* { dg-final { cleanup-tree-dump "ltrans" } } */