New options to disable/enable any pass for any functions

[davidxl, 2011-05-18 18:37:11]

In gcc, not all passes have user level control to turn it on/off, and
there is no way to flip on/off the pass for a subset of functions. I
implemented a generic option handling scheme in gcc to allow
disabling/enabling any gcc pass for any specified function(s).  The
new options will be very useful for things like performance
experiments and bug triaging (gcc has dbgcnt mechanism, but not all
passes have the counter).

The option syntax is very similar to -fdump- options. The following
are some examples:

-fdisable-tree-ccp1    <--- disable ccp1 for all functions
-fenable-tree-cunroll=1   <--- enable complete unroll for the function
                           whose cgraphnode uid is 1
-fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
                                           functions at the following
                                            ranges [1,1], [300,400], and
[400,1000]
-fdisable-tree-einline --> disable early inlining for all callers
-fdisable-ipa-inline --> disable ipa inlininig

In the gcc dumps, the uid numbers are displayed in the function header.

The options are intended to be used internally by gcc developers.

Ok for trunk ? (There is a little LIPO specific change that can be removed).

David

2011-05-18  David Li  <davidxl@google.com>

	* final.c (rest_of_clean_state): Call function header dumper.
	* opts-global.c (handle_common_deferred_options): Handle new options.
	* tree-cfg.c (gimple_dump_cfg): Call function header dumper.
	* passes.c (register_one_dump_file): Call register_pass_name.
	(pass_init_dump_file): Call function header dumper.
	(execute_one_pass): Check explicit enable/disable flag.
	(passr_hash): New function.
	(passr_eq): 
	(register_pass_name):
	(get_pass_by_name):
	(pass_hash):
	(pass_eq):
	(enable_disable_pass):
	(is_pass_explicitly_enabled_or_disabled):
	(is_pass_explicitly_enabled):
	(is_pass_explicitly_disabled):


Index: tree-pass.h
===================================================================
--- tree-pass.h	(revision 173635)
+++ tree-pass.h	(working copy)
@@ -644,4 +644,12 @@ extern bool first_pass_instance;
 /* Declare for plugins.  */
 extern void do_per_function_toporder (void (*) (void *), void *);
 
+extern void enable_disable_pass (const char *, bool);
+extern bool is_pass_explicitly_disabled (struct opt_pass *, tree);
+extern bool is_pass_explicitly_enabled (struct opt_pass *, tree);
+extern void register_pass_name (struct opt_pass *, const char *);
+extern struct opt_pass *get_pass_by_name (const char *);
+struct function;
+extern void pass_dump_function_header (FILE *, tree, struct function *);
+
 #endif /* GCC_TREE_PASS_H */
Index: final.c
===================================================================
--- final.c	(revision 173635)
+++ final.c	(working copy)
@@ -4456,19 +4456,7 @@ rest_of_clean_state (void)
 	}
       else
 	{
-	  const char *aname;
-	  struct cgraph_node *node = cgraph_node (current_function_decl);
-
-	  aname = (IDENTIFIER_POINTER
-		   (DECL_ASSEMBLER_NAME (current_function_decl)));
-	  fprintf (final_output, "\n;; Function (%s) %s\n\n", aname,
-	     node->frequency == NODE_FREQUENCY_HOT
-	     ? " (hot)"
-	     : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
-	     ? " (unlikely executed)"
-	     : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
-	     ? " (executed once)"
-	     : "");
+	  pass_dump_function_header (final_output, current_function_decl, cfun);
 
 	  flag_dump_noaddr = flag_dump_unnumbered = 1;
 	  if (flag_compare_debug_opt || flag_compare_debug)
Index: common.opt
===================================================================
--- common.opt	(revision 173635)
+++ common.opt	(working copy)
@@ -1018,6 +1018,14 @@ fdiagnostics-show-option
 Common Var(flag_diagnostics_show_option) Init(1)
 Amend appropriate diagnostic messages with the command line option that
controls them
 
+fdisable-
+Common Joined RejectNegative Var(common_deferred_options) Defer
+-fdisable-[tree|rtl|ipa]-<pass>=range1+range2 disables an optimization pass
+
+fenable-
+Common Joined RejectNegative Var(common_deferred_options) Defer
+-fenable-[tree|rtl|ipa]-<pass>=range1+range2 enables an optimization pass
+
 fdump-
 Common Joined RejectNegative Var(common_deferred_options) Defer
 -fdump-<type>	Dump various compiler internals to a file
Index: opts-global.c
===================================================================
--- opts-global.c	(revision 173635)
+++ opts-global.c	(working copy)
@@ -411,6 +411,12 @@ handle_common_deferred_options (void)
 	    error ("unrecognized command line option %<-fdump-%s%>", opt->arg);
 	  break;
 
+	case OPT_fenable_:
+	case OPT_fdisable_:
+	  enable_disable_pass (opt->arg, (opt->opt_index == OPT_fenable_?
+	                       true : false));
+          break;
+
 	case OPT_ffixed_:
 	  /* Deferred.  */
 	  fix_register (opt->arg, 1, 1);
Index: tree-cfg.c
===================================================================
--- tree-cfg.c	(revision 173636)
+++ tree-cfg.c	(working copy)
@@ -2090,11 +2090,7 @@ gimple_dump_cfg (FILE *file, int flags)
 {
   if (flags & TDF_DETAILS)
     {
-      const char *funcname
-	= lang_hooks.decl_printable_name (current_function_decl, 2);
-
-      fputc ('\n', file);
-      fprintf (file, ";; Function %s\n\n", funcname);
+      pass_dump_function_header (file, current_function_decl, cfun);
       fprintf (file, ";; \n%d basic blocks, %d edges, last basic block
%d.\n\n",
 	       n_basic_blocks, n_edges, last_basic_block);
 
Index: passes.c
===================================================================
--- passes.c	(revision 173635)
+++ passes.c	(working copy)
@@ -382,7 +382,7 @@ void
 register_one_dump_file (struct opt_pass *pass)
 {
   char *dot_name, *flag_name, *glob_name;
-  const char *name, *prefix;
+  const char *name, *full_name, *prefix;
   char num[10];
   int flags, id;
 
@@ -411,6 +411,8 @@ register_one_dump_file (struct opt_pass 
   glob_name = concat (prefix, name, NULL);
   id = dump_register (dot_name, flag_name, glob_name, flags);
   set_pass_for_id (id, pass);
+  full_name = concat (prefix, pass->name, num, NULL);
+  register_pass_name (pass, full_name);
 }
 
 /* Recursive worker function for register_dump_files.  */
@@ -454,6 +456,298 @@ register_dump_files (struct opt_pass *pa
   register_dump_files_1 (pass, properties);
 }
 
+struct pass_registry
+{
+  const char* unique_name;
+  struct opt_pass *pass;
+};
+
+/* Pass registry hash function.  */
+
+static hashval_t
+passr_hash (const void *p)
+{
+  const struct pass_registry *const s = (const struct pass_registry *const) p;
+  return htab_hash_string (s->unique_name);
+}
+
+/* Hash equal function  */
+
+static int
+passr_eq (const void *p1, const void *p2)
+{
+  const struct pass_registry *const s1 = (const struct pass_registry *const)
p1;
+  const struct pass_registry *const s2 = (const struct pass_registry *const)
p2;
+
+  return !strcmp (s1->unique_name, s2->unique_name);
+}
+
+static htab_t pass_name_tab = NULL;
+
+/* Register PASS with NAME.  */
+
+void
+register_pass_name (struct opt_pass *pass, const char *name)
+{
+  struct pass_registry **slot;
+  struct pass_registry pr;
+
+  if (!pass_name_tab)
+    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
+
+  pr.unique_name = name;
+  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr, INSERT);
+  if (!*slot)
+    {
+      struct pass_registry *new_pr;
+
+      new_pr = XCNEW (struct pass_registry);
+      new_pr->unique_name = xstrdup (name);
+      new_pr->pass = pass;
+      *slot = new_pr;
+    }
+  else
+    gcc_assert ((*slot)->pass == pass);
+}
+
+/* Returns the pass with NAME.  */
+
+struct opt_pass *
+get_pass_by_name (const char *name)
+{
+  struct pass_registry **slot, pr;
+
+  gcc_assert (pass_name_tab);
+  pr.unique_name = name;
+  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
NO_INSERT);
+
+  if (!slot || !*slot)
+    return NULL;
+
+  return (*slot)->pass;
+}
+
+
+/* Range [start, last].  */
+
+struct uid_range
+{
+  struct opt_pass *pass;
+  unsigned int start;
+  unsigned int last;
+  struct uid_range *next;
+};
+
+/* Hash function for pass structure.  */
+
+static hashval_t
+pass_hash (const void *s)
+{
+  const struct uid_range *const p = (const struct uid_range *const) s;
+  return p->pass->static_pass_number;
+}
+
+/* Pass equal function  */
+
+static int
+pass_eq (const void *s1, const void *s2)
+{
+  const struct uid_range *const p1 = (const struct uid_range *const) s1;
+  const struct uid_range *const p2 = (const struct uid_range *const) s2;
+  return p1->pass->static_pass_number == p2->pass->static_pass_number;
+}
+
+htab_t enabled_pass_uid_range_tab = NULL;
+htab_t disabled_pass_uid_range_tab = NULL;
+
+/* Parse option string for -fdisable- and -fenabler-
+   The syntax of the options:
+
+   -fenable-<pass_name>
+   -fdisable-<pass_name>
+
+   -fenable-<pass_name>=s1:e1,s2:e2,...
+   -fdisable-<pass_name>=s1:e1,s2:e2,...
+*/
+
+void
+enable_disable_pass (const char *arg, bool is_enable)
+{
+  struct opt_pass *pass;
+  htab_t the_tab;
+  char *range_str, *phase_name;
+  char *argstr = xstrdup (arg);
+
+  range_str = strchr (argstr,'=');
+  if (range_str)
+    {
+      *range_str = '\0';
+      range_str++;
+    }
+
+  phase_name = argstr;
+  if (!*phase_name)
+    {
+      error ("Unrecognized option %s", is_enable ? "-fenable" : "-fdisable");
+      free (argstr);
+      return;
+    }
+  pass = get_pass_by_name (phase_name);
+  if (!pass)
+    {
+      error ("Unknown pass %s specified in %s",
+	     phase_name,
+	     is_enable ? "-fenable" : "-fdisable");
+      free (argstr);
+      return;
+    }
+  if (is_enable)
+    {
+      if (!enabled_pass_uid_range_tab)
+	enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq, NULL);
+      the_tab = enabled_pass_uid_range_tab;
+    }
+  else
+    {
+      if (!disabled_pass_uid_range_tab)
+	disabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq, NULL);
+      the_tab = disabled_pass_uid_range_tab;
+    }
+
+  if (!range_str)
+    {
+      struct uid_range **slot;
+      struct uid_range *new_range = XCNEW (struct uid_range);
+
+      new_range->pass = pass;
+      new_range->start = 0;
+      new_range->last = (unsigned)-1;
+
+      slot = (struct uid_range **) htab_find_slot (the_tab, new_range, INSERT);
+      new_range->next = *slot;
+      *slot = new_range;
+      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of [%u,
%u]\n",
+              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
+    }
+  else
+    {
+      char *next_range = NULL;
+      char *one_range = range_str;
+      char *end_val = NULL;
+
+      do
+	{
+	  struct uid_range **slot;
+	  struct uid_range *new_range;
+	  char *invalid = NULL;
+	  long start;
+
+	  next_range = strchr (one_range, ',');
+	  if (next_range)
+	    {
+	      *next_range = '\0';
+	      next_range++;
+	    }
+
+	  end_val = strchr (one_range, ':');
+	  if (end_val)
+	    {
+	      *end_val = '\0';
+	      end_val++;
+	    }
+	  start = strtol (one_range, &invalid, 10);
+	  if (*invalid || start < 0)
+	    {
+	      error ("Invalid range %s in option %s",
+		     one_range,
+		     is_enable ? "-fenable" : "-fdisable");
+	      free (argstr);
+	      return;
+	    }
+	  if (!end_val)
+	    {
+	      new_range = XCNEW (struct uid_range);
+              new_range->pass = pass;
+	      new_range->start = (unsigned) start;
+	      new_range->last = (unsigned) start;
+	    }
+	  else
+	    {
+	      long last = strtol (end_val, &invalid, 10);
+	      if (*invalid || last < start)
+		{
+		  error ("Invalid range %s in option %s",
+			 end_val,
+			 is_enable ? "-fenable" : "-fdisable");
+		  free (argstr);
+		  return;
+		}
+	      new_range = XCNEW (struct uid_range);
+              new_range->pass = pass;
+	      new_range->start = (unsigned) start;
+	      new_range->last = (unsigned) last;
+	    }
+	  slot = (struct uid_range **) htab_find_slot (the_tab, new_range, INSERT);
+	  new_range->next = *slot;
+	  *slot = new_range;
+          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
+                  is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
+
+	  one_range = next_range;
+	} while (next_range);
+    }
+
+  free (argstr);
+}
+
+/* Returns true if PASS is explicitly enabled/disabled for FUNC.  */
+
+static bool
+is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
+					tree func, htab_t tab)
+{
+  struct uid_range **slot, *range, key;
+  int cgraph_uid;
+
+  if (!tab)
+    return false;
+
+  key.pass = pass;
+  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
+  if (!slot || !*slot)
+    return false;
+
+  cgraph_uid = func ? cgraph_node (func)->uid : 0;
+
+  range = *slot;
+  while (range)
+    {
+      if ((unsigned) cgraph_uid >= range->start
+	  && (unsigned) cgraph_uid <= range->last)
+	return true;
+      range = range->next;
+    }
+
+  return false;
+}
+
+/* Returns true if PASS is explicitly enabled for FUNC.  */
+
+bool
+is_pass_explicitly_enabled (struct opt_pass *pass, tree func)
+{
+  return is_pass_explicitly_enabled_or_disabled (pass, func,
enabled_pass_uid_range_tab);
+}
+
+/* Returns true if PASS is explicitly disabled for FUNC.  */
+
+bool
+is_pass_explicitly_disabled (struct opt_pass *pass, tree func)
+{
+  return is_pass_explicitly_enabled_or_disabled (pass, func,
disabled_pass_uid_range_tab);
+}
+
+
 /* Look at the static_pass_number and duplicate the pass
    if it is already added to a list. */
 
@@ -1349,6 +1643,29 @@ verify_curr_properties (void *data)
 }
 #endif
 
+void
+pass_dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)
+{
+  const char *dname, *aname;
+  struct cgraph_node *node = cgraph_node (fdecl);
+  dname = lang_hooks.decl_printable_name (fdecl, 2);
+  aname = (IDENTIFIER_POINTER
+	   (DECL_ASSEMBLER_NAME (fdecl)));
+  if (L_IPO_COMP_MODE)
+    fprintf (dump_file, "\n;; Function %s (%s)[%d:%d][uid=%d]", dname, aname,
+	     FUNC_DECL_MODULE_ID (fun), FUNC_DECL_FUNC_ID (fun), node->uid);
+  else
+    fprintf (dump_file, "\n;; Function %s (%s)[uid=%d]", dname, aname,
node->uid);
+  fprintf (dump_file, "%s\n\n",
+           node->frequency == NODE_FREQUENCY_HOT
+           ? " (hot)"
+           : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
+           ? " (unlikely executed)"
+           : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
+           ? " (executed once)"
+           : "");
+}
+
 /* Initialize pass dump file.  */
 /* This is non-static so that the plugins can use it.  */
 
@@ -1362,26 +1679,7 @@ pass_init_dump_file (struct opt_pass *pa
       dump_file_name = get_dump_file_name (pass->static_pass_number);
       dump_file = dump_begin (pass->static_pass_number, &dump_flags);
       if (dump_file && current_function_decl)
-	{
-	  const char *dname, *aname;
-	  struct cgraph_node *node = cgraph_node (current_function_decl);
-	  dname = lang_hooks.decl_printable_name (current_function_decl, 2);
-	  aname = (IDENTIFIER_POINTER
-		   (DECL_ASSEMBLER_NAME (current_function_decl)));
-	  if (L_IPO_COMP_MODE)
-	    fprintf (dump_file, "\n;; Function %s (%s)[%d:%d]", dname, aname,
-		     FUNC_DECL_MODULE_ID (cfun), FUNC_DECL_FUNC_ID (cfun));
-	  else
-	    fprintf (dump_file, "\n;; Function %s (%s)", dname, aname);
-	  fprintf (dump_file, "%s\n\n",
-	     node->frequency == NODE_FREQUENCY_HOT
-	     ? " (hot)"
-	     : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
-	     ? " (unlikely executed)"
-	     : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
-	     ? " (executed once)"
-	     : "");
-	}
+        pass_dump_function_header (dump_file, current_function_decl, cfun);
       return initializing_dump;
     }
   else
@@ -1525,6 +1823,8 @@ execute_one_pass (struct opt_pass *pass)
 {
   bool initializing_dump;
   unsigned int todo_after = 0;
+  bool explicitly_enabled = false;
+  bool explicitly_disabled = false;
 
   bool gate_status;
 
@@ -1535,11 +1835,15 @@ execute_one_pass (struct opt_pass *pass)
   else
     gcc_assert (cfun && current_function_decl);
 
+  explicitly_enabled = is_pass_explicitly_enabled (pass,
current_function_decl);
+  explicitly_disabled = is_pass_explicitly_disabled (pass,
current_function_decl);
+
   current_pass = pass;
 
   /* Check whether gate check should be avoided.
      User controls the value of the gate through the parameter "gate_status".
*/
   gate_status = (pass->gate == NULL) ? true : pass->gate();
+  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);
 
   /* Override gate with plugin.  */
   invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);

--
This patch is available for review at http://codereview.appspot.com/4550056

[joseph_codesourcery.com, 2011-05-18 19:30:44]

On Wed, 18 May 2011, David Li wrote:

> +      error ("Unrecognized option %s", is_enable ? "-fenable" : "-fdisable");

> +      error ("Unknown pass %s specified in %s",
> +	     phase_name,
> +	     is_enable ? "-fenable" : "-fdisable");

Follow GNU Coding Standards for diagnostics (start with lowercase letter).

> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);

Use separate calls to inform for the enable and disable cases, so that 
full sentences can be extracted for translation.

> +	      error ("Invalid range %s in option %s",
> +		     one_range,
> +		     is_enable ? "-fenable" : "-fdisable");

GNU Coding Standards.

> +		  error ("Invalid range %s in option %s",

Likewise.

> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);

Again needs GCS and i18n fixes.

-- 
Joseph S. Myers
joseph@codesourcery.com

[davidxl, 2011-05-18 19:42:48]

Thanks for the comment. Will fix those.

David

On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 18 May 2011, David Li wrote:
>
>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>
>> +      error ("Unknown pass %s specified in %s",
>> +          phase_name,
>> +          is_enable ? "-fenable" : "-fdisable");
>
> Follow GNU Coding Standards for diagnostics (start with lowercase letter).
>
>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>
> Use separate calls to inform for the enable and disable cases, so that
> full sentences can be extracted for translation.
>
>> +           error ("Invalid range %s in option %s",
>> +                  one_range,
>> +                  is_enable ? "-fenable" : "-fdisable");
>
> GNU Coding Standards.
>
>> +               error ("Invalid range %s in option %s",
>
> Likewise.
>
>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>
> Again needs GCS and i18n fixes.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

[richard.guenther_gmail.com, 2011-05-18 20:26:14]

On Wed, May 18, 2011 at 8:37 PM, David Li <davidxl@google.com> wrote:
>
> In gcc, not all passes have user level control to turn it on/off, and
> there is no way to flip on/off the pass for a subset of functions. I
> implemented a generic option handling scheme in gcc to allow
> disabling/enabling any gcc pass for any specified function(s).  The
> new options will be very useful for things like performance
> experiments and bug triaging (gcc has dbgcnt mechanism, but not all
> passes have the counter).
>
> The option syntax is very similar to -fdump- options. The following
> are some examples:
>
> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>                           whose cgraphnode uid is 1
> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>                                           functions at the following
>                                            ranges [1,1], [300,400], and
[400,1000]
> -fdisable-tree-einline --> disable early inlining for all callers
> -fdisable-ipa-inline --> disable ipa inlininig
>
> In the gcc dumps, the uid numbers are displayed in the function header.
>
> The options are intended to be used internally by gcc developers.
>
> Ok for trunk ? (There is a little LIPO specific change that can be removed).
>
> David
>
> 2011-05-18  David Li  <davidxl@google.com>
>
>        * final.c (rest_of_clean_state): Call function header dumper.
>        * opts-global.c (handle_common_deferred_options): Handle new options.
>        * tree-cfg.c (gimple_dump_cfg): Call function header dumper.
>        * passes.c (register_one_dump_file): Call register_pass_name.
>        (pass_init_dump_file): Call function header dumper.
>        (execute_one_pass): Check explicit enable/disable flag.
>        (passr_hash): New function.
>        (passr_eq):
>        (register_pass_name):
>        (get_pass_by_name):
>        (pass_hash):
>        (pass_eq):
>        (enable_disable_pass):
>        (is_pass_explicitly_enabled_or_disabled):
>        (is_pass_explicitly_enabled):
>        (is_pass_explicitly_disabled):

Bogus changelog entry.

New options need documenting in doc/invoke.texi.

Richard.

>
> Index: tree-pass.h
> ===================================================================
> --- tree-pass.h (revision 173635)
> +++ tree-pass.h (working copy)
> @@ -644,4 +644,12 @@ extern bool first_pass_instance;
>  /* Declare for plugins.  */
>  extern void do_per_function_toporder (void (*) (void *), void *);
>
> +extern void enable_disable_pass (const char *, bool);
> +extern bool is_pass_explicitly_disabled (struct opt_pass *, tree);
> +extern bool is_pass_explicitly_enabled (struct opt_pass *, tree);
> +extern void register_pass_name (struct opt_pass *, const char *);
> +extern struct opt_pass *get_pass_by_name (const char *);
> +struct function;
> +extern void pass_dump_function_header (FILE *, tree, struct function *);
> +
>  #endif /* GCC_TREE_PASS_H */
> Index: final.c
> ===================================================================
> --- final.c     (revision 173635)
> +++ final.c     (working copy)
> @@ -4456,19 +4456,7 @@ rest_of_clean_state (void)
>        }
>       else
>        {
> -         const char *aname;
> -         struct cgraph_node *node = cgraph_node (current_function_decl);
> -
> -         aname = (IDENTIFIER_POINTER
> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
> -         fprintf (final_output, "\n;; Function (%s) %s\n\n", aname,
> -            node->frequency == NODE_FREQUENCY_HOT
> -            ? " (hot)"
> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
> -            ? " (unlikely executed)"
> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
> -            ? " (executed once)"
> -            : "");
> +         pass_dump_function_header (final_output, current_function_decl,
cfun);
>
>          flag_dump_noaddr = flag_dump_unnumbered = 1;
>          if (flag_compare_debug_opt || flag_compare_debug)
> Index: common.opt
> ===================================================================
> --- common.opt  (revision 173635)
> +++ common.opt  (working copy)
> @@ -1018,6 +1018,14 @@ fdiagnostics-show-option
>  Common Var(flag_diagnostics_show_option) Init(1)
>  Amend appropriate diagnostic messages with the command line option that
controls them
>
> +fdisable-
> +Common Joined RejectNegative Var(common_deferred_options) Defer
> +-fdisable-[tree|rtl|ipa]-<pass>=range1+range2 disables an optimization pass
> +
> +fenable-
> +Common Joined RejectNegative Var(common_deferred_options) Defer
> +-fenable-[tree|rtl|ipa]-<pass>=range1+range2 enables an optimization pass
> +
>  fdump-
>  Common Joined RejectNegative Var(common_deferred_options) Defer
>  -fdump-<type>  Dump various compiler internals to a file
> Index: opts-global.c
> ===================================================================
> --- opts-global.c       (revision 173635)
> +++ opts-global.c       (working copy)
> @@ -411,6 +411,12 @@ handle_common_deferred_options (void)
>            error ("unrecognized command line option %<-fdump-%s%>", opt->arg);
>          break;
>
> +       case OPT_fenable_:
> +       case OPT_fdisable_:
> +         enable_disable_pass (opt->arg, (opt->opt_index == OPT_fenable_?
> +                              true : false));
> +          break;
> +
>        case OPT_ffixed_:
>          /* Deferred.  */
>          fix_register (opt->arg, 1, 1);
> Index: tree-cfg.c
> ===================================================================
> --- tree-cfg.c  (revision 173636)
> +++ tree-cfg.c  (working copy)
> @@ -2090,11 +2090,7 @@ gimple_dump_cfg (FILE *file, int flags)
>  {
>   if (flags & TDF_DETAILS)
>     {
> -      const char *funcname
> -       = lang_hooks.decl_printable_name (current_function_decl, 2);
> -
> -      fputc ('\n', file);
> -      fprintf (file, ";; Function %s\n\n", funcname);
> +      pass_dump_function_header (file, current_function_decl, cfun);
>       fprintf (file, ";; \n%d basic blocks, %d edges, last basic block
%d.\n\n",
>               n_basic_blocks, n_edges, last_basic_block);
>
> Index: passes.c
> ===================================================================
> --- passes.c    (revision 173635)
> +++ passes.c    (working copy)
> @@ -382,7 +382,7 @@ void
>  register_one_dump_file (struct opt_pass *pass)
>  {
>   char *dot_name, *flag_name, *glob_name;
> -  const char *name, *prefix;
> +  const char *name, *full_name, *prefix;
>   char num[10];
>   int flags, id;
>
> @@ -411,6 +411,8 @@ register_one_dump_file (struct opt_pass
>   glob_name = concat (prefix, name, NULL);
>   id = dump_register (dot_name, flag_name, glob_name, flags);
>   set_pass_for_id (id, pass);
> +  full_name = concat (prefix, pass->name, num, NULL);
> +  register_pass_name (pass, full_name);
>  }
>
>  /* Recursive worker function for register_dump_files.  */
> @@ -454,6 +456,298 @@ register_dump_files (struct opt_pass *pa
>   register_dump_files_1 (pass, properties);
>  }
>
> +struct pass_registry
> +{
> +  const char* unique_name;
> +  struct opt_pass *pass;
> +};
> +
> +/* Pass registry hash function.  */
> +
> +static hashval_t
> +passr_hash (const void *p)
> +{
> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
> +  return htab_hash_string (s->unique_name);
> +}
> +
> +/* Hash equal function  */
> +
> +static int
> +passr_eq (const void *p1, const void *p2)
> +{
> +  const struct pass_registry *const s1 = (const struct pass_registry *const)
p1;
> +  const struct pass_registry *const s2 = (const struct pass_registry *const)
p2;
> +
> +  return !strcmp (s1->unique_name, s2->unique_name);
> +}
> +
> +static htab_t pass_name_tab = NULL;
> +
> +/* Register PASS with NAME.  */
> +
> +void
> +register_pass_name (struct opt_pass *pass, const char *name)
> +{
> +  struct pass_registry **slot;
> +  struct pass_registry pr;
> +
> +  if (!pass_name_tab)
> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
> +
> +  pr.unique_name = name;
> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
INSERT);
> +  if (!*slot)
> +    {
> +      struct pass_registry *new_pr;
> +
> +      new_pr = XCNEW (struct pass_registry);
> +      new_pr->unique_name = xstrdup (name);
> +      new_pr->pass = pass;
> +      *slot = new_pr;
> +    }
> +  else
> +    gcc_assert ((*slot)->pass == pass);
> +}
> +
> +/* Returns the pass with NAME.  */
> +
> +struct opt_pass *
> +get_pass_by_name (const char *name)
> +{
> +  struct pass_registry **slot, pr;
> +
> +  gcc_assert (pass_name_tab);
> +  pr.unique_name = name;
> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
NO_INSERT);
> +
> +  if (!slot || !*slot)
> +    return NULL;
> +
> +  return (*slot)->pass;
> +}
> +
> +
> +/* Range [start, last].  */
> +
> +struct uid_range
> +{
> +  struct opt_pass *pass;
> +  unsigned int start;
> +  unsigned int last;
> +  struct uid_range *next;
> +};
> +
> +/* Hash function for pass structure.  */
> +
> +static hashval_t
> +pass_hash (const void *s)
> +{
> +  const struct uid_range *const p = (const struct uid_range *const) s;
> +  return p->pass->static_pass_number;
> +}
> +
> +/* Pass equal function  */
> +
> +static int
> +pass_eq (const void *s1, const void *s2)
> +{
> +  const struct uid_range *const p1 = (const struct uid_range *const) s1;
> +  const struct uid_range *const p2 = (const struct uid_range *const) s2;
> +  return p1->pass->static_pass_number == p2->pass->static_pass_number;
> +}
> +
> +htab_t enabled_pass_uid_range_tab = NULL;
> +htab_t disabled_pass_uid_range_tab = NULL;
> +
> +/* Parse option string for -fdisable- and -fenabler-
> +   The syntax of the options:
> +
> +   -fenable-<pass_name>
> +   -fdisable-<pass_name>
> +
> +   -fenable-<pass_name>=s1:e1,s2:e2,...
> +   -fdisable-<pass_name>=s1:e1,s2:e2,...
> +*/
> +
> +void
> +enable_disable_pass (const char *arg, bool is_enable)
> +{
> +  struct opt_pass *pass;
> +  htab_t the_tab;
> +  char *range_str, *phase_name;
> +  char *argstr = xstrdup (arg);
> +
> +  range_str = strchr (argstr,'=');
> +  if (range_str)
> +    {
> +      *range_str = '\0';
> +      range_str++;
> +    }
> +
> +  phase_name = argstr;
> +  if (!*phase_name)
> +    {
> +      error ("Unrecognized option %s", is_enable ? "-fenable" : "-fdisable");
> +      free (argstr);
> +      return;
> +    }
> +  pass = get_pass_by_name (phase_name);
> +  if (!pass)
> +    {
> +      error ("Unknown pass %s specified in %s",
> +            phase_name,
> +            is_enable ? "-fenable" : "-fdisable");
> +      free (argstr);
> +      return;
> +    }
> +  if (is_enable)
> +    {
> +      if (!enabled_pass_uid_range_tab)
> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
> +      the_tab = enabled_pass_uid_range_tab;
> +    }
> +  else
> +    {
> +      if (!disabled_pass_uid_range_tab)
> +       disabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
> +      the_tab = disabled_pass_uid_range_tab;
> +    }
> +
> +  if (!range_str)
> +    {
> +      struct uid_range **slot;
> +      struct uid_range *new_range = XCNEW (struct uid_range);
> +
> +      new_range->pass = pass;
> +      new_range->start = 0;
> +      new_range->last = (unsigned)-1;
> +
> +      slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
> +      new_range->next = *slot;
> +      *slot = new_range;
> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
> +    }
> +  else
> +    {
> +      char *next_range = NULL;
> +      char *one_range = range_str;
> +      char *end_val = NULL;
> +
> +      do
> +       {
> +         struct uid_range **slot;
> +         struct uid_range *new_range;
> +         char *invalid = NULL;
> +         long start;
> +
> +         next_range = strchr (one_range, ',');
> +         if (next_range)
> +           {
> +             *next_range = '\0';
> +             next_range++;
> +           }
> +
> +         end_val = strchr (one_range, ':');
> +         if (end_val)
> +           {
> +             *end_val = '\0';
> +             end_val++;
> +           }
> +         start = strtol (one_range, &invalid, 10);
> +         if (*invalid || start < 0)
> +           {
> +             error ("Invalid range %s in option %s",
> +                    one_range,
> +                    is_enable ? "-fenable" : "-fdisable");
> +             free (argstr);
> +             return;
> +           }
> +         if (!end_val)
> +           {
> +             new_range = XCNEW (struct uid_range);
> +              new_range->pass = pass;
> +             new_range->start = (unsigned) start;
> +             new_range->last = (unsigned) start;
> +           }
> +         else
> +           {
> +             long last = strtol (end_val, &invalid, 10);
> +             if (*invalid || last < start)
> +               {
> +                 error ("Invalid range %s in option %s",
> +                        end_val,
> +                        is_enable ? "-fenable" : "-fdisable");
> +                 free (argstr);
> +                 return;
> +               }
> +             new_range = XCNEW (struct uid_range);
> +              new_range->pass = pass;
> +             new_range->start = (unsigned) start;
> +             new_range->last = (unsigned) last;
> +           }
> +         slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
> +         new_range->next = *slot;
> +         *slot = new_range;
> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
> +
> +         one_range = next_range;
> +       } while (next_range);
> +    }
> +
> +  free (argstr);
> +}
> +
> +/* Returns true if PASS is explicitly enabled/disabled for FUNC.  */
> +
> +static bool
> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
> +                                       tree func, htab_t tab)
> +{
> +  struct uid_range **slot, *range, key;
> +  int cgraph_uid;
> +
> +  if (!tab)
> +    return false;
> +
> +  key.pass = pass;
> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
> +  if (!slot || !*slot)
> +    return false;
> +
> +  cgraph_uid = func ? cgraph_node (func)->uid : 0;
> +
> +  range = *slot;
> +  while (range)
> +    {
> +      if ((unsigned) cgraph_uid >= range->start
> +         && (unsigned) cgraph_uid <= range->last)
> +       return true;
> +      range = range->next;
> +    }
> +
> +  return false;
> +}
> +
> +/* Returns true if PASS is explicitly enabled for FUNC.  */
> +
> +bool
> +is_pass_explicitly_enabled (struct opt_pass *pass, tree func)
> +{
> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
enabled_pass_uid_range_tab);
> +}
> +
> +/* Returns true if PASS is explicitly disabled for FUNC.  */
> +
> +bool
> +is_pass_explicitly_disabled (struct opt_pass *pass, tree func)
> +{
> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
disabled_pass_uid_range_tab);
> +}
> +
> +
>  /* Look at the static_pass_number and duplicate the pass
>    if it is already added to a list. */
>
> @@ -1349,6 +1643,29 @@ verify_curr_properties (void *data)
>  }
>  #endif
>
> +void
> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)
> +{
> +  const char *dname, *aname;
> +  struct cgraph_node *node = cgraph_node (fdecl);
> +  dname = lang_hooks.decl_printable_name (fdecl, 2);
> +  aname = (IDENTIFIER_POINTER
> +          (DECL_ASSEMBLER_NAME (fdecl)));
> +  if (L_IPO_COMP_MODE)
> +    fprintf (dump_file, "\n;; Function %s (%s)[%d:%d][uid=%d]", dname, aname,
> +            FUNC_DECL_MODULE_ID (fun), FUNC_DECL_FUNC_ID (fun), node->uid);
> +  else
> +    fprintf (dump_file, "\n;; Function %s (%s)[uid=%d]", dname, aname,
node->uid);
> +  fprintf (dump_file, "%s\n\n",
> +           node->frequency == NODE_FREQUENCY_HOT
> +           ? " (hot)"
> +           : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
> +           ? " (unlikely executed)"
> +           : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
> +           ? " (executed once)"
> +           : "");
> +}
> +
>  /* Initialize pass dump file.  */
>  /* This is non-static so that the plugins can use it.  */
>
> @@ -1362,26 +1679,7 @@ pass_init_dump_file (struct opt_pass *pa
>       dump_file_name = get_dump_file_name (pass->static_pass_number);
>       dump_file = dump_begin (pass->static_pass_number, &dump_flags);
>       if (dump_file && current_function_decl)
> -       {
> -         const char *dname, *aname;
> -         struct cgraph_node *node = cgraph_node (current_function_decl);
> -         dname = lang_hooks.decl_printable_name (current_function_decl, 2);
> -         aname = (IDENTIFIER_POINTER
> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
> -         if (L_IPO_COMP_MODE)
> -           fprintf (dump_file, "\n;; Function %s (%s)[%d:%d]", dname, aname,
> -                    FUNC_DECL_MODULE_ID (cfun), FUNC_DECL_FUNC_ID (cfun));
> -         else
> -           fprintf (dump_file, "\n;; Function %s (%s)", dname, aname);
> -         fprintf (dump_file, "%s\n\n",
> -            node->frequency == NODE_FREQUENCY_HOT
> -            ? " (hot)"
> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
> -            ? " (unlikely executed)"
> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
> -            ? " (executed once)"
> -            : "");
> -       }
> +        pass_dump_function_header (dump_file, current_function_decl, cfun);
>       return initializing_dump;
>     }
>   else
> @@ -1525,6 +1823,8 @@ execute_one_pass (struct opt_pass *pass)
>  {
>   bool initializing_dump;
>   unsigned int todo_after = 0;
> +  bool explicitly_enabled = false;
> +  bool explicitly_disabled = false;
>
>   bool gate_status;
>
> @@ -1535,11 +1835,15 @@ execute_one_pass (struct opt_pass *pass)
>   else
>     gcc_assert (cfun && current_function_decl);
>
> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
current_function_decl);
> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
current_function_decl);
> +
>   current_pass = pass;
>
>   /* Check whether gate check should be avoided.
>      User controls the value of the gate through the parameter "gate_status".
*/
>   gate_status = (pass->gate == NULL) ? true : pass->gate();
> +  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);
>
>   /* Override gate with plugin.  */
>   invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);
>
> --
> This patch is available for review at http://codereview.appspot.com/4550056
>

[davidxl, 2011-05-18 20:34:10]

Will fix the Changelog, and add documentation.

Thanks,

David



On Wed, May 18, 2011 at 1:26 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, May 18, 2011 at 8:37 PM, David Li <davidxl@google.com> wrote:
>>
>> In gcc, not all passes have user level control to turn it on/off, and
>> there is no way to flip on/off the pass for a subset of functions. I
>> implemented a generic option handling scheme in gcc to allow
>> disabling/enabling any gcc pass for any specified function(s).  The
>> new options will be very useful for things like performance
>> experiments and bug triaging (gcc has dbgcnt mechanism, but not all
>> passes have the counter).
>>
>> The option syntax is very similar to -fdump- options. The following
>> are some examples:
>>
>> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
>> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>>                           whose cgraphnode uid is 1
>> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>>                                           functions at the following
>>                                            ranges [1,1], [300,400], and
[400,1000]
>> -fdisable-tree-einline --> disable early inlining for all callers
>> -fdisable-ipa-inline --> disable ipa inlininig
>>
>> In the gcc dumps, the uid numbers are displayed in the function header.
>>
>> The options are intended to be used internally by gcc developers.
>>
>> Ok for trunk ? (There is a little LIPO specific change that can be removed).
>>
>> David
>>
>> 2011-05-18  David Li  <davidxl@google.com>
>>
>>        * final.c (rest_of_clean_state): Call function header dumper.
>>        * opts-global.c (handle_common_deferred_options): Handle new options.
>>        * tree-cfg.c (gimple_dump_cfg): Call function header dumper.
>>        * passes.c (register_one_dump_file): Call register_pass_name.
>>        (pass_init_dump_file): Call function header dumper.
>>        (execute_one_pass): Check explicit enable/disable flag.
>>        (passr_hash): New function.
>>        (passr_eq):
>>        (register_pass_name):
>>        (get_pass_by_name):
>>        (pass_hash):
>>        (pass_eq):
>>        (enable_disable_pass):
>>        (is_pass_explicitly_enabled_or_disabled):
>>        (is_pass_explicitly_enabled):
>>        (is_pass_explicitly_disabled):
>
> Bogus changelog entry.
>
> New options need documenting in doc/invoke.texi.
>
> Richard.
>
>>
>> Index: tree-pass.h
>> ===================================================================
>> --- tree-pass.h (revision 173635)
>> +++ tree-pass.h (working copy)
>> @@ -644,4 +644,12 @@ extern bool first_pass_instance;
>>  /* Declare for plugins.  */
>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>
>> +extern void enable_disable_pass (const char *, bool);
>> +extern bool is_pass_explicitly_disabled (struct opt_pass *, tree);
>> +extern bool is_pass_explicitly_enabled (struct opt_pass *, tree);
>> +extern void register_pass_name (struct opt_pass *, const char *);
>> +extern struct opt_pass *get_pass_by_name (const char *);
>> +struct function;
>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>> +
>>  #endif /* GCC_TREE_PASS_H */
>> Index: final.c
>> ===================================================================
>> --- final.c     (revision 173635)
>> +++ final.c     (working copy)
>> @@ -4456,19 +4456,7 @@ rest_of_clean_state (void)
>>        }
>>       else
>>        {
>> -         const char *aname;
>> -         struct cgraph_node *node = cgraph_node (current_function_decl);
>> -
>> -         aname = (IDENTIFIER_POINTER
>> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
>> -         fprintf (final_output, "\n;; Function (%s) %s\n\n", aname,
>> -            node->frequency == NODE_FREQUENCY_HOT
>> -            ? " (hot)"
>> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>> -            ? " (unlikely executed)"
>> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>> -            ? " (executed once)"
>> -            : "");
>> +         pass_dump_function_header (final_output, current_function_decl,
cfun);
>>
>>          flag_dump_noaddr = flag_dump_unnumbered = 1;
>>          if (flag_compare_debug_opt || flag_compare_debug)
>> Index: common.opt
>> ===================================================================
>> --- common.opt  (revision 173635)
>> +++ common.opt  (working copy)
>> @@ -1018,6 +1018,14 @@ fdiagnostics-show-option
>>  Common Var(flag_diagnostics_show_option) Init(1)
>>  Amend appropriate diagnostic messages with the command line option that
controls them
>>
>> +fdisable-
>> +Common Joined RejectNegative Var(common_deferred_options) Defer
>> +-fdisable-[tree|rtl|ipa]-<pass>=range1+range2 disables an optimization pass
>> +
>> +fenable-
>> +Common Joined RejectNegative Var(common_deferred_options) Defer
>> +-fenable-[tree|rtl|ipa]-<pass>=range1+range2 enables an optimization pass
>> +
>>  fdump-
>>  Common Joined RejectNegative Var(common_deferred_options) Defer
>>  -fdump-<type>  Dump various compiler internals to a file
>> Index: opts-global.c
>> ===================================================================
>> --- opts-global.c       (revision 173635)
>> +++ opts-global.c       (working copy)
>> @@ -411,6 +411,12 @@ handle_common_deferred_options (void)
>>            error ("unrecognized command line option %<-fdump-%s%>",
opt->arg);
>>          break;
>>
>> +       case OPT_fenable_:
>> +       case OPT_fdisable_:
>> +         enable_disable_pass (opt->arg, (opt->opt_index == OPT_fenable_?
>> +                              true : false));
>> +          break;
>> +
>>        case OPT_ffixed_:
>>          /* Deferred.  */
>>          fix_register (opt->arg, 1, 1);
>> Index: tree-cfg.c
>> ===================================================================
>> --- tree-cfg.c  (revision 173636)
>> +++ tree-cfg.c  (working copy)
>> @@ -2090,11 +2090,7 @@ gimple_dump_cfg (FILE *file, int flags)
>>  {
>>   if (flags & TDF_DETAILS)
>>     {
>> -      const char *funcname
>> -       = lang_hooks.decl_printable_name (current_function_decl, 2);
>> -
>> -      fputc ('\n', file);
>> -      fprintf (file, ";; Function %s\n\n", funcname);
>> +      pass_dump_function_header (file, current_function_decl, cfun);
>>       fprintf (file, ";; \n%d basic blocks, %d edges, last basic block
%d.\n\n",
>>               n_basic_blocks, n_edges, last_basic_block);
>>
>> Index: passes.c
>> ===================================================================
>> --- passes.c    (revision 173635)
>> +++ passes.c    (working copy)
>> @@ -382,7 +382,7 @@ void
>>  register_one_dump_file (struct opt_pass *pass)
>>  {
>>   char *dot_name, *flag_name, *glob_name;
>> -  const char *name, *prefix;
>> +  const char *name, *full_name, *prefix;
>>   char num[10];
>>   int flags, id;
>>
>> @@ -411,6 +411,8 @@ register_one_dump_file (struct opt_pass
>>   glob_name = concat (prefix, name, NULL);
>>   id = dump_register (dot_name, flag_name, glob_name, flags);
>>   set_pass_for_id (id, pass);
>> +  full_name = concat (prefix, pass->name, num, NULL);
>> +  register_pass_name (pass, full_name);
>>  }
>>
>>  /* Recursive worker function for register_dump_files.  */
>> @@ -454,6 +456,298 @@ register_dump_files (struct opt_pass *pa
>>   register_dump_files_1 (pass, properties);
>>  }
>>
>> +struct pass_registry
>> +{
>> +  const char* unique_name;
>> +  struct opt_pass *pass;
>> +};
>> +
>> +/* Pass registry hash function.  */
>> +
>> +static hashval_t
>> +passr_hash (const void *p)
>> +{
>> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
>> +  return htab_hash_string (s->unique_name);
>> +}
>> +
>> +/* Hash equal function  */
>> +
>> +static int
>> +passr_eq (const void *p1, const void *p2)
>> +{
>> +  const struct pass_registry *const s1 = (const struct pass_registry *const)
p1;
>> +  const struct pass_registry *const s2 = (const struct pass_registry *const)
p2;
>> +
>> +  return !strcmp (s1->unique_name, s2->unique_name);
>> +}
>> +
>> +static htab_t pass_name_tab = NULL;
>> +
>> +/* Register PASS with NAME.  */
>> +
>> +void
>> +register_pass_name (struct opt_pass *pass, const char *name)
>> +{
>> +  struct pass_registry **slot;
>> +  struct pass_registry pr;
>> +
>> +  if (!pass_name_tab)
>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>> +
>> +  pr.unique_name = name;
>> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
INSERT);
>> +  if (!*slot)
>> +    {
>> +      struct pass_registry *new_pr;
>> +
>> +      new_pr = XCNEW (struct pass_registry);
>> +      new_pr->unique_name = xstrdup (name);
>> +      new_pr->pass = pass;
>> +      *slot = new_pr;
>> +    }
>> +  else
>> +    gcc_assert ((*slot)->pass == pass);
>> +}
>> +
>> +/* Returns the pass with NAME.  */
>> +
>> +struct opt_pass *
>> +get_pass_by_name (const char *name)
>> +{
>> +  struct pass_registry **slot, pr;
>> +
>> +  gcc_assert (pass_name_tab);
>> +  pr.unique_name = name;
>> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
NO_INSERT);
>> +
>> +  if (!slot || !*slot)
>> +    return NULL;
>> +
>> +  return (*slot)->pass;
>> +}
>> +
>> +
>> +/* Range [start, last].  */
>> +
>> +struct uid_range
>> +{
>> +  struct opt_pass *pass;
>> +  unsigned int start;
>> +  unsigned int last;
>> +  struct uid_range *next;
>> +};
>> +
>> +/* Hash function for pass structure.  */
>> +
>> +static hashval_t
>> +pass_hash (const void *s)
>> +{
>> +  const struct uid_range *const p = (const struct uid_range *const) s;
>> +  return p->pass->static_pass_number;
>> +}
>> +
>> +/* Pass equal function  */
>> +
>> +static int
>> +pass_eq (const void *s1, const void *s2)
>> +{
>> +  const struct uid_range *const p1 = (const struct uid_range *const) s1;
>> +  const struct uid_range *const p2 = (const struct uid_range *const) s2;
>> +  return p1->pass->static_pass_number == p2->pass->static_pass_number;
>> +}
>> +
>> +htab_t enabled_pass_uid_range_tab = NULL;
>> +htab_t disabled_pass_uid_range_tab = NULL;
>> +
>> +/* Parse option string for -fdisable- and -fenabler-
>> +   The syntax of the options:
>> +
>> +   -fenable-<pass_name>
>> +   -fdisable-<pass_name>
>> +
>> +   -fenable-<pass_name>=s1:e1,s2:e2,...
>> +   -fdisable-<pass_name>=s1:e1,s2:e2,...
>> +*/
>> +
>> +void
>> +enable_disable_pass (const char *arg, bool is_enable)
>> +{
>> +  struct opt_pass *pass;
>> +  htab_t the_tab;
>> +  char *range_str, *phase_name;
>> +  char *argstr = xstrdup (arg);
>> +
>> +  range_str = strchr (argstr,'=');
>> +  if (range_str)
>> +    {
>> +      *range_str = '\0';
>> +      range_str++;
>> +    }
>> +
>> +  phase_name = argstr;
>> +  if (!*phase_name)
>> +    {
>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>> +      free (argstr);
>> +      return;
>> +    }
>> +  pass = get_pass_by_name (phase_name);
>> +  if (!pass)
>> +    {
>> +      error ("Unknown pass %s specified in %s",
>> +            phase_name,
>> +            is_enable ? "-fenable" : "-fdisable");
>> +      free (argstr);
>> +      return;
>> +    }
>> +  if (is_enable)
>> +    {
>> +      if (!enabled_pass_uid_range_tab)
>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>> +      the_tab = enabled_pass_uid_range_tab;
>> +    }
>> +  else
>> +    {
>> +      if (!disabled_pass_uid_range_tab)
>> +       disabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>> +      the_tab = disabled_pass_uid_range_tab;
>> +    }
>> +
>> +  if (!range_str)
>> +    {
>> +      struct uid_range **slot;
>> +      struct uid_range *new_range = XCNEW (struct uid_range);
>> +
>> +      new_range->pass = pass;
>> +      new_range->start = 0;
>> +      new_range->last = (unsigned)-1;
>> +
>> +      slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
>> +      new_range->next = *slot;
>> +      *slot = new_range;
>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>> +    }
>> +  else
>> +    {
>> +      char *next_range = NULL;
>> +      char *one_range = range_str;
>> +      char *end_val = NULL;
>> +
>> +      do
>> +       {
>> +         struct uid_range **slot;
>> +         struct uid_range *new_range;
>> +         char *invalid = NULL;
>> +         long start;
>> +
>> +         next_range = strchr (one_range, ',');
>> +         if (next_range)
>> +           {
>> +             *next_range = '\0';
>> +             next_range++;
>> +           }
>> +
>> +         end_val = strchr (one_range, ':');
>> +         if (end_val)
>> +           {
>> +             *end_val = '\0';
>> +             end_val++;
>> +           }
>> +         start = strtol (one_range, &invalid, 10);
>> +         if (*invalid || start < 0)
>> +           {
>> +             error ("Invalid range %s in option %s",
>> +                    one_range,
>> +                    is_enable ? "-fenable" : "-fdisable");
>> +             free (argstr);
>> +             return;
>> +           }
>> +         if (!end_val)
>> +           {
>> +             new_range = XCNEW (struct uid_range);
>> +              new_range->pass = pass;
>> +             new_range->start = (unsigned) start;
>> +             new_range->last = (unsigned) start;
>> +           }
>> +         else
>> +           {
>> +             long last = strtol (end_val, &invalid, 10);
>> +             if (*invalid || last < start)
>> +               {
>> +                 error ("Invalid range %s in option %s",
>> +                        end_val,
>> +                        is_enable ? "-fenable" : "-fdisable");
>> +                 free (argstr);
>> +                 return;
>> +               }
>> +             new_range = XCNEW (struct uid_range);
>> +              new_range->pass = pass;
>> +             new_range->start = (unsigned) start;
>> +             new_range->last = (unsigned) last;
>> +           }
>> +         slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
>> +         new_range->next = *slot;
>> +         *slot = new_range;
>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>> +
>> +         one_range = next_range;
>> +       } while (next_range);
>> +    }
>> +
>> +  free (argstr);
>> +}
>> +
>> +/* Returns true if PASS is explicitly enabled/disabled for FUNC.  */
>> +
>> +static bool
>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>> +                                       tree func, htab_t tab)
>> +{
>> +  struct uid_range **slot, *range, key;
>> +  int cgraph_uid;
>> +
>> +  if (!tab)
>> +    return false;
>> +
>> +  key.pass = pass;
>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>> +  if (!slot || !*slot)
>> +    return false;
>> +
>> +  cgraph_uid = func ? cgraph_node (func)->uid : 0;
>> +
>> +  range = *slot;
>> +  while (range)
>> +    {
>> +      if ((unsigned) cgraph_uid >= range->start
>> +         && (unsigned) cgraph_uid <= range->last)
>> +       return true;
>> +      range = range->next;
>> +    }
>> +
>> +  return false;
>> +}
>> +
>> +/* Returns true if PASS is explicitly enabled for FUNC.  */
>> +
>> +bool
>> +is_pass_explicitly_enabled (struct opt_pass *pass, tree func)
>> +{
>> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
enabled_pass_uid_range_tab);
>> +}
>> +
>> +/* Returns true if PASS is explicitly disabled for FUNC.  */
>> +
>> +bool
>> +is_pass_explicitly_disabled (struct opt_pass *pass, tree func)
>> +{
>> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
disabled_pass_uid_range_tab);
>> +}
>> +
>> +
>>  /* Look at the static_pass_number and duplicate the pass
>>    if it is already added to a list. */
>>
>> @@ -1349,6 +1643,29 @@ verify_curr_properties (void *data)
>>  }
>>  #endif
>>
>> +void
>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function
*fun)
>> +{
>> +  const char *dname, *aname;
>> +  struct cgraph_node *node = cgraph_node (fdecl);
>> +  dname = lang_hooks.decl_printable_name (fdecl, 2);
>> +  aname = (IDENTIFIER_POINTER
>> +          (DECL_ASSEMBLER_NAME (fdecl)));
>> +  if (L_IPO_COMP_MODE)
>> +    fprintf (dump_file, "\n;; Function %s (%s)[%d:%d][uid=%d]", dname,
aname,
>> +            FUNC_DECL_MODULE_ID (fun), FUNC_DECL_FUNC_ID (fun), node->uid);
>> +  else
>> +    fprintf (dump_file, "\n;; Function %s (%s)[uid=%d]", dname, aname,
node->uid);
>> +  fprintf (dump_file, "%s\n\n",
>> +           node->frequency == NODE_FREQUENCY_HOT
>> +           ? " (hot)"
>> +           : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>> +           ? " (unlikely executed)"
>> +           : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>> +           ? " (executed once)"
>> +           : "");
>> +}
>> +
>>  /* Initialize pass dump file.  */
>>  /* This is non-static so that the plugins can use it.  */
>>
>> @@ -1362,26 +1679,7 @@ pass_init_dump_file (struct opt_pass *pa
>>       dump_file_name = get_dump_file_name (pass->static_pass_number);
>>       dump_file = dump_begin (pass->static_pass_number, &dump_flags);
>>       if (dump_file && current_function_decl)
>> -       {
>> -         const char *dname, *aname;
>> -         struct cgraph_node *node = cgraph_node (current_function_decl);
>> -         dname = lang_hooks.decl_printable_name (current_function_decl, 2);
>> -         aname = (IDENTIFIER_POINTER
>> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
>> -         if (L_IPO_COMP_MODE)
>> -           fprintf (dump_file, "\n;; Function %s (%s)[%d:%d]", dname, aname,
>> -                    FUNC_DECL_MODULE_ID (cfun), FUNC_DECL_FUNC_ID (cfun));
>> -         else
>> -           fprintf (dump_file, "\n;; Function %s (%s)", dname, aname);
>> -         fprintf (dump_file, "%s\n\n",
>> -            node->frequency == NODE_FREQUENCY_HOT
>> -            ? " (hot)"
>> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>> -            ? " (unlikely executed)"
>> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>> -            ? " (executed once)"
>> -            : "");
>> -       }
>> +        pass_dump_function_header (dump_file, current_function_decl, cfun);
>>       return initializing_dump;
>>     }
>>   else
>> @@ -1525,6 +1823,8 @@ execute_one_pass (struct opt_pass *pass)
>>  {
>>   bool initializing_dump;
>>   unsigned int todo_after = 0;
>> +  bool explicitly_enabled = false;
>> +  bool explicitly_disabled = false;
>>
>>   bool gate_status;
>>
>> @@ -1535,11 +1835,15 @@ execute_one_pass (struct opt_pass *pass)
>>   else
>>     gcc_assert (cfun && current_function_decl);
>>
>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
current_function_decl);
>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
current_function_decl);
>> +
>>   current_pass = pass;
>>
>>   /* Check whether gate check should be avoided.
>>      User controls the value of the gate through the parameter "gate_status".
*/
>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>> +  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);
>>
>>   /* Override gate with plugin.  */
>>   invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);
>>
>> --
>> This patch is available for review at http://codereview.appspot.com/4550056
>>
>

[davidxl, 2011-05-18 22:38:58]

The attached is the revised patch. Bootstrap and regression tested in
trunk on x86-64/linux.

Ok for checkin?

Thanks,

David

On Wed, May 18, 2011 at 1:34 PM, Xinliang David Li <davidxl@google.com> wrote:
> Will fix the Changelog, and add documentation.
>
> Thanks,
>
> David
>
>
>
> On Wed, May 18, 2011 at 1:26 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, May 18, 2011 at 8:37 PM, David Li <davidxl@google.com> wrote:
>>>
>>> In gcc, not all passes have user level control to turn it on/off, and
>>> there is no way to flip on/off the pass for a subset of functions. I
>>> implemented a generic option handling scheme in gcc to allow
>>> disabling/enabling any gcc pass for any specified function(s).  The
>>> new options will be very useful for things like performance
>>> experiments and bug triaging (gcc has dbgcnt mechanism, but not all
>>> passes have the counter).
>>>
>>> The option syntax is very similar to -fdump- options. The following
>>> are some examples:
>>>
>>> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
>>> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>>>                           whose cgraphnode uid is 1
>>> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>>>                                           functions at the following
>>>                                            ranges [1,1], [300,400], and
[400,1000]
>>> -fdisable-tree-einline --> disable early inlining for all callers
>>> -fdisable-ipa-inline --> disable ipa inlininig
>>>
>>> In the gcc dumps, the uid numbers are displayed in the function header.
>>>
>>> The options are intended to be used internally by gcc developers.
>>>
>>> Ok for trunk ? (There is a little LIPO specific change that can be removed).
>>>
>>> David
>>>
>>> 2011-05-18  David Li  <davidxl@google.com>
>>>
>>>        * final.c (rest_of_clean_state): Call function header dumper.
>>>        * opts-global.c (handle_common_deferred_options): Handle new options.
>>>        * tree-cfg.c (gimple_dump_cfg): Call function header dumper.
>>>        * passes.c (register_one_dump_file): Call register_pass_name.
>>>        (pass_init_dump_file): Call function header dumper.
>>>        (execute_one_pass): Check explicit enable/disable flag.
>>>        (passr_hash): New function.
>>>        (passr_eq):
>>>        (register_pass_name):
>>>        (get_pass_by_name):
>>>        (pass_hash):
>>>        (pass_eq):
>>>        (enable_disable_pass):
>>>        (is_pass_explicitly_enabled_or_disabled):
>>>        (is_pass_explicitly_enabled):
>>>        (is_pass_explicitly_disabled):
>>
>> Bogus changelog entry.
>>
>> New options need documenting in doc/invoke.texi.
>>
>> Richard.
>>
>>>
>>> Index: tree-pass.h
>>> ===================================================================
>>> --- tree-pass.h (revision 173635)
>>> +++ tree-pass.h (working copy)
>>> @@ -644,4 +644,12 @@ extern bool first_pass_instance;
>>>  /* Declare for plugins.  */
>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>
>>> +extern void enable_disable_pass (const char *, bool);
>>> +extern bool is_pass_explicitly_disabled (struct opt_pass *, tree);
>>> +extern bool is_pass_explicitly_enabled (struct opt_pass *, tree);
>>> +extern void register_pass_name (struct opt_pass *, const char *);
>>> +extern struct opt_pass *get_pass_by_name (const char *);
>>> +struct function;
>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>> +
>>>  #endif /* GCC_TREE_PASS_H */
>>> Index: final.c
>>> ===================================================================
>>> --- final.c     (revision 173635)
>>> +++ final.c     (working copy)
>>> @@ -4456,19 +4456,7 @@ rest_of_clean_state (void)
>>>        }
>>>       else
>>>        {
>>> -         const char *aname;
>>> -         struct cgraph_node *node = cgraph_node (current_function_decl);
>>> -
>>> -         aname = (IDENTIFIER_POINTER
>>> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
>>> -         fprintf (final_output, "\n;; Function (%s) %s\n\n", aname,
>>> -            node->frequency == NODE_FREQUENCY_HOT
>>> -            ? " (hot)"
>>> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>>> -            ? " (unlikely executed)"
>>> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>>> -            ? " (executed once)"
>>> -            : "");
>>> +         pass_dump_function_header (final_output, current_function_decl,
cfun);
>>>
>>>          flag_dump_noaddr = flag_dump_unnumbered = 1;
>>>          if (flag_compare_debug_opt || flag_compare_debug)
>>> Index: common.opt
>>> ===================================================================
>>> --- common.opt  (revision 173635)
>>> +++ common.opt  (working copy)
>>> @@ -1018,6 +1018,14 @@ fdiagnostics-show-option
>>>  Common Var(flag_diagnostics_show_option) Init(1)
>>>  Amend appropriate diagnostic messages with the command line option that
controls them
>>>
>>> +fdisable-
>>> +Common Joined RejectNegative Var(common_deferred_options) Defer
>>> +-fdisable-[tree|rtl|ipa]-<pass>=range1+range2 disables an optimization pass
>>> +
>>> +fenable-
>>> +Common Joined RejectNegative Var(common_deferred_options) Defer
>>> +-fenable-[tree|rtl|ipa]-<pass>=range1+range2 enables an optimization pass
>>> +
>>>  fdump-
>>>  Common Joined RejectNegative Var(common_deferred_options) Defer
>>>  -fdump-<type>  Dump various compiler internals to a file
>>> Index: opts-global.c
>>> ===================================================================
>>> --- opts-global.c       (revision 173635)
>>> +++ opts-global.c       (working copy)
>>> @@ -411,6 +411,12 @@ handle_common_deferred_options (void)
>>>            error ("unrecognized command line option %<-fdump-%s%>",
opt->arg);
>>>          break;
>>>
>>> +       case OPT_fenable_:
>>> +       case OPT_fdisable_:
>>> +         enable_disable_pass (opt->arg, (opt->opt_index == OPT_fenable_?
>>> +                              true : false));
>>> +          break;
>>> +
>>>        case OPT_ffixed_:
>>>          /* Deferred.  */
>>>          fix_register (opt->arg, 1, 1);
>>> Index: tree-cfg.c
>>> ===================================================================
>>> --- tree-cfg.c  (revision 173636)
>>> +++ tree-cfg.c  (working copy)
>>> @@ -2090,11 +2090,7 @@ gimple_dump_cfg (FILE *file, int flags)
>>>  {
>>>   if (flags & TDF_DETAILS)
>>>     {
>>> -      const char *funcname
>>> -       = lang_hooks.decl_printable_name (current_function_decl, 2);
>>> -
>>> -      fputc ('\n', file);
>>> -      fprintf (file, ";; Function %s\n\n", funcname);
>>> +      pass_dump_function_header (file, current_function_decl, cfun);
>>>       fprintf (file, ";; \n%d basic blocks, %d edges, last basic block
%d.\n\n",
>>>               n_basic_blocks, n_edges, last_basic_block);
>>>
>>> Index: passes.c
>>> ===================================================================
>>> --- passes.c    (revision 173635)
>>> +++ passes.c    (working copy)
>>> @@ -382,7 +382,7 @@ void
>>>  register_one_dump_file (struct opt_pass *pass)
>>>  {
>>>   char *dot_name, *flag_name, *glob_name;
>>> -  const char *name, *prefix;
>>> +  const char *name, *full_name, *prefix;
>>>   char num[10];
>>>   int flags, id;
>>>
>>> @@ -411,6 +411,8 @@ register_one_dump_file (struct opt_pass
>>>   glob_name = concat (prefix, name, NULL);
>>>   id = dump_register (dot_name, flag_name, glob_name, flags);
>>>   set_pass_for_id (id, pass);
>>> +  full_name = concat (prefix, pass->name, num, NULL);
>>> +  register_pass_name (pass, full_name);
>>>  }
>>>
>>>  /* Recursive worker function for register_dump_files.  */
>>> @@ -454,6 +456,298 @@ register_dump_files (struct opt_pass *pa
>>>   register_dump_files_1 (pass, properties);
>>>  }
>>>
>>> +struct pass_registry
>>> +{
>>> +  const char* unique_name;
>>> +  struct opt_pass *pass;
>>> +};
>>> +
>>> +/* Pass registry hash function.  */
>>> +
>>> +static hashval_t
>>> +passr_hash (const void *p)
>>> +{
>>> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
>>> +  return htab_hash_string (s->unique_name);
>>> +}
>>> +
>>> +/* Hash equal function  */
>>> +
>>> +static int
>>> +passr_eq (const void *p1, const void *p2)
>>> +{
>>> +  const struct pass_registry *const s1 = (const struct pass_registry
*const) p1;
>>> +  const struct pass_registry *const s2 = (const struct pass_registry
*const) p2;
>>> +
>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>> +}
>>> +
>>> +static htab_t pass_name_tab = NULL;
>>> +
>>> +/* Register PASS with NAME.  */
>>> +
>>> +void
>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>> +{
>>> +  struct pass_registry **slot;
>>> +  struct pass_registry pr;
>>> +
>>> +  if (!pass_name_tab)
>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>> +
>>> +  pr.unique_name = name;
>>> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
INSERT);
>>> +  if (!*slot)
>>> +    {
>>> +      struct pass_registry *new_pr;
>>> +
>>> +      new_pr = XCNEW (struct pass_registry);
>>> +      new_pr->unique_name = xstrdup (name);
>>> +      new_pr->pass = pass;
>>> +      *slot = new_pr;
>>> +    }
>>> +  else
>>> +    gcc_assert ((*slot)->pass == pass);
>>> +}
>>> +
>>> +/* Returns the pass with NAME.  */
>>> +
>>> +struct opt_pass *
>>> +get_pass_by_name (const char *name)
>>> +{
>>> +  struct pass_registry **slot, pr;
>>> +
>>> +  gcc_assert (pass_name_tab);
>>> +  pr.unique_name = name;
>>> +  slot = (struct pass_registry **) htab_find_slot (pass_name_tab, &pr,
NO_INSERT);
>>> +
>>> +  if (!slot || !*slot)
>>> +    return NULL;
>>> +
>>> +  return (*slot)->pass;
>>> +}
>>> +
>>> +
>>> +/* Range [start, last].  */
>>> +
>>> +struct uid_range
>>> +{
>>> +  struct opt_pass *pass;
>>> +  unsigned int start;
>>> +  unsigned int last;
>>> +  struct uid_range *next;
>>> +};
>>> +
>>> +/* Hash function for pass structure.  */
>>> +
>>> +static hashval_t
>>> +pass_hash (const void *s)
>>> +{
>>> +  const struct uid_range *const p = (const struct uid_range *const) s;
>>> +  return p->pass->static_pass_number;
>>> +}
>>> +
>>> +/* Pass equal function  */
>>> +
>>> +static int
>>> +pass_eq (const void *s1, const void *s2)
>>> +{
>>> +  const struct uid_range *const p1 = (const struct uid_range *const) s1;
>>> +  const struct uid_range *const p2 = (const struct uid_range *const) s2;
>>> +  return p1->pass->static_pass_number == p2->pass->static_pass_number;
>>> +}
>>> +
>>> +htab_t enabled_pass_uid_range_tab = NULL;
>>> +htab_t disabled_pass_uid_range_tab = NULL;
>>> +
>>> +/* Parse option string for -fdisable- and -fenabler-
>>> +   The syntax of the options:
>>> +
>>> +   -fenable-<pass_name>
>>> +   -fdisable-<pass_name>
>>> +
>>> +   -fenable-<pass_name>=s1:e1,s2:e2,...
>>> +   -fdisable-<pass_name>=s1:e1,s2:e2,...
>>> +*/
>>> +
>>> +void
>>> +enable_disable_pass (const char *arg, bool is_enable)
>>> +{
>>> +  struct opt_pass *pass;
>>> +  htab_t the_tab;
>>> +  char *range_str, *phase_name;
>>> +  char *argstr = xstrdup (arg);
>>> +
>>> +  range_str = strchr (argstr,'=');
>>> +  if (range_str)
>>> +    {
>>> +      *range_str = '\0';
>>> +      range_str++;
>>> +    }
>>> +
>>> +  phase_name = argstr;
>>> +  if (!*phase_name)
>>> +    {
>>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>>> +      free (argstr);
>>> +      return;
>>> +    }
>>> +  pass = get_pass_by_name (phase_name);
>>> +  if (!pass)
>>> +    {
>>> +      error ("Unknown pass %s specified in %s",
>>> +            phase_name,
>>> +            is_enable ? "-fenable" : "-fdisable");
>>> +      free (argstr);
>>> +      return;
>>> +    }
>>> +  if (is_enable)
>>> +    {
>>> +      if (!enabled_pass_uid_range_tab)
>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>> +      the_tab = enabled_pass_uid_range_tab;
>>> +    }
>>> +  else
>>> +    {
>>> +      if (!disabled_pass_uid_range_tab)
>>> +       disabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>> +      the_tab = disabled_pass_uid_range_tab;
>>> +    }
>>> +
>>> +  if (!range_str)
>>> +    {
>>> +      struct uid_range **slot;
>>> +      struct uid_range *new_range = XCNEW (struct uid_range);
>>> +
>>> +      new_range->pass = pass;
>>> +      new_range->start = 0;
>>> +      new_range->last = (unsigned)-1;
>>> +
>>> +      slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
>>> +      new_range->next = *slot;
>>> +      *slot = new_range;
>>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>>> +    }
>>> +  else
>>> +    {
>>> +      char *next_range = NULL;
>>> +      char *one_range = range_str;
>>> +      char *end_val = NULL;
>>> +
>>> +      do
>>> +       {
>>> +         struct uid_range **slot;
>>> +         struct uid_range *new_range;
>>> +         char *invalid = NULL;
>>> +         long start;
>>> +
>>> +         next_range = strchr (one_range, ',');
>>> +         if (next_range)
>>> +           {
>>> +             *next_range = '\0';
>>> +             next_range++;
>>> +           }
>>> +
>>> +         end_val = strchr (one_range, ':');
>>> +         if (end_val)
>>> +           {
>>> +             *end_val = '\0';
>>> +             end_val++;
>>> +           }
>>> +         start = strtol (one_range, &invalid, 10);
>>> +         if (*invalid || start < 0)
>>> +           {
>>> +             error ("Invalid range %s in option %s",
>>> +                    one_range,
>>> +                    is_enable ? "-fenable" : "-fdisable");
>>> +             free (argstr);
>>> +             return;
>>> +           }
>>> +         if (!end_val)
>>> +           {
>>> +             new_range = XCNEW (struct uid_range);
>>> +              new_range->pass = pass;
>>> +             new_range->start = (unsigned) start;
>>> +             new_range->last = (unsigned) start;
>>> +           }
>>> +         else
>>> +           {
>>> +             long last = strtol (end_val, &invalid, 10);
>>> +             if (*invalid || last < start)
>>> +               {
>>> +                 error ("Invalid range %s in option %s",
>>> +                        end_val,
>>> +                        is_enable ? "-fenable" : "-fdisable");
>>> +                 free (argstr);
>>> +                 return;
>>> +               }
>>> +             new_range = XCNEW (struct uid_range);
>>> +              new_range->pass = pass;
>>> +             new_range->start = (unsigned) start;
>>> +             new_range->last = (unsigned) last;
>>> +           }
>>> +         slot = (struct uid_range **) htab_find_slot (the_tab, new_range,
INSERT);
>>> +         new_range->next = *slot;
>>> +         *slot = new_range;
>>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>>> +
>>> +         one_range = next_range;
>>> +       } while (next_range);
>>> +    }
>>> +
>>> +  free (argstr);
>>> +}
>>> +
>>> +/* Returns true if PASS is explicitly enabled/disabled for FUNC.  */
>>> +
>>> +static bool
>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>> +                                       tree func, htab_t tab)
>>> +{
>>> +  struct uid_range **slot, *range, key;
>>> +  int cgraph_uid;
>>> +
>>> +  if (!tab)
>>> +    return false;
>>> +
>>> +  key.pass = pass;
>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>> +  if (!slot || !*slot)
>>> +    return false;
>>> +
>>> +  cgraph_uid = func ? cgraph_node (func)->uid : 0;
>>> +
>>> +  range = *slot;
>>> +  while (range)
>>> +    {
>>> +      if ((unsigned) cgraph_uid >= range->start
>>> +         && (unsigned) cgraph_uid <= range->last)
>>> +       return true;
>>> +      range = range->next;
>>> +    }
>>> +
>>> +  return false;
>>> +}
>>> +
>>> +/* Returns true if PASS is explicitly enabled for FUNC.  */
>>> +
>>> +bool
>>> +is_pass_explicitly_enabled (struct opt_pass *pass, tree func)
>>> +{
>>> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
enabled_pass_uid_range_tab);
>>> +}
>>> +
>>> +/* Returns true if PASS is explicitly disabled for FUNC.  */
>>> +
>>> +bool
>>> +is_pass_explicitly_disabled (struct opt_pass *pass, tree func)
>>> +{
>>> +  return is_pass_explicitly_enabled_or_disabled (pass, func,
disabled_pass_uid_range_tab);
>>> +}
>>> +
>>> +
>>>  /* Look at the static_pass_number and duplicate the pass
>>>    if it is already added to a list. */
>>>
>>> @@ -1349,6 +1643,29 @@ verify_curr_properties (void *data)
>>>  }
>>>  #endif
>>>
>>> +void
>>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function
*fun)
>>> +{
>>> +  const char *dname, *aname;
>>> +  struct cgraph_node *node = cgraph_node (fdecl);
>>> +  dname = lang_hooks.decl_printable_name (fdecl, 2);
>>> +  aname = (IDENTIFIER_POINTER
>>> +          (DECL_ASSEMBLER_NAME (fdecl)));
>>> +  if (L_IPO_COMP_MODE)
>>> +    fprintf (dump_file, "\n;; Function %s (%s)[%d:%d][uid=%d]", dname,
aname,
>>> +            FUNC_DECL_MODULE_ID (fun), FUNC_DECL_FUNC_ID (fun), node->uid);
>>> +  else
>>> +    fprintf (dump_file, "\n;; Function %s (%s)[uid=%d]", dname, aname,
node->uid);
>>> +  fprintf (dump_file, "%s\n\n",
>>> +           node->frequency == NODE_FREQUENCY_HOT
>>> +           ? " (hot)"
>>> +           : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>>> +           ? " (unlikely executed)"
>>> +           : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>>> +           ? " (executed once)"
>>> +           : "");
>>> +}
>>> +
>>>  /* Initialize pass dump file.  */
>>>  /* This is non-static so that the plugins can use it.  */
>>>
>>> @@ -1362,26 +1679,7 @@ pass_init_dump_file (struct opt_pass *pa
>>>       dump_file_name = get_dump_file_name (pass->static_pass_number);
>>>       dump_file = dump_begin (pass->static_pass_number, &dump_flags);
>>>       if (dump_file && current_function_decl)
>>> -       {
>>> -         const char *dname, *aname;
>>> -         struct cgraph_node *node = cgraph_node (current_function_decl);
>>> -         dname = lang_hooks.decl_printable_name (current_function_decl, 2);
>>> -         aname = (IDENTIFIER_POINTER
>>> -                  (DECL_ASSEMBLER_NAME (current_function_decl)));
>>> -         if (L_IPO_COMP_MODE)
>>> -           fprintf (dump_file, "\n;; Function %s (%s)[%d:%d]", dname,
aname,
>>> -                    FUNC_DECL_MODULE_ID (cfun), FUNC_DECL_FUNC_ID (cfun));
>>> -         else
>>> -           fprintf (dump_file, "\n;; Function %s (%s)", dname, aname);
>>> -         fprintf (dump_file, "%s\n\n",
>>> -            node->frequency == NODE_FREQUENCY_HOT
>>> -            ? " (hot)"
>>> -            : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>>> -            ? " (unlikely executed)"
>>> -            : node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>>> -            ? " (executed once)"
>>> -            : "");
>>> -       }
>>> +        pass_dump_function_header (dump_file, current_function_decl, cfun);
>>>       return initializing_dump;
>>>     }
>>>   else
>>> @@ -1525,6 +1823,8 @@ execute_one_pass (struct opt_pass *pass)
>>>  {
>>>   bool initializing_dump;
>>>   unsigned int todo_after = 0;
>>> +  bool explicitly_enabled = false;
>>> +  bool explicitly_disabled = false;
>>>
>>>   bool gate_status;
>>>
>>> @@ -1535,11 +1835,15 @@ execute_one_pass (struct opt_pass *pass)
>>>   else
>>>     gcc_assert (cfun && current_function_decl);
>>>
>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
current_function_decl);
>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
current_function_decl);
>>> +
>>>   current_pass = pass;
>>>
>>>   /* Check whether gate check should be avoided.
>>>      User controls the value of the gate through the parameter
"gate_status". */
>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>
>>>   /* Override gate with plugin.  */
>>>   invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);
>>>
>>> --
>>> This patch is available for review at http://codereview.appspot.com/4550056
>>>
>>
>

[andi_firstfloor.org, 2011-05-19 18:05:14]

davidxl@google.com (David Li) writes:

> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>                            whose cgraphnode uid is 1
> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>                                            functions at the following
>                                             ranges [1,1], [300,400],
> and [400,1000]

How are the ranges defined? I doubt numbers are a good interface here
to specify functions.

This would be better done with #pragmas? 

-Andi



-- 
ak@linux.intel.com -- Speaking for myself only

[davidxl, 2011-05-19 18:10:32]

On Thu, May 19, 2011 at 11:04 AM, Andi Kleen <andi@firstfloor.org> wrote:
> davidxl@google.com (David Li) writes:
>
>> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
>> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>>                            whose cgraphnode uid is 1
>> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>>                                            functions at the following
>>                                             ranges [1,1], [300,400],
>> and [400,1000]
>
> How are the ranges defined? I doubt numbers are a good interface here
> to specify functions.

The numbers are cgraph uids for the functions. The form that takes the
range is mainly for developers who use scripts to auto search (bug
triaging and optimization space traverse).

>
> This would be better done with #pragmas?

This is not good for automation. However, I do plan (later after this
patch is in) to add another form of the option which takes a comma
separated list of assembler names --- this form will be quite useful
to workaround compiler bugs temporarily in the make file.

David

>
> -Andi
>
>
>
> --
> ak@linux.intel.com -- Speaking for myself only
>

[andi_firstfloor.org, 2011-05-19 18:17:23]

On Thu, May 19, 2011 at 11:10:24AM -0700, Xinliang David Li wrote:
> On Thu, May 19, 2011 at 11:04 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > davidxl@google.com (David Li) writes:
> >
> >> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
> >> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
> >>                            whose cgraphnode uid is 1
> >> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
> >>                                            functions at the following
> >>                                             ranges [1,1], [300,400],
> >> and [400,1000]
> >
> > How are the ranges defined? I doubt numbers are a good interface here
> > to specify functions.
> 
> The numbers are cgraph uids for the functions. The form that takes the
> range is mainly for developers who use scripts to auto search (bug
> triaging and optimization space traverse).

How about function names?


> > This would be better done with #pragmas?
> 
> This is not good for automation. However, I do plan (later after this

Why not? It should be easy enough to write a script to add such
pragmas given a dwarf2 symbol->file:line dump

I think pragmas would be a lot more useful for non compiler developers.

-Andi

[davidxl, 2011-05-19 18:50:27]

On Thu, May 19, 2011 at 11:17 AM, Andi Kleen <andi@firstfloor.org> wrote:
> On Thu, May 19, 2011 at 11:10:24AM -0700, Xinliang David Li wrote:
>> On Thu, May 19, 2011 at 11:04 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> > davidxl@google.com (David Li) writes:
>> >
>> >> -fdisable-tree-ccp1    <--- disable ccp1 for all functions
>> >> -fenable-tree-cunroll=1   <--- enable complete unroll for the function
>> >>                            whose cgraphnode uid is 1
>> >> -fdisable-rtl-gcse2=1:100,300,400:1000   <-- disable gcse2 for
>> >>                                            functions at the following
>> >>                                             ranges [1,1], [300,400],
>> >> and [400,1000]
>> >
>> > How are the ranges defined? I doubt numbers are a good interface here
>> > to specify functions.
>>
>> The numbers are cgraph uids for the functions. The form that takes the
>> range is mainly for developers who use scripts to auto search (bug
>> triaging and optimization space traverse).
>
> How about function names?

Not so easy for things like binary search.

>
>
>> > This would be better done with #pragmas?
>>
>> This is not good for automation. However, I do plan (later after this
>
> Why not? It should be easy enough to write a script to add such
> pragmas given a dwarf2 symbol->file:line dump

This may require changes many many sources files as compared to a
simple command line tweak -- for most of the cases, you don't even
need to know the id ranges, and can be blindly set to a large initial
value.

>
> I think pragmas would be a lot more useful for non compiler developers.
>

As compared with the -fdisable-tree-xxx=func1,func2?

The semantics of the pragma is also in question -- does it apply to
all inline instances of the function with pragma or just the emitted
instance?

(The pragma scheme can be implemented independently if it is considered useful).

Thanks,

David


> -Andi
>

[davidxl, 2011-05-20 16:07:03]

Ok to check in this one?

Thanks,

David

On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 18 May 2011, David Li wrote:
>
>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>
>> +      error ("Unknown pass %s specified in %s",
>> +          phase_name,
>> +          is_enable ? "-fenable" : "-fdisable");
>
> Follow GNU Coding Standards for diagnostics (start with lowercase letter).
>
>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>
> Use separate calls to inform for the enable and disable cases, so that
> full sentences can be extracted for translation.
>
>> +           error ("Invalid range %s in option %s",
>> +                  one_range,
>> +                  is_enable ? "-fenable" : "-fdisable");
>
> GNU Coding Standards.
>
>> +               error ("Invalid range %s in option %s",
>
> Likewise.
>
>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>
> Again needs GCS and i18n fixes.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

[davidxl, 2011-05-22 23:17:11]

Ping.

David


On Fri, May 20, 2011 at 9:06 AM, Xinliang David Li <davidxl@google.com> wrote:
> Ok to check in this one?
>
> Thanks,
>
> David
>
> On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Wed, 18 May 2011, David Li wrote:
>>
>>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>>
>>> +      error ("Unknown pass %s specified in %s",
>>> +          phase_name,
>>> +          is_enable ? "-fenable" : "-fdisable");
>>
>> Follow GNU Coding Standards for diagnostics (start with lowercase letter).
>>
>>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>>
>> Use separate calls to inform for the enable and disable cases, so that
>> full sentences can be extracted for translation.
>>
>>> +           error ("Invalid range %s in option %s",
>>> +                  one_range,
>>> +                  is_enable ? "-fenable" : "-fdisable");
>>
>> GNU Coding Standards.
>>
>>> +               error ("Invalid range %s in option %s",
>>
>> Likewise.
>>
>>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>>
>> Again needs GCS and i18n fixes.
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
>>
>

[davidxl, 2011-05-25 16:18:29]

Ping. The link to the message:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html

Thanks,

David

On Sun, May 22, 2011 at 4:17 PM, Xinliang David Li <davidxl@google.com> wrote:
> Ping.
>
> David
>
>
> On Fri, May 20, 2011 at 9:06 AM, Xinliang David Li <davidxl@google.com> wrote:
>> Ok to check in this one?
>>
>> Thanks,
>>
>> David
>>
>> On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
>> <joseph@codesourcery.com> wrote:
>>> On Wed, 18 May 2011, David Li wrote:
>>>
>>>> +      error ("Unrecognized option %s", is_enable ? "-fenable" :
"-fdisable");
>>>
>>>> +      error ("Unknown pass %s specified in %s",
>>>> +          phase_name,
>>>> +          is_enable ? "-fenable" : "-fdisable");
>>>
>>> Follow GNU Coding Standards for diagnostics (start with lowercase letter).
>>>
>>>> +      inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range of
[%u, %u]\n",
>>>> +              is_enable? "Enable":"Disable", phase_name, new_range->start,
new_range->last);
>>>
>>> Use separate calls to inform for the enable and disable cases, so that
>>> full sentences can be extracted for translation.
>>>
>>>> +           error ("Invalid range %s in option %s",
>>>> +                  one_range,
>>>> +                  is_enable ? "-fenable" : "-fdisable");
>>>
>>> GNU Coding Standards.
>>>
>>>> +               error ("Invalid range %s in option %s",
>>>
>>> Likewise.
>>>
>>>> +          inform (UNKNOWN_LOCATION, "%s pass %s for functions in the range
of [%u, %u]\n",
>>>> +                  is_enable? "Enable":"Disable", phase_name,
new_range->start, new_range->last);
>>>
>>> Again needs GCS and i18n fixes.
>>>
>>> --
>>> Joseph S. Myers
>>> joseph@codesourcery.com
>>>
>>
>

[joseph_codesourcery.com, 2011-05-25 16:53:34]

On Wed, 25 May 2011, Xinliang David Li wrote:

> Ping. The link to the message:
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html

I don't consider this an option handling patch.  Patches adding whole new 
features involving new options should be reviewed by maintainers for the 
part of the compiler relevant to those features (since there isn't a pass 
manager maintainer, I guess that means middle-end).

-- 
Joseph S. Myers
joseph@codesourcery.com

[davidxl, 2011-05-25 17:21:19]

Fair enough.  Richard?

Thanks,

David

On Wed, May 25, 2011 at 9:53 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 25 May 2011, Xinliang David Li wrote:
>
>> Ping. The link to the message:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>
> I don't consider this an option handling patch.  Patches adding whole new
> features involving new options should be reviewed by maintainers for the
> part of the compiler relevant to those features (since there isn't a pass
> manager maintainer, I guess that means middle-end).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

[richard.guenther_gmail.com, 2011-05-26 09:04:29]

On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 25 May 2011, Xinliang David Li wrote:
>
>> Ping. The link to the message:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>
> I don't consider this an option handling patch.  Patches adding whole new
> features involving new options should be reviewed by maintainers for the
> part of the compiler relevant to those features (since there isn't a pass
> manager maintainer, I guess that means middle-end).

Hmm, I suppose then you reviewed the option handling parts and they
are ok?  Those globbing options always cause headache to me.

+-fenable-ipa-@var{pass} @gol
+-fenable-rtl-@var{pass} @gol
+-fenable-rtl-@var{pass}=@var{range-list} @gol
+-fenable-tree-@var{pass} @gol

so, no -fenable-tree-@var{pass}=@var{range-list}?

Does the pass name match 1:1 with the dump file name?  In which
case

+Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
pass is statically invoked in the compiler multiple times, the pass
name should be appended with a sequential number starting from 1.

isn't true as passes that are invoked only a single time lack the number
suffix (yes, I'd really like that to be changed ...)

Please break likes also in .texi files and stick to 80 columns.  Please
document that these options are debugging options and regular
options for enabling/disabling passes should be used.  I would suggest
to group documentation differently and document -fenable-* and
-fdisable-*, thus,

+ -fdisable-@var{kind}-@var{pass}
+ -fenable-@var{kind}-@var{pass}

Even in .texi files please two spaces after a full-stop.

+extern void enable_disable_pass (const char *, bool);

I'd rather have both enable_pass and disable_pass ;)

+struct function;
+extern void pass_dump_function_header (FILE *, tree, struct function *);

that's odd and probably should be split out, the function should
maybe reside in tree-pretty-print.c.

Index: tree-ssa-loop-ivopts.c
===================================================================
--- tree-ssa-loop-ivopts.c      (revision 173837)
+++ tree-ssa-loop-ivopts.c      (working copy)
@@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d

well - doesn't belong here ;)

+static hashval_t
+passr_hash (const void *p)
+{
+  const struct pass_registry *const s = (const struct pass_registry *const) p;
+  return htab_hash_string (s->unique_name);
+}
+
+/* Hash equal function  */
+
+static int
+passr_eq (const void *p1, const void *p2)
+{
+  const struct pass_registry *const s1 = (const struct pass_registry
*const) p1;
+  const struct pass_registry *const s2 = (const struct pass_registry
*const) p2;
+
+  return !strcmp (s1->unique_name, s2->unique_name);
+}

you can use htab_hash_string and strcmp directly, no need for these
wrappers.

+void
+register_pass_name (struct opt_pass *pass, const char *name)

doesn't seem to need exporting, so don't and make it static.

+  if (!pass_name_tab)
+    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);

see above, the initial size should be larger - we have 223 passes at the
moment, so use 256.

+  else
+    return; /* Ignore plugin passes.  */

?  You mean they might clash?

+struct opt_pass *
+get_pass_by_name (const char *name)

doesn't need exporting either.

+      if (is_enable)
+        error ("unrecognized option -fenable");
+      else
+        error ("unrecognized option -fdisable");

I think that should be fatal_error - Joseph?

+      if (is_enable)
+        error ("unknown pass %s specified in -fenable", phase_name);
+      else
+        error ("unknown pass %s specified in -fdisble", phase_name);

likewise.

+      if (!enabled_pass_uid_range_tab)
+       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq, NULL);

instead of using a hashtable here please use a VEC indexed by
the static_pass_number which shoud speed up

+static bool
+is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
+                                       tree func, htab_t tab)
+{
+  struct uid_range **slot, *range, key;
+  int cgraph_uid;
+
+  if (!tab)
+    return false;
+
+  key.pass = pass;
+  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
+  if (!slot || !*slot)
+    return false;

and simplify the code quite a bit.

+  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;

note that cgraph uids are recycled, so it might not be the best idea
to use them as discriminator (though I don't have a good idea how
to represent ranges without them).

+  explicitly_enabled = is_pass_explicitly_enabled (pass,
current_function_decl);
+  explicitly_disabled = is_pass_explicitly_disabled (pass,
current_function_decl);
+
   current_pass = pass;

   /* Check whether gate check should be avoided.
      User controls the value of the gate through the parameter
"gate_status". */
   gate_status = (pass->gate == NULL) ? true : pass->gate();
+  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);

so explicitly disabling wins over explicit enabling ;)  I think this
implementation detail and the fact that you always query both
hints at that the interface should be like

gate_status = override_gate_status (pass, current_function_decl, gate_status);

instead.

Thus, please split out the function header dumping changes and rework
the rest of the patch as suggested.

Thanks,
Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com
>

[joseph_codesourcery.com, 2011-05-26 12:05:16]

On Thu, 26 May 2011, Richard Guenther wrote:

> +      if (is_enable)
> +        error ("unrecognized option -fenable");
> +      else
> +        error ("unrecognized option -fdisable");
> 
> I think that should be fatal_error - Joseph?

No, all existing errors for unknown options are ordinary errors rather 
than fatal errors (though if the driver detects a problem it won't then 
run cc1).

-- 
Joseph S. Myers
joseph@codesourcery.com

[davidxl, 2011-05-26 21:04:11]

On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>
>>> Ping. The link to the message:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>
>> I don't consider this an option handling patch.  Patches adding whole new
>> features involving new options should be reviewed by maintainers for the
>> part of the compiler relevant to those features (since there isn't a pass
>> manager maintainer, I guess that means middle-end).
>
> Hmm, I suppose then you reviewed the option handling parts and they
> are ok?  Those globbing options always cause headache to me.
>
> +-fenable-ipa-@var{pass} @gol
> +-fenable-rtl-@var{pass} @gol
> +-fenable-rtl-@var{pass}=@var{range-list} @gol
> +-fenable-tree-@var{pass} @gol
>
> so, no -fenable-tree-@var{pass}=@var{range-list}?
>

Missed. Will add.


> Does the pass name match 1:1 with the dump file name?  In which
> case

Yes.

>
> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
> pass is statically invoked in the compiler multiple times, the pass
> name should be appended with a sequential number starting from 1.
>
> isn't true as passes that are invoked only a single time lack the number
> suffix (yes, I'd really like that to be changed ...)

Yes, pass with single static instance does not need number suffix.

>
> Please break likes also in .texi files and stick to 80 columns.

Done.

>  Please
> document that these options are debugging options and regular
> options for enabling/disabling passes should be used.  I would suggest
> to group documentation differently and document -fenable-* and
> -fdisable-*, thus,
>
> + -fdisable-@var{kind}-@var{pass}
> + -fenable-@var{kind}-@var{pass}
>
> Even in .texi files please two spaces after a full-stop.

Done

>
> +extern void enable_disable_pass (const char *, bool);
>
> I'd rather have both enable_pass and disable_pass ;)

Ok.

>
> +struct function;
> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>
> that's odd and probably should be split out, the function should
> maybe reside in tree-pretty-print.c.

Ok.

>
> Index: tree-ssa-loop-ivopts.c
> ===================================================================
> --- tree-ssa-loop-ivopts.c      (revision 173837)
> +++ tree-ssa-loop-ivopts.c      (working copy)
> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>
> well - doesn't belong here ;)

Sorry -- many things in the same client -- not needed with your latest
change anyway.

>
> +static hashval_t
> +passr_hash (const void *p)
> +{
> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
> +  return htab_hash_string (s->unique_name);
> +}
> +
> +/* Hash equal function  */
> +
> +static int
> +passr_eq (const void *p1, const void *p2)
> +{
> +  const struct pass_registry *const s1 = (const struct pass_registry
> *const) p1;
> +  const struct pass_registry *const s2 = (const struct pass_registry
> *const) p2;
> +
> +  return !strcmp (s1->unique_name, s2->unique_name);
> +}
>
> you can use htab_hash_string and strcmp directly, no need for these
> wrappers.

The hashtable entry is not string in this case. It is pass_registry,
thus the wrapper.

>
> +void
> +register_pass_name (struct opt_pass *pass, const char *name)
>
> doesn't seem to need exporting, so don't and make it static.

Done.

>
> +  if (!pass_name_tab)
> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>
> see above, the initial size should be larger - we have 223 passes at the
> moment, so use 256.

Done.

>
> +  else
> +    return; /* Ignore plugin passes.  */
>
> ?  You mean they might clash?

Yes, name clash.

>
> +struct opt_pass *
> +get_pass_by_name (const char *name)
>
> doesn't need exporting either.

Done.

>
> +      if (is_enable)
> +        error ("unrecognized option -fenable");
> +      else
> +        error ("unrecognized option -fdisable");
>
> I think that should be fatal_error - Joseph?
>
> +      if (is_enable)
> +        error ("unknown pass %s specified in -fenable", phase_name);
> +      else
> +        error ("unknown pass %s specified in -fdisble", phase_name);
>
> likewise.
>
> +      if (!enabled_pass_uid_range_tab)
> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>
> instead of using a hashtable here please use a VEC indexed by
> the static_pass_number which shoud speed up

Ok.  The reason I did not use it is because in most of the cases, the
htab will be very small -- it is determined by the number of passes
specified in the command line, while the VEC requires allocating const
size array. Not an issue as long as by default the array is not
allocated.

>
> +static bool
> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
> +                                       tree func, htab_t tab)
> +{
> +  struct uid_range **slot, *range, key;
> +  int cgraph_uid;
> +
> +  if (!tab)
> +    return false;
> +
> +  key.pass = pass;
> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
> +  if (!slot || !*slot)
> +    return false;
>
> and simplify the code quite a bit.
>
> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>
> note that cgraph uids are recycled, so it might not be the best idea
> to use them as discriminator (though I don't have a good idea how
> to represent ranges without them).

Yes. It is not a big problem as the blind search does not need to know
the id->name mapping. Once the id s found, it can be easily discovered
via dump.

>
> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
> current_function_decl);
> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
> current_function_decl);
> +
>   current_pass = pass;
>
>   /* Check whether gate check should be avoided.
>      User controls the value of the gate through the parameter
> "gate_status". */
>   gate_status = (pass->gate == NULL) ? true : pass->gate();
> +  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);
>
> so explicitly disabling wins over explicit enabling ;)  I think this
> implementation detail and the fact that you always query both
> hints at that the interface should be like
>
> gate_status = override_gate_status (pass, current_function_decl, gate_status);

Done.

>
> instead.
>
> Thus, please split out the function header dumping changes and rework
> the rest of the patch as suggested.

Split out. The new patch is attached.

Ok after testing is done?

Thanks,

David

>
> Thanks,
> Richard.
>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
>>
>

[davidxl, 2011-05-26 22:02:03]

The latest version that only exports 2 functions from passes.c.

David

On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com> wrote:
> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>> <joseph@codesourcery.com> wrote:
>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>
>>>> Ping. The link to the message:
>>>>
>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>
>>> I don't consider this an option handling patch.  Patches adding whole new
>>> features involving new options should be reviewed by maintainers for the
>>> part of the compiler relevant to those features (since there isn't a pass
>>> manager maintainer, I guess that means middle-end).
>>
>> Hmm, I suppose then you reviewed the option handling parts and they
>> are ok?  Those globbing options always cause headache to me.
>>
>> +-fenable-ipa-@var{pass} @gol
>> +-fenable-rtl-@var{pass} @gol
>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>> +-fenable-tree-@var{pass} @gol
>>
>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>
>
> Missed. Will add.
>
>
>> Does the pass name match 1:1 with the dump file name?  In which
>> case
>
> Yes.
>
>>
>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>> pass is statically invoked in the compiler multiple times, the pass
>> name should be appended with a sequential number starting from 1.
>>
>> isn't true as passes that are invoked only a single time lack the number
>> suffix (yes, I'd really like that to be changed ...)
>
> Yes, pass with single static instance does not need number suffix.
>
>>
>> Please break likes also in .texi files and stick to 80 columns.
>
> Done.
>
>>  Please
>> document that these options are debugging options and regular
>> options for enabling/disabling passes should be used.  I would suggest
>> to group documentation differently and document -fenable-* and
>> -fdisable-*, thus,
>>
>> + -fdisable-@var{kind}-@var{pass}
>> + -fenable-@var{kind}-@var{pass}
>>
>> Even in .texi files please two spaces after a full-stop.
>
> Done
>
>>
>> +extern void enable_disable_pass (const char *, bool);
>>
>> I'd rather have both enable_pass and disable_pass ;)
>
> Ok.
>
>>
>> +struct function;
>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>
>> that's odd and probably should be split out, the function should
>> maybe reside in tree-pretty-print.c.
>
> Ok.
>
>>
>> Index: tree-ssa-loop-ivopts.c
>> ===================================================================
>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>> +++ tree-ssa-loop-ivopts.c      (working copy)
>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>
>> well - doesn't belong here ;)
>
> Sorry -- many things in the same client -- not needed with your latest
> change anyway.
>
>>
>> +static hashval_t
>> +passr_hash (const void *p)
>> +{
>> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
>> +  return htab_hash_string (s->unique_name);
>> +}
>> +
>> +/* Hash equal function  */
>> +
>> +static int
>> +passr_eq (const void *p1, const void *p2)
>> +{
>> +  const struct pass_registry *const s1 = (const struct pass_registry
>> *const) p1;
>> +  const struct pass_registry *const s2 = (const struct pass_registry
>> *const) p2;
>> +
>> +  return !strcmp (s1->unique_name, s2->unique_name);
>> +}
>>
>> you can use htab_hash_string and strcmp directly, no need for these
>> wrappers.
>
> The hashtable entry is not string in this case. It is pass_registry,
> thus the wrapper.
>
>>
>> +void
>> +register_pass_name (struct opt_pass *pass, const char *name)
>>
>> doesn't seem to need exporting, so don't and make it static.
>
> Done.
>
>>
>> +  if (!pass_name_tab)
>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>
>> see above, the initial size should be larger - we have 223 passes at the
>> moment, so use 256.
>
> Done.
>
>>
>> +  else
>> +    return; /* Ignore plugin passes.  */
>>
>> ?  You mean they might clash?
>
> Yes, name clash.
>
>>
>> +struct opt_pass *
>> +get_pass_by_name (const char *name)
>>
>> doesn't need exporting either.
>
> Done.
>
>>
>> +      if (is_enable)
>> +        error ("unrecognized option -fenable");
>> +      else
>> +        error ("unrecognized option -fdisable");
>>
>> I think that should be fatal_error - Joseph?
>>
>> +      if (is_enable)
>> +        error ("unknown pass %s specified in -fenable", phase_name);
>> +      else
>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>
>> likewise.
>>
>> +      if (!enabled_pass_uid_range_tab)
>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>
>> instead of using a hashtable here please use a VEC indexed by
>> the static_pass_number which shoud speed up
>
> Ok.  The reason I did not use it is because in most of the cases, the
> htab will be very small -- it is determined by the number of passes
> specified in the command line, while the VEC requires allocating const
> size array. Not an issue as long as by default the array is not
> allocated.
>
>>
>> +static bool
>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>> +                                       tree func, htab_t tab)
>> +{
>> +  struct uid_range **slot, *range, key;
>> +  int cgraph_uid;
>> +
>> +  if (!tab)
>> +    return false;
>> +
>> +  key.pass = pass;
>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>> +  if (!slot || !*slot)
>> +    return false;
>>
>> and simplify the code quite a bit.
>>
>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>
>> note that cgraph uids are recycled, so it might not be the best idea
>> to use them as discriminator (though I don't have a good idea how
>> to represent ranges without them).
>
> Yes. It is not a big problem as the blind search does not need to know
> the id->name mapping. Once the id s found, it can be easily discovered
> via dump.
>
>>
>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>> current_function_decl);
>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>> current_function_decl);
>> +
>>   current_pass = pass;
>>
>>   /* Check whether gate check should be avoided.
>>      User controls the value of the gate through the parameter
>> "gate_status". */
>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>> +  gate_status = !explicitly_disabled && (gate_status || explicitly_enabled);
>>
>> so explicitly disabling wins over explicit enabling ;)  I think this
>> implementation detail and the fact that you always query both
>> hints at that the interface should be like
>>
>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>
> Done.
>
>>
>> instead.
>>
>> Thus, please split out the function header dumping changes and rework
>> the rest of the patch as suggested.
>
> Split out. The new patch is attached.
>
> Ok after testing is done?
>
> Thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>> --
>>> Joseph S. Myers
>>> joseph@codesourcery.com
>>>
>>
>

[richard.guenther_gmail.com, 2011-05-27 09:58:51]

On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com> wrote:
> The latest version that only exports 2 functions from passes.c.

Ok with ...

@@ -637,4 +637,8 @@ extern bool first_pass_instance;
 /* Declare for plugins.  */
 extern void do_per_function_toporder (void (*) (void *), void *);

+extern void disable_pass (const char *);
+extern void enable_pass (const char *);
+struct function;
+

struct function forward decl removed.

+  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
+  explicitly_disabled = is_pass_explicitly_disabled (pass, func);

both functions inlined here and removed.

+#define MAX_PASS_ID 512

this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
before the accesses.

+-fenable-ipa-@var{pass} @gol
+-fenable-rtl-@var{pass} @gol
+-fenable-rtl-@var{pass}=@var{range-list} @gol
+-fenable-tree-@var{pass} @gol
+-fenable-tree-@var{pass}=@var{range-list} @gol

-fenable-@var{kind}-@var{pass}, etc.

+@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
+@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
+@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
+@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}

likewise.

Thanks,
Richard.

> David
>
> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com> wrote:
>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>> <joseph@codesourcery.com> wrote:
>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>
>>>>> Ping. The link to the message:
>>>>>
>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>
>>>> I don't consider this an option handling patch.  Patches adding whole new
>>>> features involving new options should be reviewed by maintainers for the
>>>> part of the compiler relevant to those features (since there isn't a pass
>>>> manager maintainer, I guess that means middle-end).
>>>
>>> Hmm, I suppose then you reviewed the option handling parts and they
>>> are ok?  Those globbing options always cause headache to me.
>>>
>>> +-fenable-ipa-@var{pass} @gol
>>> +-fenable-rtl-@var{pass} @gol
>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>> +-fenable-tree-@var{pass} @gol
>>>
>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>
>>
>> Missed. Will add.
>>
>>
>>> Does the pass name match 1:1 with the dump file name?  In which
>>> case
>>
>> Yes.
>>
>>>
>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>> pass is statically invoked in the compiler multiple times, the pass
>>> name should be appended with a sequential number starting from 1.
>>>
>>> isn't true as passes that are invoked only a single time lack the number
>>> suffix (yes, I'd really like that to be changed ...)
>>
>> Yes, pass with single static instance does not need number suffix.
>>
>>>
>>> Please break likes also in .texi files and stick to 80 columns.
>>
>> Done.
>>
>>>  Please
>>> document that these options are debugging options and regular
>>> options for enabling/disabling passes should be used.  I would suggest
>>> to group documentation differently and document -fenable-* and
>>> -fdisable-*, thus,
>>>
>>> + -fdisable-@var{kind}-@var{pass}
>>> + -fenable-@var{kind}-@var{pass}
>>>
>>> Even in .texi files please two spaces after a full-stop.
>>
>> Done
>>
>>>
>>> +extern void enable_disable_pass (const char *, bool);
>>>
>>> I'd rather have both enable_pass and disable_pass ;)
>>
>> Ok.
>>
>>>
>>> +struct function;
>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>
>>> that's odd and probably should be split out, the function should
>>> maybe reside in tree-pretty-print.c.
>>
>> Ok.
>>
>>>
>>> Index: tree-ssa-loop-ivopts.c
>>> ===================================================================
>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>
>>> well - doesn't belong here ;)
>>
>> Sorry -- many things in the same client -- not needed with your latest
>> change anyway.
>>
>>>
>>> +static hashval_t
>>> +passr_hash (const void *p)
>>> +{
>>> +  const struct pass_registry *const s = (const struct pass_registry *const)
p;
>>> +  return htab_hash_string (s->unique_name);
>>> +}
>>> +
>>> +/* Hash equal function  */
>>> +
>>> +static int
>>> +passr_eq (const void *p1, const void *p2)
>>> +{
>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>> *const) p1;
>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>> *const) p2;
>>> +
>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>> +}
>>>
>>> you can use htab_hash_string and strcmp directly, no need for these
>>> wrappers.
>>
>> The hashtable entry is not string in this case. It is pass_registry,
>> thus the wrapper.
>>
>>>
>>> +void
>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>
>>> doesn't seem to need exporting, so don't and make it static.
>>
>> Done.
>>
>>>
>>> +  if (!pass_name_tab)
>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>
>>> see above, the initial size should be larger - we have 223 passes at the
>>> moment, so use 256.
>>
>> Done.
>>
>>>
>>> +  else
>>> +    return; /* Ignore plugin passes.  */
>>>
>>> ?  You mean they might clash?
>>
>> Yes, name clash.
>>
>>>
>>> +struct opt_pass *
>>> +get_pass_by_name (const char *name)
>>>
>>> doesn't need exporting either.
>>
>> Done.
>>
>>>
>>> +      if (is_enable)
>>> +        error ("unrecognized option -fenable");
>>> +      else
>>> +        error ("unrecognized option -fdisable");
>>>
>>> I think that should be fatal_error - Joseph?
>>>
>>> +      if (is_enable)
>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>> +      else
>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>
>>> likewise.
>>>
>>> +      if (!enabled_pass_uid_range_tab)
>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>
>>> instead of using a hashtable here please use a VEC indexed by
>>> the static_pass_number which shoud speed up
>>
>> Ok.  The reason I did not use it is because in most of the cases, the
>> htab will be very small -- it is determined by the number of passes
>> specified in the command line, while the VEC requires allocating const
>> size array. Not an issue as long as by default the array is not
>> allocated.
>>
>>>
>>> +static bool
>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>> +                                       tree func, htab_t tab)
>>> +{
>>> +  struct uid_range **slot, *range, key;
>>> +  int cgraph_uid;
>>> +
>>> +  if (!tab)
>>> +    return false;
>>> +
>>> +  key.pass = pass;
>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>> +  if (!slot || !*slot)
>>> +    return false;
>>>
>>> and simplify the code quite a bit.
>>>
>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>
>>> note that cgraph uids are recycled, so it might not be the best idea
>>> to use them as discriminator (though I don't have a good idea how
>>> to represent ranges without them).
>>
>> Yes. It is not a big problem as the blind search does not need to know
>> the id->name mapping. Once the id s found, it can be easily discovered
>> via dump.
>>
>>>
>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>> current_function_decl);
>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>> current_function_decl);
>>> +
>>>   current_pass = pass;
>>>
>>>   /* Check whether gate check should be avoided.
>>>      User controls the value of the gate through the parameter
>>> "gate_status". */
>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>
>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>> implementation detail and the fact that you always query both
>>> hints at that the interface should be like
>>>
>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>
>> Done.
>>
>>>
>>> instead.
>>>
>>> Thus, please split out the function header dumping changes and rework
>>> the rest of the patch as suggested.
>>
>> Split out. The new patch is attached.
>>
>> Ok after testing is done?
>>
>> Thanks,
>>
>> David
>>
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> --
>>>> Joseph S. Myers
>>>> joseph@codesourcery.com
>>>>
>>>
>>
>

[davidxl, 2011-05-30 20:16:51]

The attached are two simple follow up patches

1) the first patch does some refactorization on function header
dumping (with more information printed)

2) the second patch cleans up some pass names. Part of the cleanup
results from a previous discussion with Honza -- a) rename
'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
'profile' into 'profile_estimate'. The rest of cleanups are needed to
make sure pass names are unique.

Ok for trunk?

Thanks,

David

On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>> The latest version that only exports 2 functions from passes.c.
>
> Ok with ...
>
> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>  /* Declare for plugins.  */
>  extern void do_per_function_toporder (void (*) (void *), void *);
>
> +extern void disable_pass (const char *);
> +extern void enable_pass (const char *);
> +struct function;
> +
>
> struct function forward decl removed.
>
> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>
> both functions inlined here and removed.
>
> +#define MAX_PASS_ID 512
>
> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
> before the accesses.
>
> +-fenable-ipa-@var{pass} @gol
> +-fenable-rtl-@var{pass} @gol
> +-fenable-rtl-@var{pass}=@var{range-list} @gol
> +-fenable-tree-@var{pass} @gol
> +-fenable-tree-@var{pass}=@var{range-list} @gol
>
> -fenable-@var{kind}-@var{pass}, etc.
>
> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>
> likewise.
>
> Thanks,
> Richard.
>
>> David
>>
>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>> <joseph@codesourcery.com> wrote:
>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>
>>>>>> Ping. The link to the message:
>>>>>>
>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>
>>>>> I don't consider this an option handling patch.  Patches adding whole new
>>>>> features involving new options should be reviewed by maintainers for the
>>>>> part of the compiler relevant to those features (since there isn't a pass
>>>>> manager maintainer, I guess that means middle-end).
>>>>
>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>> are ok?  Those globbing options always cause headache to me.
>>>>
>>>> +-fenable-ipa-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>> +-fenable-tree-@var{pass} @gol
>>>>
>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>
>>>
>>> Missed. Will add.
>>>
>>>
>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>> case
>>>
>>> Yes.
>>>
>>>>
>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>> pass is statically invoked in the compiler multiple times, the pass
>>>> name should be appended with a sequential number starting from 1.
>>>>
>>>> isn't true as passes that are invoked only a single time lack the number
>>>> suffix (yes, I'd really like that to be changed ...)
>>>
>>> Yes, pass with single static instance does not need number suffix.
>>>
>>>>
>>>> Please break likes also in .texi files and stick to 80 columns.
>>>
>>> Done.
>>>
>>>>  Please
>>>> document that these options are debugging options and regular
>>>> options for enabling/disabling passes should be used.  I would suggest
>>>> to group documentation differently and document -fenable-* and
>>>> -fdisable-*, thus,
>>>>
>>>> + -fdisable-@var{kind}-@var{pass}
>>>> + -fenable-@var{kind}-@var{pass}
>>>>
>>>> Even in .texi files please two spaces after a full-stop.
>>>
>>> Done
>>>
>>>>
>>>> +extern void enable_disable_pass (const char *, bool);
>>>>
>>>> I'd rather have both enable_pass and disable_pass ;)
>>>
>>> Ok.
>>>
>>>>
>>>> +struct function;
>>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>>
>>>> that's odd and probably should be split out, the function should
>>>> maybe reside in tree-pretty-print.c.
>>>
>>> Ok.
>>>
>>>>
>>>> Index: tree-ssa-loop-ivopts.c
>>>> ===================================================================
>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>
>>>> well - doesn't belong here ;)
>>>
>>> Sorry -- many things in the same client -- not needed with your latest
>>> change anyway.
>>>
>>>>
>>>> +static hashval_t
>>>> +passr_hash (const void *p)
>>>> +{
>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>> +  return htab_hash_string (s->unique_name);
>>>> +}
>>>> +
>>>> +/* Hash equal function  */
>>>> +
>>>> +static int
>>>> +passr_eq (const void *p1, const void *p2)
>>>> +{
>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>> *const) p1;
>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>> *const) p2;
>>>> +
>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>> +}
>>>>
>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>> wrappers.
>>>
>>> The hashtable entry is not string in this case. It is pass_registry,
>>> thus the wrapper.
>>>
>>>>
>>>> +void
>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>
>>>> doesn't seem to need exporting, so don't and make it static.
>>>
>>> Done.
>>>
>>>>
>>>> +  if (!pass_name_tab)
>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>
>>>> see above, the initial size should be larger - we have 223 passes at the
>>>> moment, so use 256.
>>>
>>> Done.
>>>
>>>>
>>>> +  else
>>>> +    return; /* Ignore plugin passes.  */
>>>>
>>>> ?  You mean they might clash?
>>>
>>> Yes, name clash.
>>>
>>>>
>>>> +struct opt_pass *
>>>> +get_pass_by_name (const char *name)
>>>>
>>>> doesn't need exporting either.
>>>
>>> Done.
>>>
>>>>
>>>> +      if (is_enable)
>>>> +        error ("unrecognized option -fenable");
>>>> +      else
>>>> +        error ("unrecognized option -fdisable");
>>>>
>>>> I think that should be fatal_error - Joseph?
>>>>
>>>> +      if (is_enable)
>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>> +      else
>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>
>>>> likewise.
>>>>
>>>> +      if (!enabled_pass_uid_range_tab)
>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>>
>>>> instead of using a hashtable here please use a VEC indexed by
>>>> the static_pass_number which shoud speed up
>>>
>>> Ok.  The reason I did not use it is because in most of the cases, the
>>> htab will be very small -- it is determined by the number of passes
>>> specified in the command line, while the VEC requires allocating const
>>> size array. Not an issue as long as by default the array is not
>>> allocated.
>>>
>>>>
>>>> +static bool
>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>> +                                       tree func, htab_t tab)
>>>> +{
>>>> +  struct uid_range **slot, *range, key;
>>>> +  int cgraph_uid;
>>>> +
>>>> +  if (!tab)
>>>> +    return false;
>>>> +
>>>> +  key.pass = pass;
>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>> +  if (!slot || !*slot)
>>>> +    return false;
>>>>
>>>> and simplify the code quite a bit.
>>>>
>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>
>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>> to use them as discriminator (though I don't have a good idea how
>>>> to represent ranges without them).
>>>
>>> Yes. It is not a big problem as the blind search does not need to know
>>> the id->name mapping. Once the id s found, it can be easily discovered
>>> via dump.
>>>
>>>>
>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>> current_function_decl);
>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>> current_function_decl);
>>>> +
>>>>   current_pass = pass;
>>>>
>>>>   /* Check whether gate check should be avoided.
>>>>      User controls the value of the gate through the parameter
>>>> "gate_status". */
>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>
>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>> implementation detail and the fact that you always query both
>>>> hints at that the interface should be like
>>>>
>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>
>>> Done.
>>>
>>>>
>>>> instead.
>>>>
>>>> Thus, please split out the function header dumping changes and rework
>>>> the rest of the patch as suggested.
>>>
>>> Split out. The new patch is attached.
>>>
>>> Ok after testing is done?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>> --
>>>>> Joseph S. Myers
>>>>> joseph@codesourcery.com
>>>>>
>>>>
>>>
>>
>

[davidxl, 2011-05-30 21:44:42]

This is the complete patch for pass name fixes (with test case changes).

David


On Mon, May 30, 2011 at 1:16 PM, Xinliang David Li <davidxl@google.com> wrote:
> The attached are two simple follow up patches
>
> 1) the first patch does some refactorization on function header
> dumping (with more information printed)
>
> 2) the second patch cleans up some pass names. Part of the cleanup
> results from a previous discussion with Honza -- a) rename
> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
> make sure pass names are unique.
>
> Ok for trunk?
>
> Thanks,
>
> David
>
> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>> The latest version that only exports 2 functions from passes.c.
>>
>> Ok with ...
>>
>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>  /* Declare for plugins.  */
>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>
>> +extern void disable_pass (const char *);
>> +extern void enable_pass (const char *);
>> +struct function;
>> +
>>
>> struct function forward decl removed.
>>
>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>
>> both functions inlined here and removed.
>>
>> +#define MAX_PASS_ID 512
>>
>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>> before the accesses.
>>
>> +-fenable-ipa-@var{pass} @gol
>> +-fenable-rtl-@var{pass} @gol
>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>> +-fenable-tree-@var{pass} @gol
>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>
>> -fenable-@var{kind}-@var{pass}, etc.
>>
>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>
>> likewise.
>>
>> Thanks,
>> Richard.
>>
>>> David
>>>
>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>> <richard.guenther@gmail.com> wrote:
>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>> <joseph@codesourcery.com> wrote:
>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>
>>>>>>> Ping. The link to the message:
>>>>>>>
>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>
>>>>>> I don't consider this an option handling patch.  Patches adding whole new
>>>>>> features involving new options should be reviewed by maintainers for the
>>>>>> part of the compiler relevant to those features (since there isn't a pass
>>>>>> manager maintainer, I guess that means middle-end).
>>>>>
>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>
>>>>> +-fenable-ipa-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>> +-fenable-tree-@var{pass} @gol
>>>>>
>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>
>>>>
>>>> Missed. Will add.
>>>>
>>>>
>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>> case
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>> name should be appended with a sequential number starting from 1.
>>>>>
>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>
>>>> Yes, pass with single static instance does not need number suffix.
>>>>
>>>>>
>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>
>>>> Done.
>>>>
>>>>>  Please
>>>>> document that these options are debugging options and regular
>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>> to group documentation differently and document -fenable-* and
>>>>> -fdisable-*, thus,
>>>>>
>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>
>>>>> Even in .texi files please two spaces after a full-stop.
>>>>
>>>> Done
>>>>
>>>>>
>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>
>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> +struct function;
>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>>>
>>>>> that's odd and probably should be split out, the function should
>>>>> maybe reside in tree-pretty-print.c.
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> Index: tree-ssa-loop-ivopts.c
>>>>> ===================================================================
>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>
>>>>> well - doesn't belong here ;)
>>>>
>>>> Sorry -- many things in the same client -- not needed with your latest
>>>> change anyway.
>>>>
>>>>>
>>>>> +static hashval_t
>>>>> +passr_hash (const void *p)
>>>>> +{
>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>> +  return htab_hash_string (s->unique_name);
>>>>> +}
>>>>> +
>>>>> +/* Hash equal function  */
>>>>> +
>>>>> +static int
>>>>> +passr_eq (const void *p1, const void *p2)
>>>>> +{
>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>> *const) p1;
>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>> *const) p2;
>>>>> +
>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>> +}
>>>>>
>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>> wrappers.
>>>>
>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>> thus the wrapper.
>>>>
>>>>>
>>>>> +void
>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>
>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +  if (!pass_name_tab)
>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>
>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>> moment, so use 256.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +  else
>>>>> +    return; /* Ignore plugin passes.  */
>>>>>
>>>>> ?  You mean they might clash?
>>>>
>>>> Yes, name clash.
>>>>
>>>>>
>>>>> +struct opt_pass *
>>>>> +get_pass_by_name (const char *name)
>>>>>
>>>>> doesn't need exporting either.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +      if (is_enable)
>>>>> +        error ("unrecognized option -fenable");
>>>>> +      else
>>>>> +        error ("unrecognized option -fdisable");
>>>>>
>>>>> I think that should be fatal_error - Joseph?
>>>>>
>>>>> +      if (is_enable)
>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>> +      else
>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>
>>>>> likewise.
>>>>>
>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>>>
>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>> the static_pass_number which shoud speed up
>>>>
>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>> htab will be very small -- it is determined by the number of passes
>>>> specified in the command line, while the VEC requires allocating const
>>>> size array. Not an issue as long as by default the array is not
>>>> allocated.
>>>>
>>>>>
>>>>> +static bool
>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>> +                                       tree func, htab_t tab)
>>>>> +{
>>>>> +  struct uid_range **slot, *range, key;
>>>>> +  int cgraph_uid;
>>>>> +
>>>>> +  if (!tab)
>>>>> +    return false;
>>>>> +
>>>>> +  key.pass = pass;
>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>> +  if (!slot || !*slot)
>>>>> +    return false;
>>>>>
>>>>> and simplify the code quite a bit.
>>>>>
>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>
>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>> to use them as discriminator (though I don't have a good idea how
>>>>> to represent ranges without them).
>>>>
>>>> Yes. It is not a big problem as the blind search does not need to know
>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>> via dump.
>>>>
>>>>>
>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>> current_function_decl);
>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>> current_function_decl);
>>>>> +
>>>>>   current_pass = pass;
>>>>>
>>>>>   /* Check whether gate check should be avoided.
>>>>>      User controls the value of the gate through the parameter
>>>>> "gate_status". */
>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>
>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>> implementation detail and the fact that you always query both
>>>>> hints at that the interface should be like
>>>>>
>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> instead.
>>>>>
>>>>> Thus, please split out the function header dumping changes and rework
>>>>> the rest of the patch as suggested.
>>>>
>>>> Split out. The new patch is attached.
>>>>
>>>> Ok after testing is done?
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>> --
>>>>>> Joseph S. Myers
>>>>>> joseph@codesourcery.com
>>>>>>
>>>>>
>>>>
>>>
>>
>

[richard.guenther_gmail.com, 2011-05-31 09:05:08]

On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl@google.com> wrote:
> The attached are two simple follow up patches
>
> 1) the first patch does some refactorization on function header
> dumping (with more information printed)
>
> 2) the second patch cleans up some pass names. Part of the cleanup
> results from a previous discussion with Honza -- a) rename
> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
> make sure pass names are unique.
>
> Ok for trunk?

+
+void
+pass_dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)

This function needs documentation, the ChangeLog entry misses
the tree-pretty-print.h change.

+struct function;

instead of this please include coretypes.h from tree-pretty-print.h
and add the struct function forward declaration there if it isn't already
present.

You change the output of the header, so please make sure you
have bootstrapped and tested with _all_ languages included
(and also watch for bugreports for target specific bugs).

+  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, uid=%d)",
+           dname, aname, fun->funcdef_no, node->uid);

I see no point in dumping funcdef_no - it wasn't dumped before in
any place.  Instead I miss dumping of the DECL_UID and thus
a more specific 'uid', like 'cgraph-uid'.

+  aname = (IDENTIFIER_POINTER
+          (DECL_ASSEMBLER_NAME (fdecl)));

using DECL_ASSEMBLER_NAME is bad - it might trigger computation
of DECL_ASSEMBLER_NAME which certainly shouldn't be done
only for dumping purposes.  Instead do sth like

   if (DECL_ASSEMBLER_NAME_SET_P (fdecl))
     aname = DECL_ASSEMBLER_NAME (fdecl);
   else
     aname = '<unset-asm-name>';

and please also watch for cgraph_get_node returning NULL.

Also please call the function dump_function_header instead of
pass_dump_function_header.

Please re-post with appropriate changes.

Thanks,
Richard.

> Thanks,
>
> David
>
> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>> The latest version that only exports 2 functions from passes.c.
>>
>> Ok with ...
>>
>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>  /* Declare for plugins.  */
>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>
>> +extern void disable_pass (const char *);
>> +extern void enable_pass (const char *);
>> +struct function;
>> +
>>
>> struct function forward decl removed.
>>
>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>
>> both functions inlined here and removed.
>>
>> +#define MAX_PASS_ID 512
>>
>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>> before the accesses.
>>
>> +-fenable-ipa-@var{pass} @gol
>> +-fenable-rtl-@var{pass} @gol
>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>> +-fenable-tree-@var{pass} @gol
>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>
>> -fenable-@var{kind}-@var{pass}, etc.
>>
>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>
>> likewise.
>>
>> Thanks,
>> Richard.
>>
>>> David
>>>
>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>> <richard.guenther@gmail.com> wrote:
>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>> <joseph@codesourcery.com> wrote:
>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>
>>>>>>> Ping. The link to the message:
>>>>>>>
>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>
>>>>>> I don't consider this an option handling patch.  Patches adding whole new
>>>>>> features involving new options should be reviewed by maintainers for the
>>>>>> part of the compiler relevant to those features (since there isn't a pass
>>>>>> manager maintainer, I guess that means middle-end).
>>>>>
>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>
>>>>> +-fenable-ipa-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>> +-fenable-tree-@var{pass} @gol
>>>>>
>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>
>>>>
>>>> Missed. Will add.
>>>>
>>>>
>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>> case
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>> name should be appended with a sequential number starting from 1.
>>>>>
>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>
>>>> Yes, pass with single static instance does not need number suffix.
>>>>
>>>>>
>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>
>>>> Done.
>>>>
>>>>>  Please
>>>>> document that these options are debugging options and regular
>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>> to group documentation differently and document -fenable-* and
>>>>> -fdisable-*, thus,
>>>>>
>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>
>>>>> Even in .texi files please two spaces after a full-stop.
>>>>
>>>> Done
>>>>
>>>>>
>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>
>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> +struct function;
>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>>>
>>>>> that's odd and probably should be split out, the function should
>>>>> maybe reside in tree-pretty-print.c.
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> Index: tree-ssa-loop-ivopts.c
>>>>> ===================================================================
>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>
>>>>> well - doesn't belong here ;)
>>>>
>>>> Sorry -- many things in the same client -- not needed with your latest
>>>> change anyway.
>>>>
>>>>>
>>>>> +static hashval_t
>>>>> +passr_hash (const void *p)
>>>>> +{
>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>> +  return htab_hash_string (s->unique_name);
>>>>> +}
>>>>> +
>>>>> +/* Hash equal function  */
>>>>> +
>>>>> +static int
>>>>> +passr_eq (const void *p1, const void *p2)
>>>>> +{
>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>> *const) p1;
>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>> *const) p2;
>>>>> +
>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>> +}
>>>>>
>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>> wrappers.
>>>>
>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>> thus the wrapper.
>>>>
>>>>>
>>>>> +void
>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>
>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +  if (!pass_name_tab)
>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>
>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>> moment, so use 256.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +  else
>>>>> +    return; /* Ignore plugin passes.  */
>>>>>
>>>>> ?  You mean they might clash?
>>>>
>>>> Yes, name clash.
>>>>
>>>>>
>>>>> +struct opt_pass *
>>>>> +get_pass_by_name (const char *name)
>>>>>
>>>>> doesn't need exporting either.
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> +      if (is_enable)
>>>>> +        error ("unrecognized option -fenable");
>>>>> +      else
>>>>> +        error ("unrecognized option -fdisable");
>>>>>
>>>>> I think that should be fatal_error - Joseph?
>>>>>
>>>>> +      if (is_enable)
>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>> +      else
>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>
>>>>> likewise.
>>>>>
>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>>>
>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>> the static_pass_number which shoud speed up
>>>>
>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>> htab will be very small -- it is determined by the number of passes
>>>> specified in the command line, while the VEC requires allocating const
>>>> size array. Not an issue as long as by default the array is not
>>>> allocated.
>>>>
>>>>>
>>>>> +static bool
>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>> +                                       tree func, htab_t tab)
>>>>> +{
>>>>> +  struct uid_range **slot, *range, key;
>>>>> +  int cgraph_uid;
>>>>> +
>>>>> +  if (!tab)
>>>>> +    return false;
>>>>> +
>>>>> +  key.pass = pass;
>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>> +  if (!slot || !*slot)
>>>>> +    return false;
>>>>>
>>>>> and simplify the code quite a bit.
>>>>>
>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>
>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>> to use them as discriminator (though I don't have a good idea how
>>>>> to represent ranges without them).
>>>>
>>>> Yes. It is not a big problem as the blind search does not need to know
>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>> via dump.
>>>>
>>>>>
>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>> current_function_decl);
>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>> current_function_decl);
>>>>> +
>>>>>   current_pass = pass;
>>>>>
>>>>>   /* Check whether gate check should be avoided.
>>>>>      User controls the value of the gate through the parameter
>>>>> "gate_status". */
>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>
>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>> implementation detail and the fact that you always query both
>>>>> hints at that the interface should be like
>>>>>
>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>
>>>> Done.
>>>>
>>>>>
>>>>> instead.
>>>>>
>>>>> Thus, please split out the function header dumping changes and rework
>>>>> the rest of the patch as suggested.
>>>>
>>>> Split out. The new patch is attached.
>>>>
>>>> Ok after testing is done?
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>> --
>>>>>> Joseph S. Myers
>>>>>> joseph@codesourcery.com
>>>>>>
>>>>>
>>>>
>>>
>>
>

[richard.guenther_gmail.com, 2011-05-31 09:07:36]

On Mon, May 30, 2011 at 11:44 PM, Xinliang David Li <davidxl@google.com> wrote:
> This is the complete patch for pass name fixes (with test case changes).

This is ok if Honza thinks the profile pass names make more sense this
way.

Thanks,
Richard.

> David
>
>
> On Mon, May 30, 2011 at 1:16 PM, Xinliang David Li <davidxl@google.com> wrote:
>> The attached are two simple follow up patches
>>
>> 1) the first patch does some refactorization on function header
>> dumping (with more information printed)
>>
>> 2) the second patch cleans up some pass names. Part of the cleanup
>> results from a previous discussion with Honza -- a) rename
>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>> make sure pass names are unique.
>>
>> Ok for trunk?
>>
>> Thanks,
>>
>> David
>>
>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>> The latest version that only exports 2 functions from passes.c.
>>>
>>> Ok with ...
>>>
>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>  /* Declare for plugins.  */
>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>
>>> +extern void disable_pass (const char *);
>>> +extern void enable_pass (const char *);
>>> +struct function;
>>> +
>>>
>>> struct function forward decl removed.
>>>
>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>
>>> both functions inlined here and removed.
>>>
>>> +#define MAX_PASS_ID 512
>>>
>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>> before the accesses.
>>>
>>> +-fenable-ipa-@var{pass} @gol
>>> +-fenable-rtl-@var{pass} @gol
>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>> +-fenable-tree-@var{pass} @gol
>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>
>>> -fenable-@var{kind}-@var{pass}, etc.
>>>
>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>
>>> likewise.
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> David
>>>>
>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>> <richard.guenther@gmail.com> wrote:
>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>
>>>>>>>> Ping. The link to the message:
>>>>>>>>
>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>
>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>> features involving new options should be reviewed by maintainers for the
>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>
>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>
>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>
>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>
>>>>>
>>>>> Missed. Will add.
>>>>>
>>>>>
>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>> case
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>
>>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>
>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>
>>>>>>
>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>
>>>>> Done.
>>>>>
>>>>>>  Please
>>>>>> document that these options are debugging options and regular
>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>> to group documentation differently and document -fenable-* and
>>>>>> -fdisable-*, thus,
>>>>>>
>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>
>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>
>>>>> Done
>>>>>
>>>>>>
>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>
>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>> +struct function;
>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>>>>
>>>>>> that's odd and probably should be split out, the function should
>>>>>> maybe reside in tree-pretty-print.c.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>> ===================================================================
>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>
>>>>>> well - doesn't belong here ;)
>>>>>
>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>> change anyway.
>>>>>
>>>>>>
>>>>>> +static hashval_t
>>>>>> +passr_hash (const void *p)
>>>>>> +{
>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>> +}
>>>>>> +
>>>>>> +/* Hash equal function  */
>>>>>> +
>>>>>> +static int
>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>> +{
>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>> *const) p1;
>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>> *const) p2;
>>>>>> +
>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>> +}
>>>>>>
>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>> wrappers.
>>>>>
>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>> thus the wrapper.
>>>>>
>>>>>>
>>>>>> +void
>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>
>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +  if (!pass_name_tab)
>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>
>>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>>> moment, so use 256.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +  else
>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>
>>>>>> ?  You mean they might clash?
>>>>>
>>>>> Yes, name clash.
>>>>>
>>>>>>
>>>>>> +struct opt_pass *
>>>>>> +get_pass_by_name (const char *name)
>>>>>>
>>>>>> doesn't need exporting either.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +      if (is_enable)
>>>>>> +        error ("unrecognized option -fenable");
>>>>>> +      else
>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>
>>>>>> I think that should be fatal_error - Joseph?
>>>>>>
>>>>>> +      if (is_enable)
>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>> +      else
>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>
>>>>>> likewise.
>>>>>>
>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>>>>
>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>> the static_pass_number which shoud speed up
>>>>>
>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>> htab will be very small -- it is determined by the number of passes
>>>>> specified in the command line, while the VEC requires allocating const
>>>>> size array. Not an issue as long as by default the array is not
>>>>> allocated.
>>>>>
>>>>>>
>>>>>> +static bool
>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>> +                                       tree func, htab_t tab)
>>>>>> +{
>>>>>> +  struct uid_range **slot, *range, key;
>>>>>> +  int cgraph_uid;
>>>>>> +
>>>>>> +  if (!tab)
>>>>>> +    return false;
>>>>>> +
>>>>>> +  key.pass = pass;
>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>> +  if (!slot || !*slot)
>>>>>> +    return false;
>>>>>>
>>>>>> and simplify the code quite a bit.
>>>>>>
>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>
>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>> to represent ranges without them).
>>>>>
>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>> via dump.
>>>>>
>>>>>>
>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>> current_function_decl);
>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>> current_function_decl);
>>>>>> +
>>>>>>   current_pass = pass;
>>>>>>
>>>>>>   /* Check whether gate check should be avoided.
>>>>>>      User controls the value of the gate through the parameter
>>>>>> "gate_status". */
>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>
>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>> implementation detail and the fact that you always query both
>>>>>> hints at that the interface should be like
>>>>>>
>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> instead.
>>>>>>
>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>> the rest of the patch as suggested.
>>>>>
>>>>> Split out. The new patch is attached.
>>>>>
>>>>> Ok after testing is done?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>>>
>>>>>>> --
>>>>>>> Joseph S. Myers
>>>>>>> joseph@codesourcery.com
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[davidxl, 2011-05-31 16:06:54]

On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl@google.com>
wrote:
>> The attached are two simple follow up patches
>>
>> 1) the first patch does some refactorization on function header
>> dumping (with more information printed)
>>
>> 2) the second patch cleans up some pass names. Part of the cleanup
>> results from a previous discussion with Honza -- a) rename
>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>> make sure pass names are unique.
>>
>> Ok for trunk?
>
> +
> +void
> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)
>
> This function needs documentation, the ChangeLog entry misses
> the tree-pretty-print.h change.
>
> +struct function;
>
> instead of this please include coretypes.h from tree-pretty-print.h
> and add the struct function forward declaration there if it isn't already
> present.
>
> You change the output of the header, so please make sure you
> have bootstrapped and tested with _all_ languages included
> (and also watch for bugreports for target specific bugs).
>

Ok.

> +  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, uid=%d)",
> +           dname, aname, fun->funcdef_no, node->uid);
>
> I see no point in dumping funcdef_no - it wasn't dumped before in
> any place.  Instead I miss dumping of the DECL_UID and thus
> a more specific 'uid', like 'cgraph-uid'.

Ok will add decl_uid. Funcdef_no is very useful for debugging FDO
coverage mismatch related problems as it is the id used in profile
hashing.

>
> +  aname = (IDENTIFIER_POINTER
> +          (DECL_ASSEMBLER_NAME (fdecl)));
>
> using DECL_ASSEMBLER_NAME is bad - it might trigger computation
> of DECL_ASSEMBLER_NAME which certainly shouldn't be done
> only for dumping purposes.  Instead do sth like
>
>   if (DECL_ASSEMBLER_NAME_SET_P (fdecl))
>     aname = DECL_ASSEMBLER_NAME (fdecl);
>   else
>     aname = '<unset-asm-name>';

Ok.

>
> and please also watch for cgraph_get_node returning NULL.
>
> Also please call the function dump_function_header instead of
> pass_dump_function_header.
>

Ok.

Thanks,

David
> Please re-post with appropriate changes.
>
> Thanks,
> Richard.
>
>> Thanks,
>>
>> David
>>
>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>> The latest version that only exports 2 functions from passes.c.
>>>
>>> Ok with ...
>>>
>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>  /* Declare for plugins.  */
>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>
>>> +extern void disable_pass (const char *);
>>> +extern void enable_pass (const char *);
>>> +struct function;
>>> +
>>>
>>> struct function forward decl removed.
>>>
>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>
>>> both functions inlined here and removed.
>>>
>>> +#define MAX_PASS_ID 512
>>>
>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>> before the accesses.
>>>
>>> +-fenable-ipa-@var{pass} @gol
>>> +-fenable-rtl-@var{pass} @gol
>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>> +-fenable-tree-@var{pass} @gol
>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>
>>> -fenable-@var{kind}-@var{pass}, etc.
>>>
>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>
>>> likewise.
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> David
>>>>
>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>> <richard.guenther@gmail.com> wrote:
>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>
>>>>>>>> Ping. The link to the message:
>>>>>>>>
>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>
>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>> features involving new options should be reviewed by maintainers for the
>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>
>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>
>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>
>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>
>>>>>
>>>>> Missed. Will add.
>>>>>
>>>>>
>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>> case
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>
>>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>
>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>
>>>>>>
>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>
>>>>> Done.
>>>>>
>>>>>>  Please
>>>>>> document that these options are debugging options and regular
>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>> to group documentation differently and document -fenable-* and
>>>>>> -fdisable-*, thus,
>>>>>>
>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>
>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>
>>>>> Done
>>>>>
>>>>>>
>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>
>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>> +struct function;
>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>>>>>
>>>>>> that's odd and probably should be split out, the function should
>>>>>> maybe reside in tree-pretty-print.c.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>> ===================================================================
>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>
>>>>>> well - doesn't belong here ;)
>>>>>
>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>> change anyway.
>>>>>
>>>>>>
>>>>>> +static hashval_t
>>>>>> +passr_hash (const void *p)
>>>>>> +{
>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>> +}
>>>>>> +
>>>>>> +/* Hash equal function  */
>>>>>> +
>>>>>> +static int
>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>> +{
>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>> *const) p1;
>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>> *const) p2;
>>>>>> +
>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>> +}
>>>>>>
>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>> wrappers.
>>>>>
>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>> thus the wrapper.
>>>>>
>>>>>>
>>>>>> +void
>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>
>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +  if (!pass_name_tab)
>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>
>>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>>> moment, so use 256.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +  else
>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>
>>>>>> ?  You mean they might clash?
>>>>>
>>>>> Yes, name clash.
>>>>>
>>>>>>
>>>>>> +struct opt_pass *
>>>>>> +get_pass_by_name (const char *name)
>>>>>>
>>>>>> doesn't need exporting either.
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> +      if (is_enable)
>>>>>> +        error ("unrecognized option -fenable");
>>>>>> +      else
>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>
>>>>>> I think that should be fatal_error - Joseph?
>>>>>>
>>>>>> +      if (is_enable)
>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>> +      else
>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>
>>>>>> likewise.
>>>>>>
>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq,
NULL);
>>>>>>
>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>> the static_pass_number which shoud speed up
>>>>>
>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>> htab will be very small -- it is determined by the number of passes
>>>>> specified in the command line, while the VEC requires allocating const
>>>>> size array. Not an issue as long as by default the array is not
>>>>> allocated.
>>>>>
>>>>>>
>>>>>> +static bool
>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>> +                                       tree func, htab_t tab)
>>>>>> +{
>>>>>> +  struct uid_range **slot, *range, key;
>>>>>> +  int cgraph_uid;
>>>>>> +
>>>>>> +  if (!tab)
>>>>>> +    return false;
>>>>>> +
>>>>>> +  key.pass = pass;
>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>> +  if (!slot || !*slot)
>>>>>> +    return false;
>>>>>>
>>>>>> and simplify the code quite a bit.
>>>>>>
>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>
>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>> to represent ranges without them).
>>>>>
>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>> via dump.
>>>>>
>>>>>>
>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>> current_function_decl);
>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>> current_function_decl);
>>>>>> +
>>>>>>   current_pass = pass;
>>>>>>
>>>>>>   /* Check whether gate check should be avoided.
>>>>>>      User controls the value of the gate through the parameter
>>>>>> "gate_status". */
>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>
>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>> implementation detail and the fact that you always query both
>>>>>> hints at that the interface should be like
>>>>>>
>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>
>>>>> Done.
>>>>>
>>>>>>
>>>>>> instead.
>>>>>>
>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>> the rest of the patch as suggested.
>>>>>
>>>>> Split out. The new patch is attached.
>>>>>
>>>>> Ok after testing is done?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>>>
>>>>>>> --
>>>>>>> Joseph S. Myers
>>>>>>> joseph@codesourcery.com
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[davidxl, 2011-06-01 00:01:21]

The new patch is attached. The test (c,c++,fortran, java, ada) is on going.

Thanks,

David

On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>> The attached are two simple follow up patches
>>>
>>> 1) the first patch does some refactorization on function header
>>> dumping (with more information printed)
>>>
>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>> results from a previous discussion with Honza -- a) rename
>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>> make sure pass names are unique.
>>>
>>> Ok for trunk?
>>
>> +
>> +void
>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function
*fun)
>>
>> This function needs documentation, the ChangeLog entry misses
>> the tree-pretty-print.h change.
>>
>> +struct function;
>>
>> instead of this please include coretypes.h from tree-pretty-print.h
>> and add the struct function forward declaration there if it isn't already
>> present.
>>
>> You change the output of the header, so please make sure you
>> have bootstrapped and tested with _all_ languages included
>> (and also watch for bugreports for target specific bugs).
>>
>
> Ok.
>
>> +  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, uid=%d)",
>> +           dname, aname, fun->funcdef_no, node->uid);
>>
>> I see no point in dumping funcdef_no - it wasn't dumped before in
>> any place.  Instead I miss dumping of the DECL_UID and thus
>> a more specific 'uid', like 'cgraph-uid'.
>
> Ok will add decl_uid. Funcdef_no is very useful for debugging FDO
> coverage mismatch related problems as it is the id used in profile
> hashing.
>
>>
>> +  aname = (IDENTIFIER_POINTER
>> +          (DECL_ASSEMBLER_NAME (fdecl)));
>>
>> using DECL_ASSEMBLER_NAME is bad - it might trigger computation
>> of DECL_ASSEMBLER_NAME which certainly shouldn't be done
>> only for dumping purposes.  Instead do sth like
>>
>>   if (DECL_ASSEMBLER_NAME_SET_P (fdecl))
>>     aname = DECL_ASSEMBLER_NAME (fdecl);
>>   else
>>     aname = '<unset-asm-name>';
>
> Ok.
>
>>
>> and please also watch for cgraph_get_node returning NULL.
>>
>> Also please call the function dump_function_header instead of
>> pass_dump_function_header.
>>
>
> Ok.
>
> Thanks,
>
> David
>> Please re-post with appropriate changes.
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>>
>>> David
>>>
>>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>> The latest version that only exports 2 functions from passes.c.
>>>>
>>>> Ok with ...
>>>>
>>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>>  /* Declare for plugins.  */
>>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>>
>>>> +extern void disable_pass (const char *);
>>>> +extern void enable_pass (const char *);
>>>> +struct function;
>>>> +
>>>>
>>>> struct function forward decl removed.
>>>>
>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>>
>>>> both functions inlined here and removed.
>>>>
>>>> +#define MAX_PASS_ID 512
>>>>
>>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>>> before the accesses.
>>>>
>>>> +-fenable-ipa-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>> +-fenable-tree-@var{pass} @gol
>>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>>
>>>> -fenable-@var{kind}-@var{pass}, etc.
>>>>
>>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>
>>>> likewise.
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>> David
>>>>>
>>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>>
>>>>>>>>> Ping. The link to the message:
>>>>>>>>>
>>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>>
>>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>>> features involving new options should be reviewed by maintainers for
the
>>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>>
>>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>>
>>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>>
>>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>>
>>>>>>
>>>>>> Missed. Will add.
>>>>>>
>>>>>>
>>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>>> case
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>
>>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>>
>>>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>>
>>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>>
>>>>>>>
>>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>  Please
>>>>>>> document that these options are debugging options and regular
>>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>>> to group documentation differently and document -fenable-* and
>>>>>>> -fdisable-*, thus,
>>>>>>>
>>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>>
>>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>>
>>>>>> Done
>>>>>>
>>>>>>>
>>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>>
>>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>
>>>>>>> +struct function;
>>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function
*);
>>>>>>>
>>>>>>> that's odd and probably should be split out, the function should
>>>>>>> maybe reside in tree-pretty-print.c.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>
>>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>>> ===================================================================
>>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>>
>>>>>>> well - doesn't belong here ;)
>>>>>>
>>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>>> change anyway.
>>>>>>
>>>>>>>
>>>>>>> +static hashval_t
>>>>>>> +passr_hash (const void *p)
>>>>>>> +{
>>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>>> +}
>>>>>>> +
>>>>>>> +/* Hash equal function  */
>>>>>>> +
>>>>>>> +static int
>>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>>> +{
>>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>>> *const) p1;
>>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>>> *const) p2;
>>>>>>> +
>>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>>> +}
>>>>>>>
>>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>>> wrappers.
>>>>>>
>>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>>> thus the wrapper.
>>>>>>
>>>>>>>
>>>>>>> +void
>>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>>
>>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +  if (!pass_name_tab)
>>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>>
>>>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>>>> moment, so use 256.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +  else
>>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>>
>>>>>>> ?  You mean they might clash?
>>>>>>
>>>>>> Yes, name clash.
>>>>>>
>>>>>>>
>>>>>>> +struct opt_pass *
>>>>>>> +get_pass_by_name (const char *name)
>>>>>>>
>>>>>>> doesn't need exporting either.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +      if (is_enable)
>>>>>>> +        error ("unrecognized option -fenable");
>>>>>>> +      else
>>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>>
>>>>>>> I think that should be fatal_error - Joseph?
>>>>>>>
>>>>>>> +      if (is_enable)
>>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>>> +      else
>>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>>
>>>>>>> likewise.
>>>>>>>
>>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash,
pass_eq, NULL);
>>>>>>>
>>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>>> the static_pass_number which shoud speed up
>>>>>>
>>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>>> htab will be very small -- it is determined by the number of passes
>>>>>> specified in the command line, while the VEC requires allocating const
>>>>>> size array. Not an issue as long as by default the array is not
>>>>>> allocated.
>>>>>>
>>>>>>>
>>>>>>> +static bool
>>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>>> +                                       tree func, htab_t tab)
>>>>>>> +{
>>>>>>> +  struct uid_range **slot, *range, key;
>>>>>>> +  int cgraph_uid;
>>>>>>> +
>>>>>>> +  if (!tab)
>>>>>>> +    return false;
>>>>>>> +
>>>>>>> +  key.pass = pass;
>>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>>> +  if (!slot || !*slot)
>>>>>>> +    return false;
>>>>>>>
>>>>>>> and simplify the code quite a bit.
>>>>>>>
>>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>>
>>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>>> to represent ranges without them).
>>>>>>
>>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>>> via dump.
>>>>>>
>>>>>>>
>>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>>> current_function_decl);
>>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>>> current_function_decl);
>>>>>>> +
>>>>>>>   current_pass = pass;
>>>>>>>
>>>>>>>   /* Check whether gate check should be avoided.
>>>>>>>      User controls the value of the gate through the parameter
>>>>>>> "gate_status". */
>>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>>
>>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>>> implementation detail and the fact that you always query both
>>>>>>> hints at that the interface should be like
>>>>>>>
>>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> instead.
>>>>>>>
>>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>>> the rest of the patch as suggested.
>>>>>>
>>>>>> Split out. The new patch is attached.
>>>>>>
>>>>>> Ok after testing is done?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Richard.
>>>>>>>
>>>>>>>> --
>>>>>>>> Joseph S. Myers
>>>>>>>> joseph@codesourcery.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[davidxl, 2011-06-01 00:02:16]

Honza, are you ok with the pass name change?

David

On Tue, May 31, 2011 at 2:07 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, May 30, 2011 at 11:44 PM, Xinliang David Li <davidxl@google.com>
wrote:
>> This is the complete patch for pass name fixes (with test case changes).
>
> This is ok if Honza thinks the profile pass names make more sense this
> way.
>
> Thanks,
> Richard.
>
>> David
>>
>>
>> On Mon, May 30, 2011 at 1:16 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>> The attached are two simple follow up patches
>>>
>>> 1) the first patch does some refactorization on function header
>>> dumping (with more information printed)
>>>
>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>> results from a previous discussion with Honza -- a) rename
>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>> make sure pass names are unique.
>>>
>>> Ok for trunk?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>> The latest version that only exports 2 functions from passes.c.
>>>>
>>>> Ok with ...
>>>>
>>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>>  /* Declare for plugins.  */
>>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>>
>>>> +extern void disable_pass (const char *);
>>>> +extern void enable_pass (const char *);
>>>> +struct function;
>>>> +
>>>>
>>>> struct function forward decl removed.
>>>>
>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>>
>>>> both functions inlined here and removed.
>>>>
>>>> +#define MAX_PASS_ID 512
>>>>
>>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>>> before the accesses.
>>>>
>>>> +-fenable-ipa-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass} @gol
>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>> +-fenable-tree-@var{pass} @gol
>>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>>
>>>> -fenable-@var{kind}-@var{pass}, etc.
>>>>
>>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>
>>>> likewise.
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>> David
>>>>>
>>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>>
>>>>>>>>> Ping. The link to the message:
>>>>>>>>>
>>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>>
>>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>>> features involving new options should be reviewed by maintainers for
the
>>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>>
>>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>>
>>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>>
>>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>>
>>>>>>
>>>>>> Missed. Will add.
>>>>>>
>>>>>>
>>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>>> case
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>
>>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>>
>>>>>>> isn't true as passes that are invoked only a single time lack the number
>>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>>
>>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>>
>>>>>>>
>>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>  Please
>>>>>>> document that these options are debugging options and regular
>>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>>> to group documentation differently and document -fenable-* and
>>>>>>> -fdisable-*, thus,
>>>>>>>
>>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>>
>>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>>
>>>>>> Done
>>>>>>
>>>>>>>
>>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>>
>>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>
>>>>>>> +struct function;
>>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function
*);
>>>>>>>
>>>>>>> that's odd and probably should be split out, the function should
>>>>>>> maybe reside in tree-pretty-print.c.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>
>>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>>> ===================================================================
>>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>>
>>>>>>> well - doesn't belong here ;)
>>>>>>
>>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>>> change anyway.
>>>>>>
>>>>>>>
>>>>>>> +static hashval_t
>>>>>>> +passr_hash (const void *p)
>>>>>>> +{
>>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>>> +}
>>>>>>> +
>>>>>>> +/* Hash equal function  */
>>>>>>> +
>>>>>>> +static int
>>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>>> +{
>>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>>> *const) p1;
>>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>>> *const) p2;
>>>>>>> +
>>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>>> +}
>>>>>>>
>>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>>> wrappers.
>>>>>>
>>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>>> thus the wrapper.
>>>>>>
>>>>>>>
>>>>>>> +void
>>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>>
>>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +  if (!pass_name_tab)
>>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>>
>>>>>>> see above, the initial size should be larger - we have 223 passes at the
>>>>>>> moment, so use 256.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +  else
>>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>>
>>>>>>> ?  You mean they might clash?
>>>>>>
>>>>>> Yes, name clash.
>>>>>>
>>>>>>>
>>>>>>> +struct opt_pass *
>>>>>>> +get_pass_by_name (const char *name)
>>>>>>>
>>>>>>> doesn't need exporting either.
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> +      if (is_enable)
>>>>>>> +        error ("unrecognized option -fenable");
>>>>>>> +      else
>>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>>
>>>>>>> I think that should be fatal_error - Joseph?
>>>>>>>
>>>>>>> +      if (is_enable)
>>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>>> +      else
>>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>>
>>>>>>> likewise.
>>>>>>>
>>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash,
pass_eq, NULL);
>>>>>>>
>>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>>> the static_pass_number which shoud speed up
>>>>>>
>>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>>> htab will be very small -- it is determined by the number of passes
>>>>>> specified in the command line, while the VEC requires allocating const
>>>>>> size array. Not an issue as long as by default the array is not
>>>>>> allocated.
>>>>>>
>>>>>>>
>>>>>>> +static bool
>>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>>> +                                       tree func, htab_t tab)
>>>>>>> +{
>>>>>>> +  struct uid_range **slot, *range, key;
>>>>>>> +  int cgraph_uid;
>>>>>>> +
>>>>>>> +  if (!tab)
>>>>>>> +    return false;
>>>>>>> +
>>>>>>> +  key.pass = pass;
>>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>>> +  if (!slot || !*slot)
>>>>>>> +    return false;
>>>>>>>
>>>>>>> and simplify the code quite a bit.
>>>>>>>
>>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>>
>>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>>> to represent ranges without them).
>>>>>>
>>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>>> via dump.
>>>>>>
>>>>>>>
>>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>>> current_function_decl);
>>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>>> current_function_decl);
>>>>>>> +
>>>>>>>   current_pass = pass;
>>>>>>>
>>>>>>>   /* Check whether gate check should be avoided.
>>>>>>>      User controls the value of the gate through the parameter
>>>>>>> "gate_status". */
>>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>>
>>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>>> implementation detail and the fact that you always query both
>>>>>>> hints at that the interface should be like
>>>>>>>
>>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>>
>>>>>>> instead.
>>>>>>>
>>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>>> the rest of the patch as suggested.
>>>>>>
>>>>>> Split out. The new patch is attached.
>>>>>>
>>>>>> Ok after testing is done?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Richard.
>>>>>>>
>>>>>>>> --
>>>>>>>> Joseph S. Myers
>>>>>>>> joseph@codesourcery.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[davidxl, 2011-06-01 00:04:01]

Please discard the previous one. This is the right one:

David

On Tue, May 31, 2011 at 5:01 PM, Xinliang David Li <davidxl@google.com> wrote:
> The new patch is attached. The test (c,c++,fortran, java, ada) is on going.
>
> Thanks,
>
> David
>
> On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li <davidxl@google.com> wrote:
>> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>> The attached are two simple follow up patches
>>>>
>>>> 1) the first patch does some refactorization on function header
>>>> dumping (with more information printed)
>>>>
>>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>>> results from a previous discussion with Honza -- a) rename
>>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>>> make sure pass names are unique.
>>>>
>>>> Ok for trunk?
>>>
>>> +
>>> +void
>>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function
*fun)
>>>
>>> This function needs documentation, the ChangeLog entry misses
>>> the tree-pretty-print.h change.
>>>
>>> +struct function;
>>>
>>> instead of this please include coretypes.h from tree-pretty-print.h
>>> and add the struct function forward declaration there if it isn't already
>>> present.
>>>
>>> You change the output of the header, so please make sure you
>>> have bootstrapped and tested with _all_ languages included
>>> (and also watch for bugreports for target specific bugs).
>>>
>>
>> Ok.
>>
>>> +  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, uid=%d)",
>>> +           dname, aname, fun->funcdef_no, node->uid);
>>>
>>> I see no point in dumping funcdef_no - it wasn't dumped before in
>>> any place.  Instead I miss dumping of the DECL_UID and thus
>>> a more specific 'uid', like 'cgraph-uid'.
>>
>> Ok will add decl_uid. Funcdef_no is very useful for debugging FDO
>> coverage mismatch related problems as it is the id used in profile
>> hashing.
>>
>>>
>>> +  aname = (IDENTIFIER_POINTER
>>> +          (DECL_ASSEMBLER_NAME (fdecl)));
>>>
>>> using DECL_ASSEMBLER_NAME is bad - it might trigger computation
>>> of DECL_ASSEMBLER_NAME which certainly shouldn't be done
>>> only for dumping purposes.  Instead do sth like
>>>
>>>   if (DECL_ASSEMBLER_NAME_SET_P (fdecl))
>>>     aname = DECL_ASSEMBLER_NAME (fdecl);
>>>   else
>>>     aname = '<unset-asm-name>';
>>
>> Ok.
>>
>>>
>>> and please also watch for cgraph_get_node returning NULL.
>>>
>>> Also please call the function dump_function_header instead of
>>> pass_dump_function_header.
>>>
>>
>> Ok.
>>
>> Thanks,
>>
>> David
>>> Please re-post with appropriate changes.
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>>>> <richard.guenther@gmail.com> wrote:
>>>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>> The latest version that only exports 2 functions from passes.c.
>>>>>
>>>>> Ok with ...
>>>>>
>>>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>>>  /* Declare for plugins.  */
>>>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>>>
>>>>> +extern void disable_pass (const char *);
>>>>> +extern void enable_pass (const char *);
>>>>> +struct function;
>>>>> +
>>>>>
>>>>> struct function forward decl removed.
>>>>>
>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>>>
>>>>> both functions inlined here and removed.
>>>>>
>>>>> +#define MAX_PASS_ID 512
>>>>>
>>>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>>>> before the accesses.
>>>>>
>>>>> +-fenable-ipa-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass} @gol
>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>> +-fenable-tree-@var{pass} @gol
>>>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>>>
>>>>> -fenable-@var{kind}-@var{pass}, etc.
>>>>>
>>>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>>
>>>>> likewise.
>>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>> David
>>>>>>
>>>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>>>
>>>>>>>>>> Ping. The link to the message:
>>>>>>>>>>
>>>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>>>
>>>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>>>> features involving new options should be reviewed by maintainers for
the
>>>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>>>
>>>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>>>
>>>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>>>
>>>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>>>
>>>>>>>
>>>>>>> Missed. Will add.
>>>>>>>
>>>>>>>
>>>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>>>> case
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>>
>>>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>>>
>>>>>>>> isn't true as passes that are invoked only a single time lack the
number
>>>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>>>
>>>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>>>
>>>>>>>>
>>>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>>  Please
>>>>>>>> document that these options are debugging options and regular
>>>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>>>> to group documentation differently and document -fenable-* and
>>>>>>>> -fdisable-*, thus,
>>>>>>>>
>>>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>>>
>>>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>>>
>>>>>>> Done
>>>>>>>
>>>>>>>>
>>>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>>>
>>>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>>>
>>>>>>> Ok.
>>>>>>>
>>>>>>>>
>>>>>>>> +struct function;
>>>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function
*);
>>>>>>>>
>>>>>>>> that's odd and probably should be split out, the function should
>>>>>>>> maybe reside in tree-pretty-print.c.
>>>>>>>
>>>>>>> Ok.
>>>>>>>
>>>>>>>>
>>>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>>>> ===================================================================
>>>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>>>
>>>>>>>> well - doesn't belong here ;)
>>>>>>>
>>>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>>>> change anyway.
>>>>>>>
>>>>>>>>
>>>>>>>> +static hashval_t
>>>>>>>> +passr_hash (const void *p)
>>>>>>>> +{
>>>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +/* Hash equal function  */
>>>>>>>> +
>>>>>>>> +static int
>>>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>>>> +{
>>>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>>>> *const) p1;
>>>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>>>> *const) p2;
>>>>>>>> +
>>>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>>>> +}
>>>>>>>>
>>>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>>>> wrappers.
>>>>>>>
>>>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>>>> thus the wrapper.
>>>>>>>
>>>>>>>>
>>>>>>>> +void
>>>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>>>
>>>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>>
>>>>>>>> +  if (!pass_name_tab)
>>>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>>>
>>>>>>>> see above, the initial size should be larger - we have 223 passes at
the
>>>>>>>> moment, so use 256.
>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>>
>>>>>>>> +  else
>>>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>>>
>>>>>>>> ?  You mean they might clash?
>>>>>>>
>>>>>>> Yes, name clash.
>>>>>>>
>>>>>>>>
>>>>>>>> +struct opt_pass *
>>>>>>>> +get_pass_by_name (const char *name)
>>>>>>>>
>>>>>>>> doesn't need exporting either.
>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>>
>>>>>>>> +      if (is_enable)
>>>>>>>> +        error ("unrecognized option -fenable");
>>>>>>>> +      else
>>>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>>>
>>>>>>>> I think that should be fatal_error - Joseph?
>>>>>>>>
>>>>>>>> +      if (is_enable)
>>>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>>>> +      else
>>>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>>>
>>>>>>>> likewise.
>>>>>>>>
>>>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash,
pass_eq, NULL);
>>>>>>>>
>>>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>>>> the static_pass_number which shoud speed up
>>>>>>>
>>>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>>>> htab will be very small -- it is determined by the number of passes
>>>>>>> specified in the command line, while the VEC requires allocating const
>>>>>>> size array. Not an issue as long as by default the array is not
>>>>>>> allocated.
>>>>>>>
>>>>>>>>
>>>>>>>> +static bool
>>>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>>>> +                                       tree func, htab_t tab)
>>>>>>>> +{
>>>>>>>> +  struct uid_range **slot, *range, key;
>>>>>>>> +  int cgraph_uid;
>>>>>>>> +
>>>>>>>> +  if (!tab)
>>>>>>>> +    return false;
>>>>>>>> +
>>>>>>>> +  key.pass = pass;
>>>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>>>> +  if (!slot || !*slot)
>>>>>>>> +    return false;
>>>>>>>>
>>>>>>>> and simplify the code quite a bit.
>>>>>>>>
>>>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>>>
>>>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>>>> to represent ranges without them).
>>>>>>>
>>>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>>>> via dump.
>>>>>>>
>>>>>>>>
>>>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>>>> current_function_decl);
>>>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>>>> current_function_decl);
>>>>>>>> +
>>>>>>>>   current_pass = pass;
>>>>>>>>
>>>>>>>>   /* Check whether gate check should be avoided.
>>>>>>>>      User controls the value of the gate through the parameter
>>>>>>>> "gate_status". */
>>>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>>>
>>>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>>>> implementation detail and the fact that you always query both
>>>>>>>> hints at that the interface should be like
>>>>>>>>
>>>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>>
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>>>> the rest of the patch as suggested.
>>>>>>>
>>>>>>> Split out. The new patch is attached.
>>>>>>>
>>>>>>> Ok after testing is done?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joseph S. Myers
>>>>>>>>> joseph@codesourcery.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[hubicka_ucw.cz, 2011-06-01 08:13:56]

> Please discard the previous one. This is the right one:
> 
> David
> Index: tree-pretty-print.c
> ===================================================================
> --- tree-pretty-print.c	(revision 174424)
> +++ tree-pretty-print.c	(working copy)
> @@ -3013,3 +3013,36 @@ pp_base_tree_identifier (pretty_printer 
>      pp_append_text (pp, IDENTIFIER_POINTER (id),
>  		    IDENTIFIER_POINTER (id) + IDENTIFIER_LENGTH (id));
>  }
> +
> +/* A helper function that is used to dump function information before the
> +   function dump.  */
> +
> +void
> +dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)

You can get to FUN via DECL_STRUCT_FUNCTION (fndecl) that would save you a
parameter...
> Index: tree-pretty-print.h
> ===================================================================
> --- tree-pretty-print.h	(revision 174422)
> +++ tree-pretty-print.h	(working copy)
> @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  
>  #define GCC_TREE_PRETTY_PRINT_H
>  
>  #include "pretty-print.h"
> +#include "coretypes.h"

.. and need for this
> Index: coretypes.h
> ===================================================================
> --- coretypes.h	(revision 174422)
> +++ coretypes.h	(working copy)
> @@ -75,6 +75,7 @@ typedef struct diagnostic_context diagno
>  struct gimple_seq_d;
>  typedef struct gimple_seq_d *gimple_seq;
>  typedef const struct gimple_seq_d *const_gimple_seq;
> +struct function;

... and this.

Otherwise the patch seems OK.  You need to update Makefile.in for new
dependencies.

Honza

[richard.guenther_gmail.com, 2011-06-01 09:22:59]

On Wed, Jun 1, 2011 at 2:03 AM, Xinliang David Li <davidxl@google.com> wrote:
> Please discard the previous one. This is the right one:

See also Honzas comments (on the wrong patch presumably ;)).

+  if (node)
+    fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d,
decl_uid = %d, cgraph_uid=%d)",
+             dname, aname, fun->funcdef_no, DECL_UID(fdecl), node->uid);
+  else
+    fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, decl_uid = %d)",
+             dname, aname, fun->funcdef_no, DECL_UID(fdecl));
+
+  fprintf (dump_file, "%s\n\n",
+           node->frequency == NODE_FREQUENCY_HOT

you also need to check for node == NULL here.

Ok with this (and honzas suggested change for not passing struct
function *).

Thanks,
Richard.

> David
>
> On Tue, May 31, 2011 at 5:01 PM, Xinliang David Li <davidxl@google.com> wrote:
>> The new patch is attached. The test (c,c++,fortran, java, ada) is on going.
>>
>> Thanks,
>>
>> David
>>
>> On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>> The attached are two simple follow up patches
>>>>>
>>>>> 1) the first patch does some refactorization on function header
>>>>> dumping (with more information printed)
>>>>>
>>>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>>>> results from a previous discussion with Honza -- a) rename
>>>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>>>> make sure pass names are unique.
>>>>>
>>>>> Ok for trunk?
>>>>
>>>> +
>>>> +void
>>>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function
*fun)
>>>>
>>>> This function needs documentation, the ChangeLog entry misses
>>>> the tree-pretty-print.h change.
>>>>
>>>> +struct function;
>>>>
>>>> instead of this please include coretypes.h from tree-pretty-print.h
>>>> and add the struct function forward declaration there if it isn't already
>>>> present.
>>>>
>>>> You change the output of the header, so please make sure you
>>>> have bootstrapped and tested with _all_ languages included
>>>> (and also watch for bugreports for target specific bugs).
>>>>
>>>
>>> Ok.
>>>
>>>> +  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, uid=%d)",
>>>> +           dname, aname, fun->funcdef_no, node->uid);
>>>>
>>>> I see no point in dumping funcdef_no - it wasn't dumped before in
>>>> any place.  Instead I miss dumping of the DECL_UID and thus
>>>> a more specific 'uid', like 'cgraph-uid'.
>>>
>>> Ok will add decl_uid. Funcdef_no is very useful for debugging FDO
>>> coverage mismatch related problems as it is the id used in profile
>>> hashing.
>>>
>>>>
>>>> +  aname = (IDENTIFIER_POINTER
>>>> +          (DECL_ASSEMBLER_NAME (fdecl)));
>>>>
>>>> using DECL_ASSEMBLER_NAME is bad - it might trigger computation
>>>> of DECL_ASSEMBLER_NAME which certainly shouldn't be done
>>>> only for dumping purposes.  Instead do sth like
>>>>
>>>>   if (DECL_ASSEMBLER_NAME_SET_P (fdecl))
>>>>     aname = DECL_ASSEMBLER_NAME (fdecl);
>>>>   else
>>>>     aname = '<unset-asm-name>';
>>>
>>> Ok.
>>>
>>>>
>>>> and please also watch for cgraph_get_node returning NULL.
>>>>
>>>> Also please call the function dump_function_header instead of
>>>> pass_dump_function_header.
>>>>
>>>
>>> Ok.
>>>
>>> Thanks,
>>>
>>> David
>>>> Please re-post with appropriate changes.
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>> On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
>>>>> <richard.guenther@gmail.com> wrote:
>>>>>> On Fri, May 27, 2011 at 12:02 AM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>>> The latest version that only exports 2 functions from passes.c.
>>>>>>
>>>>>> Ok with ...
>>>>>>
>>>>>> @@ -637,4 +637,8 @@ extern bool first_pass_instance;
>>>>>>  /* Declare for plugins.  */
>>>>>>  extern void do_per_function_toporder (void (*) (void *), void *);
>>>>>>
>>>>>> +extern void disable_pass (const char *);
>>>>>> +extern void enable_pass (const char *);
>>>>>> +struct function;
>>>>>> +
>>>>>>
>>>>>> struct function forward decl removed.
>>>>>>
>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass, func);
>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass, func);
>>>>>>
>>>>>> both functions inlined here and removed.
>>>>>>
>>>>>> +#define MAX_PASS_ID 512
>>>>>>
>>>>>> this removed and instead a VEC_safe_grow_cleared () or VEC_length ()
>>>>>> before the accesses.
>>>>>>
>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>> +-fenable-tree-@var{pass}=@var{range-list} @gol
>>>>>>
>>>>>> -fenable-@var{kind}-@var{pass}, etc.
>>>>>>
>>>>>> +@item -fdisable-@var{ipa|tree|rtl}-@var{pass}
>>>>>> +@itemx -fenable-@var{ipa|tree|rtl}-@var{pass}
>>>>>> +@itemx -fdisable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>>> +@itemx -fenable-@var{tree|rtl}-@var{pass}=@var{range-list}
>>>>>>
>>>>>> likewise.
>>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li <davidxl@google.com>
wrote:
>>>>>>>> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>>>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>>>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>>>>>>>> <joseph@codesourcery.com> wrote:
>>>>>>>>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>>>>>>>>
>>>>>>>>>>> Ping. The link to the message:
>>>>>>>>>>>
>>>>>>>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>>>>>>>>
>>>>>>>>>> I don't consider this an option handling patch.  Patches adding whole
new
>>>>>>>>>> features involving new options should be reviewed by maintainers for
the
>>>>>>>>>> part of the compiler relevant to those features (since there isn't a
pass
>>>>>>>>>> manager maintainer, I guess that means middle-end).
>>>>>>>>>
>>>>>>>>> Hmm, I suppose then you reviewed the option handling parts and they
>>>>>>>>> are ok?  Those globbing options always cause headache to me.
>>>>>>>>>
>>>>>>>>> +-fenable-ipa-@var{pass} @gol
>>>>>>>>> +-fenable-rtl-@var{pass} @gol
>>>>>>>>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>>>>>>>>> +-fenable-tree-@var{pass} @gol
>>>>>>>>>
>>>>>>>>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Missed. Will add.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Does the pass name match 1:1 with the dump file name?  In which
>>>>>>>>> case
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>>>>>>>>> pass is statically invoked in the compiler multiple times, the pass
>>>>>>>>> name should be appended with a sequential number starting from 1.
>>>>>>>>>
>>>>>>>>> isn't true as passes that are invoked only a single time lack the
number
>>>>>>>>> suffix (yes, I'd really like that to be changed ...)
>>>>>>>>
>>>>>>>> Yes, pass with single static instance does not need number suffix.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please break likes also in .texi files and stick to 80 columns.
>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>>  Please
>>>>>>>>> document that these options are debugging options and regular
>>>>>>>>> options for enabling/disabling passes should be used.  I would suggest
>>>>>>>>> to group documentation differently and document -fenable-* and
>>>>>>>>> -fdisable-*, thus,
>>>>>>>>>
>>>>>>>>> + -fdisable-@var{kind}-@var{pass}
>>>>>>>>> + -fenable-@var{kind}-@var{pass}
>>>>>>>>>
>>>>>>>>> Even in .texi files please two spaces after a full-stop.
>>>>>>>>
>>>>>>>> Done
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +extern void enable_disable_pass (const char *, bool);
>>>>>>>>>
>>>>>>>>> I'd rather have both enable_pass and disable_pass ;)
>>>>>>>>
>>>>>>>> Ok.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +struct function;
>>>>>>>>> +extern void pass_dump_function_header (FILE *, tree, struct function
*);
>>>>>>>>>
>>>>>>>>> that's odd and probably should be split out, the function should
>>>>>>>>> maybe reside in tree-pretty-print.c.
>>>>>>>>
>>>>>>>> Ok.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Index: tree-ssa-loop-ivopts.c
>>>>>>>>> ===================================================================
>>>>>>>>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>>>>>>>>> +++ tree-ssa-loop-ivopts.c      (working copy)
>>>>>>>>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>>>>>>>>
>>>>>>>>> well - doesn't belong here ;)
>>>>>>>>
>>>>>>>> Sorry -- many things in the same client -- not needed with your latest
>>>>>>>> change anyway.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +static hashval_t
>>>>>>>>> +passr_hash (const void *p)
>>>>>>>>> +{
>>>>>>>>> +  const struct pass_registry *const s = (const struct pass_registry
*const) p;
>>>>>>>>> +  return htab_hash_string (s->unique_name);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +/* Hash equal function  */
>>>>>>>>> +
>>>>>>>>> +static int
>>>>>>>>> +passr_eq (const void *p1, const void *p2)
>>>>>>>>> +{
>>>>>>>>> +  const struct pass_registry *const s1 = (const struct pass_registry
>>>>>>>>> *const) p1;
>>>>>>>>> +  const struct pass_registry *const s2 = (const struct pass_registry
>>>>>>>>> *const) p2;
>>>>>>>>> +
>>>>>>>>> +  return !strcmp (s1->unique_name, s2->unique_name);
>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> you can use htab_hash_string and strcmp directly, no need for these
>>>>>>>>> wrappers.
>>>>>>>>
>>>>>>>> The hashtable entry is not string in this case. It is pass_registry,
>>>>>>>> thus the wrapper.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +void
>>>>>>>>> +register_pass_name (struct opt_pass *pass, const char *name)
>>>>>>>>>
>>>>>>>>> doesn't seem to need exporting, so don't and make it static.
>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +  if (!pass_name_tab)
>>>>>>>>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>>>>>>>>
>>>>>>>>> see above, the initial size should be larger - we have 223 passes at
the
>>>>>>>>> moment, so use 256.
>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +  else
>>>>>>>>> +    return; /* Ignore plugin passes.  */
>>>>>>>>>
>>>>>>>>> ?  You mean they might clash?
>>>>>>>>
>>>>>>>> Yes, name clash.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +struct opt_pass *
>>>>>>>>> +get_pass_by_name (const char *name)
>>>>>>>>>
>>>>>>>>> doesn't need exporting either.
>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +      if (is_enable)
>>>>>>>>> +        error ("unrecognized option -fenable");
>>>>>>>>> +      else
>>>>>>>>> +        error ("unrecognized option -fdisable");
>>>>>>>>>
>>>>>>>>> I think that should be fatal_error - Joseph?
>>>>>>>>>
>>>>>>>>> +      if (is_enable)
>>>>>>>>> +        error ("unknown pass %s specified in -fenable", phase_name);
>>>>>>>>> +      else
>>>>>>>>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>>>>>>>>
>>>>>>>>> likewise.
>>>>>>>>>
>>>>>>>>> +      if (!enabled_pass_uid_range_tab)
>>>>>>>>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash,
pass_eq, NULL);
>>>>>>>>>
>>>>>>>>> instead of using a hashtable here please use a VEC indexed by
>>>>>>>>> the static_pass_number which shoud speed up
>>>>>>>>
>>>>>>>> Ok.  The reason I did not use it is because in most of the cases, the
>>>>>>>> htab will be very small -- it is determined by the number of passes
>>>>>>>> specified in the command line, while the VEC requires allocating const
>>>>>>>> size array. Not an issue as long as by default the array is not
>>>>>>>> allocated.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +static bool
>>>>>>>>> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
>>>>>>>>> +                                       tree func, htab_t tab)
>>>>>>>>> +{
>>>>>>>>> +  struct uid_range **slot, *range, key;
>>>>>>>>> +  int cgraph_uid;
>>>>>>>>> +
>>>>>>>>> +  if (!tab)
>>>>>>>>> +    return false;
>>>>>>>>> +
>>>>>>>>> +  key.pass = pass;
>>>>>>>>> +  slot = (struct uid_range **) htab_find_slot (tab, &key, NO_INSERT);
>>>>>>>>> +  if (!slot || !*slot)
>>>>>>>>> +    return false;
>>>>>>>>>
>>>>>>>>> and simplify the code quite a bit.
>>>>>>>>>
>>>>>>>>> +  cgraph_uid = func ? cgraph_get_node (func)->uid : 0;
>>>>>>>>>
>>>>>>>>> note that cgraph uids are recycled, so it might not be the best idea
>>>>>>>>> to use them as discriminator (though I don't have a good idea how
>>>>>>>>> to represent ranges without them).
>>>>>>>>
>>>>>>>> Yes. It is not a big problem as the blind search does not need to know
>>>>>>>> the id->name mapping. Once the id s found, it can be easily discovered
>>>>>>>> via dump.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> +  explicitly_enabled = is_pass_explicitly_enabled (pass,
>>>>>>>>> current_function_decl);
>>>>>>>>> +  explicitly_disabled = is_pass_explicitly_disabled (pass,
>>>>>>>>> current_function_decl);
>>>>>>>>> +
>>>>>>>>>   current_pass = pass;
>>>>>>>>>
>>>>>>>>>   /* Check whether gate check should be avoided.
>>>>>>>>>      User controls the value of the gate through the parameter
>>>>>>>>> "gate_status". */
>>>>>>>>>   gate_status = (pass->gate == NULL) ? true : pass->gate();
>>>>>>>>> +  gate_status = !explicitly_disabled && (gate_status ||
explicitly_enabled);
>>>>>>>>>
>>>>>>>>> so explicitly disabling wins over explicit enabling ;)  I think this
>>>>>>>>> implementation detail and the fact that you always query both
>>>>>>>>> hints at that the interface should be like
>>>>>>>>>
>>>>>>>>> gate_status = override_gate_status (pass, current_function_decl,
gate_status);
>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> instead.
>>>>>>>>>
>>>>>>>>> Thus, please split out the function header dumping changes and rework
>>>>>>>>> the rest of the patch as suggested.
>>>>>>>>
>>>>>>>> Split out. The new patch is attached.
>>>>>>>>
>>>>>>>> Ok after testing is done?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Richard.
>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joseph S. Myers
>>>>>>>>>> joseph@codesourcery.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[hubicka_ucw.cz, 2011-06-01 09:27:23]

> On Wed, Jun 1, 2011 at 2:03 AM, Xinliang David Li <davidxl@google.com> wrote:
> > Please discard the previous one. This is the right one:
> 
> See also Honzas comments (on the wrong patch presumably ;)).
> 
> +  if (node)
> +    fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d,
> decl_uid = %d, cgraph_uid=%d)",
> +             dname, aname, fun->funcdef_no, DECL_UID(fdecl), node->uid);
> +  else
> +    fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d, decl_uid =
%d)",
> +             dname, aname, fun->funcdef_no, DECL_UID(fdecl));
> +
> +  fprintf (dump_file, "%s\n\n",
> +           node->frequency == NODE_FREQUENCY_HOT
> 
> you also need to check for node == NULL here.
> 
> Ok with this (and honzas suggested change for not passing struct
> function *).
Also I still think the function funcdef_no is quite redundant UID. For debugging
profiling
I would go for cgraph_uid instead.  It has also the advantage of being available
at WPA stage.
But I have nothing against printing it here.

Honza

[hjl.tools_gmail.com, 2011-06-01 19:19:14]

On Mon, May 30, 2011 at 2:44 PM, Xinliang David Li <davidxl@google.com> wrote:
> This is the complete patch for pass name fixes (with test case changes).
>
> David
>
>

I think your change caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49261


H.J.