public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [vta, graphite?] propagate degenerate phi nodes into debug stmts
Date: Mon, 16 Nov 2009 20:48:00 -0000	[thread overview]
Message-ID: <ortywuw6bb.fsf@livre.localdomain> (raw)
In-Reply-To: <84fc9c000911080156iff6d687o26db10af3e9fba5d@mail.gmail.com> 	(Richard Guenther's message of "Sun, 8 Nov 2009 10:56:38 +0100")

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

On Nov  8, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> For the rest it would be better to re-organize the code as

>    else if (gimple_code (def_stmt) == PHI_NODE)
>      {
>         value = degenerate_phi_result (def_stmt);
>         if (value
>             && walk_tree (&value, find_released_ssa_name, NULL, NULL))
>           value = NULL_TREE;
>      }

> that looks simpler and it avoids walking PHI args uselessly.

That doesn't work.  We crash deep within degenerate_phi_result given
expressions containing released SSA names.  It's the same reason why we
have to test for released SSA names before calling
gimple_assign_rhs_to_tree: IIRC it has to do with testing whether the
already-NULL type of the SSA name is a pointer type.

Regardless, I reorganized the code so as to not have to test for
PHI_NODEs as often.  There were two unrelated code paths intermixed with
tests every now and again.  Now they're two separate code flows.

> @@ -479,6 +508,13 @@ insert_debug_temps_for_defs (gimple_stmt

>    stmt = gsi_stmt (*gsi);

> +  if (gimple_code (stmt) == GIMPLE_PHI)
> +    {
> +      tree var = gimple_phi_result (stmt);
> +      insert_debug_temp_for_var_def (gsi, var);
> +      return;
> +    }
> +

> This looks odd.  SSA DEF operand iteration should walk the PHI defs
> as well, so the change should not be necessary.

I thought so, too, but by the time we get there, the operands of the PHI
stmt have already been disconnected.

Here's what I'm going to test now.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vta-ssa-dom-prop-degenerate.patch --]
[-- Type: text/x-diff, Size: 2580 bytes --]

for  gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* tree-ssa.c (find_released_ssa_name): Handle NULL wi.
	(insert_debug_temp_for_var_def): Handle degenerate PHI nodes.
	(insert_debug_temps_for_defs): Handle PHI nodes.

Index: gcc/tree-ssa.c
===================================================================
--- gcc/tree-ssa.c.orig	2009-11-16 18:24:07.000000000 -0200
+++ gcc/tree-ssa.c	2009-11-16 18:41:04.000000000 -0200
@@ -279,7 +279,7 @@ find_released_ssa_name (tree *tp, int *w
 {
   struct walk_stmt_info *wi = (struct walk_stmt_info *) data_;
 
-  if (wi->is_lhs)
+  if (wi && wi->is_lhs)
     return NULL_TREE;
 
   if (TREE_CODE (*tp) == SSA_NAME)
@@ -346,7 +346,33 @@ insert_debug_temp_for_var_def (gimple_st
   /* If we didn't get an insertion point, and the stmt has already
      been removed, we won't be able to insert the debug bind stmt, so
      we'll have to drop debug information.  */
-  if (is_gimple_assign (def_stmt))
+  if (gimple_code (def_stmt) == GIMPLE_PHI)
+    {
+      bool no_value = false;
+      struct walk_stmt_info wi;
+      size_t i;
+
+      memset (&wi, 0, sizeof (wi));
+
+      for (i = 0; i < gimple_phi_num_args (def_stmt); i++)
+	{
+	  tree *argp = gimple_phi_arg_def_ptr (def_stmt, i);
+
+	  if (!*argp
+	      || walk_tree (argp, find_released_ssa_name, NULL, NULL))
+	    {
+	      no_value = true;
+	      break;
+	    }
+	}
+
+      if (!no_value)
+	/* ??? We could handle at least some non-generate PHI
+	   nodes by inserting debug temps on every edge.  It's
+	   not clear how much this would improve debug info.  */
+	value = degenerate_phi_result (def_stmt);
+    }
+  else if (is_gimple_assign (def_stmt))
     {
       bool no_value = false;
 
@@ -408,6 +434,7 @@ insert_debug_temp_for_var_def (gimple_st
 	 at the expense of duplication of expressions.  */
 
       if (CONSTANT_CLASS_P (value)
+	  || gimple_code (def_stmt) == GIMPLE_PHI
 	  || (usecount == 1
 	      && (!gimple_assign_single_p (def_stmt)
 		  || is_gimple_min_invariant (value)))
@@ -478,6 +505,16 @@ insert_debug_temps_for_defs (gimple_stmt
 
   stmt = gsi_stmt (*gsi);
 
+  /* By the time we get here, the DEF in the PHI node seems to have
+     already been disconnected as an operand, so the FOR_EACH below
+     has no effect.  Handle it explicitly.  */
+  if (gimple_code (stmt) == GIMPLE_PHI)
+    {
+      tree var = gimple_phi_result (stmt);
+      insert_debug_temp_for_var_def (gsi, var);
+      return;
+    }
+
   FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, op_iter, SSA_OP_DEF)
     {
       tree var = DEF_FROM_PTR (def_p);

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

  parent reply	other threads:[~2009-11-16 20:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-08  8:07 Alexandre Oliva
2009-11-08  9:57 ` Richard Guenther
2009-11-16 20:35   ` Alexandre Oliva
2009-11-16 20:48   ` Alexandre Oliva [this message]
2009-11-17 15:47     ` Richard Guenther
2009-11-19  4:18       ` Alexandre Oliva
2009-11-19 10:56         ` Richard Guenther
2009-11-20  9:37           ` Alexandre Oliva
2009-11-20 10:47             ` Richard Guenther
2009-11-21  5:22               ` Alexandre Oliva
2011-06-03 14:38           ` Alexandre Oliva
2011-06-06  9:37             ` Richard Guenther
2011-06-07 10:38               ` Alexandre Oliva
2011-06-07 12:04                 ` Richard Guenther
2009-11-19  4:28       ` Alexandre Oliva
2009-11-19 10:59         ` Richard Guenther
2009-11-20  9:26           ` Alexandre Oliva
2009-12-05 16:04             ` H.J. Lu
2009-12-23  8:58               ` H.J. Lu
2010-01-29 17:02                 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ortywuw6bb.fsf@livre.localdomain \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).