public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* RFC: Using mode and code macros in *.md files
@ 2004-08-07 18:38 Richard Sandiford
  2004-08-08  4:30 ` James E Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Richard Sandiford @ 2004-08-07 18:38 UTC (permalink / raw)
  To: gcc

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

This is an RFC about using mode and code macros in *.md files.
I've attached a patch that implements the suggested constructs
and an example of how they might be used in mips.md.


Motivation
----------

There are at least three major sources of cut-&-paste in mips.md:

  (1) It has two patterns for almost every pointer-related operation,
      one for when Pmode == SImode and the other for when Pmode == DImode.
      For example:

        (define_insn "indirect_jump_internal1"
          [(set (pc) (match_operand:SI 0 "register_operand" "d"))]
          "!(Pmode == DImode)"
          "%*j\t%0%/"
          [(set_attr "type" "jump")
           (set_attr "mode" "none")])

        (define_insn "indirect_jump_internal2"
          [(set (pc) (match_operand:DI 0 "register_operand" "d"))]
          "Pmode == DImode"
          "%*j\t%0%/"
          [(set_attr "type" "jump")
           (set_attr "mode" "none")])

      It would be nice to be able to write:

        (set (pc) (match_operand:P 0 "register_operand" "d"))

      instead.

  (2) For almost every 32-bit integer pattern with condition X, there is
      an equivalent 64-bit pattern with condition X && TARGET_64BIT.
      For example:

        (define_insn "*norsi3"
          [(set (match_operand:SI 0 "register_operand" "=d")
                (and:SI (not:SI (match_operand:SI 1 "register_operand" "d"))
                        (not:SI (match_operand:SI 2 "register_operand" "d"))))]
          "!TARGET_MIPS16"
          "nor\t%0,%z1,%z2"
          [(set_attr "type" "arith")
           (set_attr "mode" "SI")])

        (define_insn "*nordi3"
          [(set (match_operand:DI 0 "register_operand" "=d")
                (and:DI (not:DI (match_operand:DI 1 "register_operand" "d"))
                        (not:DI (match_operand:DI 2 "register_operand" "d"))))]
          "TARGET_64BIT && !TARGET_MIPS16"
          "nor\t%0,%z1,%z2"
          [(set_attr "type" "arith")
           (set_attr "mode" "DI")])

      Sometimes, as here, the two patterns use the same machine instruction.
      Sometimes they use different instructions, although the 64-bit
      mnemonic is often just "d" + the equivalent 32-bit mnemonic.

      Note that, unlike in the Pmode case, these patterns are not
      mutually-exclusive.  64-bit code can use them both.

  (3) For every SFmode instruction, there is an equivalent DFmode
      instruction that has exactly the same predicates and constraints,
      but which (a) uses '.d' instead of '.s' as the format suffix and
      (b) requires TARGET_DOUBLE_FLOAT.   For example:

        (define_insn "absdf2"
          [(set (match_operand:DF 0 "register_operand" "=f")
                (abs:DF (match_operand:DF 1 "register_operand" "f")))]
          "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT"
          "abs.d\t%0,%1"
          [(set_attr "type" "fabs")
           (set_attr "mode" "DF")])

        (define_insn "abssf2"
          [(set (match_operand:SF 0 "register_operand" "=f")
                (abs:SF (match_operand:SF 1 "register_operand" "f")))]
          "TARGET_HARD_FLOAT"
          "abs.s\t%0,%1"
          [(set_attr "type" "fabs")
           (set_attr "mode" "SF")])


Mode macros
-----------

In the hope of reducing this sort of duplication, I'd like to make
read-rtl.c support a kind of mode macro.  The tentative syntax for
defining a macro is:

    (define_mode_macro MACRO [(MODE1 "COND1") ... (MODEN "CONDN")])

This says that every pattern using ':MACRO' as a mode suffix will
be expanded N times, once with every ':MACRO' replaced by ':MODE1',
once with every ':MACRO' replaced by ':MODE2', and so on.  The version
that uses ':MODEX' will have 'CONDX' added to every C condition in
the pattern.

If a pattern uses several different macros, it will be expanded once
for every possible combination (the macros being applied in declaration
order).

For example, the definition of ':P' for MIPS looks like:

    (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])

We can also add macros for the other variations mentioned above:

    (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
    (define_mode_macro FPR [SF (DF "TARGET_DOUBLE_FLOAT")])

where, as a minor prettification, '(MODE "true")' is written 'MODE'.


Mode attributes
---------------

The string parts of md patterns often have a mode-dependent component.
In order to make full use of mode macros, we'd need some way of changing
the strings in each expansion.

The patch allows mode-dependent substrings to be defined in a
similar way to macros:

    (define_mode_attr ATTR [(MODE1 "VALUE1") ... (MODEN "VALUEN")])

Then, when replacing every occurence of ':MACRO' by ':MODEX', read-rtl.c
also scans each string for suitably-decorated occurences of 'MACRO:ATTR'.
It replaces each such substring with 'VALUEX'.

At the moment, "suitably-decorated" means "in angled brackets",
but I'm not sure if that's the best choice.  The 'MACRO:' prefix
can be dropped if there's no ambiguity.

If something in angled brackets doesn't match a known attribute name,
or if it names an attribute that defines no value for MODEX, that
part of the string will be kept as-is.  The idea is:

   (1) to avoid clobbering or rejecting any fancy asm syntax and
   (2) to allow the 'MACRO:' prefix to be dropped more often, such as
       when a pattern uses both floating-point and integer mode macros
       but uses attributes that only make sense for one or the other.

Note that string substitution only occurs when a macro is being expanded,
so there should be no effect on ports that don't use macros.

The patch also adds two built-in attributes: 'mode', which is the name
of the mode in lower case, and 'MODE', which is the same in upper case.


Examples
--------

This statement defines the format suffix for a MIPS floating-point operation:

    (define_mode_attr fmt [(SF "s") (DF "d")])

The floating-point abs patterns can then be combined as follows:

    (define_insn "abs<mode>2"
      [(set (match_operand:FPR 0 "register_operand" "=f")
            (abs:FPR (match_operand:FPR 1 "register_operand" "f")))]
      "TARGET_HARD_FLOAT"
      "abs.<fmt>\t%0,%1"
      [(set_attr "type" "fabs")
       (set_attr "mode" "<MODE>")])

(with :FPR defined as above).  The combined nor pattern would look like:

    (define_insn "*nor<mode>3"
      [(set (match_operand:GPR 0 "register_operand" "=d")
            (and:GPR (not:GPR (match_operand:GPR 1 "register_operand" "d"))
                     (not:GPR (match_operand:GPR 2 "register_operand" "d"))))]
      "!TARGET_MIPS16"
      "nor\t%0,%1,%2"
      [(set_attr "type" "arith")
       (set_attr "mode" "<MODE>")])

A mode attribute like:

    (define_mode_attr load [(SI "lw") (DI "ld")])

means that a single pattern can be used for loading call addresses:

    (define_insn "load_call<mode>"
      [(set (match_operand:P 0 "register_operand" "=c")
            (unspec:P [(match_operand:P 1 "register_operand" "r")
                       (match_operand:P 2 "immediate_operand" "")
                       (reg:P FAKE_CALL_REGNO)]
                      UNSPEC_LOAD_CALL))]
      "TARGET_ABICALLS"
      "<load>\t%0,%R2(%1)"
      [(set_attr "type" "load")
       (set_attr "length" "4")])

and for left loads:

    (define_insn "mov_<load>l"
      [(set (match_operand:GPR 0 "register_operand" "=d")
            (unspec:GPR [(match_operand:BLK 1 "memory_operand" "m")
                         (match_operand:QI 2 "memory_operand" "m")]
                        UNSPEC_LOAD_LEFT))]
      "!TARGET_MIPS16"
      "<load>l\t%0,%2"
      [(set_attr "type" "load")
       (set_attr "mode" "<MODE>")
       (set_attr "hazard" "none")])

(to pick two arbitrary examples).


Code macros and attributes
--------------------------

Although most duplication in mips.md comes from using different modes,
there are some examples of code-based duplication.  The worst offender
is probably:

    (define_expand "bunordered"
      [(set (pc)
            (if_then_else (unordered:CC (cc0)
                                        (const_int 0))
                          (label_ref (match_operand 0 ""))
                          (pc)))]
      ""
    {
      gen_conditional_branch (operands, UNORDERED);
      DONE;
    })

followed by similar define_expands for every other comparison code.
We also have:

    (define_insn "sunordered_df"
      [(set (match_operand:CC 0 "register_operand" "=z")
            (unordered:CC (match_operand:DF 1 "register_operand" "f")
                          (match_operand:DF 2 "register_operand" "f")))]
      "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT"
      "c.un.d\t%Z0%1,%2"
      [(set_attr "type" "fcmp")
       (set_attr "mode" "FPSW")])

followed by a similar pattern for every other native floating-point
comparison code.

The patch therefore adds macro and attribute support for codes as
well as modes.  It uses the syntax:

    (define_code_macro MACRO [(CODE1 "COND1") ... (CODEN "CONDN")])
    (define_code_attr ATTR [(CODE1 "VALUE1") ... (CODEN "VALUEN")])

and defines special "code" and "CODE" attributes that are analagous
to the mode ones.  In the case of code macros, every CODEX must have
the same format.

For example, code macros allow us to combine 7 of the c.cond.fmt patterns:

    (define_code_macro floatcond [unordered unlt uneq unle eq le lt])
    (define_code_attr floatcond [(unordered "un")
                                 (unlt "ult")
                                 (uneq "ueq")
                                 (unle "ule")
                                 (eq "eq")
                                 (le "le")
                                 (lt "lt")])

    (define_insn "s<code>_<mode>"
      [(set (match_operand:CC 0 "register_operand" "=z")
            (floatcond:CC (match_operand:FPR 1 "register_operand" "f")
                          (match_operand:FPR 2 "register_operand" "f")))]
      "TARGET_HARD_FLOAT"
      "c.<floatcond>.<fmt>\t%Z0%1,%2"
      [(set_attr "type" "fcmp")
       (set_attr "mode" "FPSW")])


The patch
---------

The patch is only an RFC at this stage.  The mips.md part in particular
is only proof of concept since:

    (1) It's unlikely that I'd apply such a big change in one go.
        (Far too easy to make mistakes.)

    (2) There are other bits that could also be cleaned up as well.
        I decided to stop when I'd whittled it down to <6000 lines.

The current diffstat for mips.md is:

    mips.md | 2937 ++++++++++++--------------------------------------------
    1 files changed, 676 insertions(+), 2261 deletions(-)

but like I say, I'm hoping there's more to come.

The patch to read-rtl.c relies on two feeder changes:

    (1) Promote the string obstack to file scope and give it a more
        appropriate name.

    (2) Simplify the format walk.

I've attached these two patches separately so that the main one is
easier to read.  I've also tried to provide some suitable md.texi docs.

FWIW, a slightly earlier version of the patch has been bootstrapped
& regression tested on mips-sgi-irix6.5.  It's just been code clean-up
since then.

So, what do folks think?  Would a feature like this be acceptable?
If so, are there any suggestions on how it could be improved?
Any concerns or ideas about the syntax?

Richard


[-- Attachment #2: macro-prep-1.diff --]
[-- Type: text/plain, Size: 7193 bytes --]

	* read-rtl.c (string_obstack): New file-scope variable.
	(read_string, read_quoted_string, read_braced_string)
	(read_escape): Remove obstack parameter and use string_obstack instead.
	(read_rtx): Remove function-local rtl_obstack and initialize
	string_obstack instead.  Update call to read_string.

--- read-rtl.c.cvs	Sat Aug  7 17:20:40 2004
+++ read-rtl.c	Fri Aug  6 07:02:42 2004
@@ -34,15 +34,18 @@ static void fatal_with_file_and_line (FI
   ATTRIBUTE_PRINTF_2 ATTRIBUTE_NORETURN;
 static void fatal_expected_char (FILE *, int, int) ATTRIBUTE_NORETURN;
 static void read_name (char *, FILE *);
-static char *read_string (struct obstack *, FILE *, int);
-static char *read_quoted_string (struct obstack *, FILE *);
-static char *read_braced_string (struct obstack *, FILE *);
-static void read_escape (struct obstack *, FILE *);
+static char *read_string (FILE *, int);
+static char *read_quoted_string (FILE *);
+static char *read_braced_string (FILE *);
+static void read_escape (FILE *);
 static hashval_t def_hash (const void *);
 static int def_name_eq_p (const void *, const void *);
 static void read_constants (FILE *infile, char *tmp_char);
 static void validate_const_int (FILE *, const char *);
 
+/* Obstack used for allocating RTL strings.  */
+static struct obstack string_obstack;
+
 /* Subroutines of read_rtx.  */
 
 /* The current line number for the file.  */
@@ -203,7 +206,7 @@ read_name (char *str, FILE *infile)
 /* Subroutine of the string readers.  Handles backslash escapes.
    Caller has read the backslash, but not placed it into the obstack.  */
 static void
-read_escape (struct obstack *ob, FILE *infile)
+read_escape (FILE *infile)
 {
   int c = getc (infile);
 
@@ -232,31 +235,31 @@ read_escape (struct obstack *ob, FILE *i
     case 'a': case 'b': case 'f': case 'n': case 'r': case 't': case 'v':
     case '0': case '1': case '2': case '3': case '4': case '5': case '6':
     case '7': case 'x':
-      obstack_1grow (ob, '\\');
+      obstack_1grow (&string_obstack, '\\');
       break;
 
       /* \; makes stuff for a C string constant containing
 	 newline and tab.  */
     case ';':
-      obstack_grow (ob, "\\n\\t", 4);
+      obstack_grow (&string_obstack, "\\n\\t", 4);
       return;
 
       /* pass anything else through, but issue a warning.  */
     default:
       fprintf (stderr, "%s:%d: warning: unrecognized escape \\%c\n",
 	       read_rtx_filename, read_rtx_lineno, c);
-      obstack_1grow (ob, '\\');
+      obstack_1grow (&string_obstack, '\\');
       break;
     }
 
-  obstack_1grow (ob, c);
+  obstack_1grow (&string_obstack, c);
 }
 
 
 /* Read a double-quoted string onto the obstack.  Caller has scanned
    the leading quote.  */
 static char *
-read_quoted_string (struct obstack *ob, FILE *infile)
+read_quoted_string (FILE *infile)
 {
   int c;
 
@@ -267,30 +270,30 @@ read_quoted_string (struct obstack *ob, 
 	read_rtx_lineno++;
       else if (c == '\\')
 	{
-	  read_escape (ob, infile);
+	  read_escape (infile);
 	  continue;
 	}
       else if (c == '"')
 	break;
 
-      obstack_1grow (ob, c);
+      obstack_1grow (&string_obstack, c);
     }
 
-  obstack_1grow (ob, 0);
-  return (char *) obstack_finish (ob);
+  obstack_1grow (&string_obstack, 0);
+  return (char *) obstack_finish (&string_obstack);
 }
 
-/* Read a braced string (a la Tcl) onto the obstack.  Caller has
-   scanned the leading brace.  Note that unlike quoted strings,
+/* Read a braced string (a la Tcl) onto the string obstack.  Caller
+   has scanned the leading brace.  Note that unlike quoted strings,
    the outermost braces _are_ included in the string constant.  */
 static char *
-read_braced_string (struct obstack *ob, FILE *infile)
+read_braced_string (FILE *infile)
 {
   int c;
   int brace_depth = 1;  /* caller-processed */
   unsigned long starting_read_rtx_lineno = read_rtx_lineno;
 
-  obstack_1grow (ob, '{');
+  obstack_1grow (&string_obstack, '{');
   while (brace_depth)
     {
       c = getc (infile); /* Read the string  */
@@ -303,7 +306,7 @@ read_braced_string (struct obstack *ob, 
 	brace_depth--;
       else if (c == '\\')
 	{
-	  read_escape (ob, infile);
+	  read_escape (infile);
 	  continue;
 	}
       else if (c == EOF)
@@ -311,11 +314,11 @@ read_braced_string (struct obstack *ob, 
 	  (infile, "missing closing } for opening brace on line %lu",
 	   starting_read_rtx_lineno);
 
-      obstack_1grow (ob, c);
+      obstack_1grow (&string_obstack, c);
     }
 
-  obstack_1grow (ob, 0);
-  return (char *) obstack_finish (ob);
+  obstack_1grow (&string_obstack, 0);
+  return (char *) obstack_finish (&string_obstack);
 }
 
 /* Read some kind of string constant.  This is the high-level routine
@@ -323,7 +326,7 @@ read_braced_string (struct obstack *ob, 
    and dispatch to the appropriate string constant reader.  */
 
 static char *
-read_string (struct obstack *ob, FILE *infile, int star_if_braced)
+read_string (FILE *infile, int star_if_braced)
 {
   char *stringbuf;
   int saw_paren = 0;
@@ -337,12 +340,12 @@ read_string (struct obstack *ob, FILE *i
     }
 
   if (c == '"')
-    stringbuf = read_quoted_string (ob, infile);
+    stringbuf = read_quoted_string (infile);
   else if (c == '{')
     {
       if (star_if_braced)
-	obstack_1grow (ob, '*');
-      stringbuf = read_braced_string (ob, infile);
+	obstack_1grow (&string_obstack, '*');
+      stringbuf = read_braced_string (infile);
     }
   else
     fatal_with_file_and_line (infile, "expected `\"' or `{', found `%c'", c);
@@ -522,7 +525,6 @@ read_rtx (FILE *infile)
   HOST_WIDE_INT tmp_wide;
 
   /* Obstack used for allocating RTL objects.  */
-  static struct obstack rtl_obstack;
   static int initialized;
 
   /* Linked list structure for making RTXs: */
@@ -532,10 +534,11 @@ read_rtx (FILE *infile)
       rtx value;		/* Value of this node.  */
     };
 
-  if (!initialized) {
-    obstack_init (&rtl_obstack);
-    initialized = 1;
-  }
+  if (!initialized)
+    {
+      obstack_init (&string_obstack);
+      initialized = 1;
+    }
 
 again:
   c = read_skip_spaces (infile); /* Should be open paren.  */
@@ -674,7 +677,7 @@ again:
 	     written with a brace block instead of a string constant.  */
 	  star_if_braced = (format_ptr[-1] == 'T');
 
-	  stringbuf = read_string (&rtl_obstack, infile, star_if_braced);
+	  stringbuf = read_string (infile, star_if_braced);
 
 	  /* For insn patterns, we want to provide a default name
 	     based on the file and line, like "*foo.md:12", if the
@@ -691,11 +694,11 @@ again:
 	      for (slash = fn; *slash; slash ++)
 		if (*slash == '/' || *slash == '\\' || *slash == ':')
 		  fn = slash + 1;
-	      obstack_1grow (&rtl_obstack, '*');
-	      obstack_grow (&rtl_obstack, fn, strlen (fn));
+	      obstack_1grow (&string_obstack, '*');
+	      obstack_grow (&string_obstack, fn, strlen (fn));
 	      sprintf (line_name, ":%d", read_rtx_lineno);
-	      obstack_grow (&rtl_obstack, line_name, strlen (line_name)+1);
-	      stringbuf = (char *) obstack_finish (&rtl_obstack);
+	      obstack_grow (&string_obstack, line_name, strlen (line_name)+1);
+	      stringbuf = (char *) obstack_finish (&string_obstack);
 	    }
 
 	  if (star_if_braced)

[-- Attachment #3: macro-prep-2.diff --]
[-- Type: text/plain, Size: 1458 bytes --]

	* read-rtl.c (read_rtx): Tidy use of format_ptr.

--- read-rtl.c.1	Sat Aug  7 17:21:00 2004
+++ read-rtl.c	Sat Aug  7 17:24:25 2004
@@ -597,8 +597,8 @@ again:
   else
     ungetc (i, infile);
 
-  for (i = 0; i < GET_RTX_LENGTH (GET_CODE (return_rtx)); i++)
-    switch (*format_ptr++)
+  for (i = 0; format_ptr[i] != 0; i++)
+    switch (format_ptr[i])
       {
 	/* 0 means a field for internal use only.
 	   Don't expect it to be present in the input.  */
@@ -667,7 +667,7 @@ again:
 	      /* 'S' fields are optional and should be NULL if no string
 		 was given.  Also allow normal 's' and 'T' strings to be
 		 omitted, treating them in the same way as empty strings.  */
-	      XSTR (return_rtx, i) = (format_ptr[-1] == 'S' ? NULL : "");
+	      XSTR (return_rtx, i) = (format_ptr[i] == 'S' ? NULL : "");
 	      break;
 	    }
 
@@ -675,7 +675,7 @@ again:
 	     DEFINE_INSN_AND_SPLIT, or DEFINE_PEEPHOLE automatically
 	     gets a star inserted as its first character, if it is
 	     written with a brace block instead of a string constant.  */
-	  star_if_braced = (format_ptr[-1] == 'T');
+	  star_if_braced = (format_ptr[i] == 'T');
 
 	  stringbuf = read_string (infile, star_if_braced);
 
@@ -740,7 +740,7 @@ again:
       default:
 	fprintf (stderr,
 		 "switch format wrong in rtl.read_rtx(). format was: %c.\n",
-		 format_ptr[-1]);
+		 format_ptr[i]);
 	fprintf (stderr, "\tfile position: %ld\n", ftell (infile));
 	abort ();
       }

[-- Attachment #4: macro-main.diff --]
[-- Type: text/plain, Size: 36335 bytes --]

	* read-rtl.c (map_value, mapping, macro_group): New structures.
	(modes, codes, bellwether_codes): New variables.
	(BELLWETHER_CODE, find_mode, uses_mode_macro_p, apply_mode_macro)
	(find_code, uses_code_macro_p, apply_code_macro, apply_macro_to_string)
	(apply_macro_to_rtx, uses_macro_p, add_condition_to_string)
	(add_condition_to_rtx, apply_macro_traverse, add_mapping)
	(add_map_value, initialize_macros): New functions.
	(def_hash, def_hash_eq_p): Generalize to anything that points to,
	or starts with, a char * field.
	(find_macro, read_mapping, check_code_macro): New functions.
	(read_rtx_1): New, split out from read_rtx.  Handle the new
	define_{mode,code}_{macro,attr} constructs.  Use find_macro
	to parse the name of a code or mode.  Use BELLWETHER_CODE to
	extract the format and to choose a suitable code for rtx_alloc.
	Modify recursive invocations to use read_rtx_1.
	(read_rtx): Call initialize_macros.  Apply code and mode macros
	to the rtx returned by read_rtx_1.  Cache everything after the
	first macro expansion for subsequent read_rtx calls.
	* doc/md.texi: Document mode and code macros.

*** read-rtl.c.2	Fri Aug  6 07:04:59 2004
--- read-rtl.c	Sat Aug  7 17:45:47 2004
*************** Software Foundation, 59 Temple Place - S
*** 30,38 ****
--- 30,105 ----
  
  static htab_t md_constants;
  
+ /* One element in a singly-linked list of (integer, string) pairs.  */
+ struct map_value {
+   struct map_value *next;
+   int number;
+   const char *string;
+ };
+ 
+ /* Maps a macro or attribute name to a list of (integer, string) pairs.
+    The integers are mode or code values; the strings are either C conditions
+    or attribute values.  */
+ struct mapping {
+   /* The name of the macro or attribute.  */
+   const char *name;
+ 
+   /* The group (modes or codes) to which the macro or attribute belongs.  */
+   struct macro_group *group;
+ 
+   /* Gives a unique number to the attribute or macro.  Numbers are
+      allocated consecutively, starting at 0.  */
+   int index;
+ 
+   /* The list of (integer, string) pairs.  */
+   struct map_value *values;
+ };
+ 
+ /* A structure for abstracting the common parts of code and mode macros.  */
+ struct macro_group {
+   /* Tables of "mapping" structures, one for attributes and one for macros.  */
+   htab_t attrs, macros;
+ 
+   /* The number of "real" modes or codes (and by extension, the first
+      number available for use as a macro placeholder).  */
+   int num_builtins;
+ 
+   /* Treat the given string as the name of a standard mode or code and
+      return its integer value.  Use the given file for error reporting.  */
+   int (*find_builtin) (const char *, FILE *);
+ 
+   /* Return true if the given rtx uses the given mode or code.  */
+   bool (*uses_macro_p) (rtx, int);
+ 
+   /* Make the given rtx use the given mode or code.  */
+   void (*apply_macro) (rtx, int);
+ };
+ 
+ /* If CODE is the number of a code macro, return a real rtx code that
+    has the same format.  Return CODE otherwise.  */
+ #define BELLWETHER_CODE(CODE) \
+   ((CODE) < NUM_RTX_CODE ? CODE : bellwether_codes[CODE - NUM_RTX_CODE])
+ 
  static void fatal_with_file_and_line (FILE *, const char *, ...)
    ATTRIBUTE_PRINTF_2 ATTRIBUTE_NORETURN;
  static void fatal_expected_char (FILE *, int, int) ATTRIBUTE_NORETURN;
+ static int find_mode (const char *, FILE *);
+ static bool uses_mode_macro_p (rtx, int);
+ static void apply_mode_macro (rtx, int);
+ static int find_code (const char *, FILE *);
+ static bool uses_code_macro_p (rtx, int);
+ static void apply_code_macro (rtx, int);
+ static const char *apply_macro_to_string (const char *, struct mapping *, int);
+ static rtx apply_macro_to_rtx (rtx, struct mapping *, int);
+ static bool uses_macro_p (rtx, struct mapping *);
+ static const char *add_condition_to_string (const char *, const char *);
+ static void add_condition_to_rtx (rtx, const char *);
+ static int apply_macro_traverse (void **, void *);
+ static struct mapping *add_mapping (struct macro_group *, htab_t t,
+ 				    const char *, FILE *);
+ static struct map_value **add_map_value (struct map_value **,
+ 					 int, const char *);
+ static void initialize_macros (void);
  static void read_name (char *, FILE *);
  static char *read_string (FILE *, int);
  static char *read_quoted_string (FILE *);
*************** static hashval_t def_hash (const void *)
*** 42,47 ****
--- 109,124 ----
  static int def_name_eq_p (const void *, const void *);
  static void read_constants (FILE *infile, char *tmp_char);
  static void validate_const_int (FILE *, const char *);
+ static int find_macro (struct macro_group *, const char *, FILE *);
+ static struct mapping *read_mapping (struct macro_group *, htab_t, FILE *);
+ static void check_code_macro (struct mapping *, FILE *);
+ static rtx read_rtx_1 (FILE *);
+ 
+ /* The mode and code macro structures.  */
+ static struct macro_group modes, codes;
+ 
+ /* Index I is the value of BELLWETHER (I + NUM_RTX_CODE).  */
+ static enum rtx_code *bellwether_codes;
  
  /* Obstack used for allocating RTL strings.  */
  static struct obstack string_obstack;
*************** fatal_expected_char (FILE *infile, int e
*** 97,102 ****
--- 174,566 ----
  			    expected_c, actual_c);
  }
  
+ /* Implementations of the macro_group callbacks for modes.  */
+ 
+ static int
+ find_mode (const char *name, FILE *infile)
+ {
+   int i;
+ 
+   for (i = 0; i < NUM_MACHINE_MODES; i++)
+     if (strcmp (GET_MODE_NAME (i), name) == 0)
+       return i;
+ 
+   fatal_with_file_and_line (infile, "unknown mode `%s'", name);
+ }
+ 
+ static bool
+ uses_mode_macro_p (rtx x, int mode)
+ {
+   return (int) GET_MODE (x) == mode;
+ }
+ 
+ static void
+ apply_mode_macro (rtx x, int mode)
+ {
+   PUT_MODE (x, mode);
+ }
+ 
+ /* Implementations of the macro_group callbacks for codes.  */
+ 
+ static int
+ find_code (const char *name, FILE *infile)
+ {
+   int i;
+ 
+   for (i = 0; i < NUM_RTX_CODE; i++)
+     if (strcmp (GET_RTX_NAME (i), name) == 0)
+       return i;
+ 
+   fatal_with_file_and_line (infile, "unknown rtx code `%s'", name);
+ }
+ 
+ static bool
+ uses_code_macro_p (rtx x, int code)
+ {
+   return (int) GET_CODE (x) == code;
+ }
+ 
+ static void
+ apply_code_macro (rtx x, int code)
+ {
+   PUT_CODE (x, code);
+ }
+ 
+ /* Given that MACRO is being expanded as VALUE, apply the appropriate
+    string substitutions to STRING.  Return the new string if any changes
+    were needed, otherwise return STRING itself.  */
+ 
+ static const char *
+ apply_macro_to_string (const char *string, struct mapping *macro, int value)
+ {
+   char *base, *copy, *p, *attr, *start, *end;
+   struct mapping *m;
+   struct map_value *v;
+ 
+   if (string == 0)
+     return string;
+ 
+   base = p = copy = ASTRDUP (string);
+   while ((start = index (p, '<')) && (end = index (start, '>')))
+     {
+       p = start + 1;
+ 
+       /* If there's a "macro:" prefix, check whether the macro name matches.
+ 	 Set ATTR to the start of the attribute name.  */
+       attr = index (p, ':');
+       if (attr == 0 || attr > end)
+ 	attr = p;
+       else
+ 	{
+ 	  if (strncmp (p, macro->name, attr - p) != 0
+ 	      || macro->name[attr - p] != 0)
+ 	    continue;
+ 	  attr++;
+ 	}
+ 
+       /* Find the attribute specification.  */
+       *end = 0;
+       m = (struct mapping *) htab_find (macro->group->attrs, &attr);
+       *end = '>';
+       if (m == 0)
+ 	continue;
+ 
+       /* Find the attribute value for VALUE.  */
+       for (v = m->values; v != 0; v = v->next)
+ 	if (v->number == value)
+ 	  break;
+       if (v == 0)
+ 	continue;
+ 
+       /* Add everything between the last copied byte and the '<',
+ 	 then add in the attribute value.  */
+       obstack_grow (&string_obstack, base, start - base);
+       obstack_grow (&string_obstack, v->string, strlen (v->string));
+       base = end + 1;
+     }
+   if (base != copy)
+     {
+       obstack_grow (&string_obstack, base, strlen (base) + 1);
+       return (char *) obstack_finish (&string_obstack);
+     }
+   return string;
+ }
+ 
+ /* Return a copy of ORIGINAL in which all uses of MACRO have been
+    replaced by VALUE.  */
+ 
+ static rtx
+ apply_macro_to_rtx (rtx original, struct mapping *macro, int value)
+ {
+   struct macro_group *group;
+   const char *format_ptr;
+   int i, j;
+   rtx x;
+   enum rtx_code bellwether_code;
+ 
+   if (original == 0)
+     return original;
+ 
+   /* Create a shallow copy of ORIGINAL.  */
+   bellwether_code = BELLWETHER_CODE (GET_CODE (original));
+   x = rtx_alloc (bellwether_code);
+   memcpy (x, original, RTX_SIZE (bellwether_code));
+ 
+   /* Change the mode or code itself.  */
+   group = macro->group;
+   if (group->uses_macro_p (x, macro->index + group->num_builtins))
+     group->apply_macro (x, value);
+ 
+   /* Change each string and recursively change each rtx.  */
+   format_ptr = GET_RTX_FORMAT (bellwether_code);
+   for (i = 0; format_ptr[i] != 0; i++)
+     switch (format_ptr[i])
+       {
+       case 'S':
+       case 'T':
+       case 's':
+ 	XSTR (x, i) = apply_macro_to_string (XSTR (x, i), macro, value);
+ 	break;
+ 
+       case 'e':
+ 	XEXP (x, i) = apply_macro_to_rtx (XEXP (x, i), macro, value);
+ 	break;
+ 
+       case 'V':
+       case 'E':
+ 	if (XVEC (original, i))
+ 	  {
+ 	    XVEC (x, i) = rtvec_alloc (XVECLEN (original, i));
+ 	    for (j = 0; j < XVECLEN (x, i); j++)
+ 	      XVECEXP (x, i, j) = apply_macro_to_rtx (XVECEXP (original, i, j),
+ 						      macro, value);
+ 	  }
+ 	break;
+ 
+       default:
+ 	break;
+       }
+   return x;
+ }
+ 
+ /* Return true if X (or some subexpression of X) uses macro MACRO.  */
+ 
+ static bool
+ uses_macro_p (rtx x, struct mapping *macro)
+ {
+   struct macro_group *group;
+   const char *format_ptr;
+   int i, j;
+ 
+   if (x == 0)
+     return false;
+ 
+   group = macro->group;
+   if (group->uses_macro_p (x, macro->index + group->num_builtins))
+     return true;
+ 
+   format_ptr = GET_RTX_FORMAT (BELLWETHER_CODE (GET_CODE (x)));
+   for (i = 0; format_ptr[i] != 0; i++)
+     switch (format_ptr[i])
+       {
+       case 'e':
+ 	if (uses_macro_p (XEXP (x, i), macro))
+ 	  return true;
+ 	break;
+ 
+       case 'V':
+       case 'E':
+ 	if (XVEC (x, i))
+ 	  for (j = 0; j < XVECLEN (x, i); j++)
+ 	    if (uses_macro_p (XVECEXP (x, i, j), macro))
+ 	      return true;
+ 	break;
+ 
+       default:
+ 	break;
+       }
+   return false;
+ }
+ 
+ /* Return a condition that must satisfy both ORIGINAL and EXTRA.  If ORIGINAL
+    has the form "&& ..." (as used in define_insn_and_splits), assume that
+    EXTRA is already satisfied.  Empty strings are treated like "true".  */
+ 
+ static const char *
+ add_condition_to_string (const char *original, const char *extra)
+ {
+   char *result;
+ 
+   if (original == 0 || original[0] == 0)
+     return extra;
+ 
+   if ((original[0] == '&' && original[1] == '&') || extra[0] == 0)
+     return original;
+ 
+   asprintf (&result, "(%s) && (%s)", original, extra);
+   return result;
+ }
+ 
+ /* Like add_condition, but applied to all conditions in rtx X.  */
+ 
+ static void
+ add_condition_to_rtx (rtx x, const char *extra)
+ {
+   switch (GET_CODE (x))
+     {
+     case DEFINE_INSN:
+     case DEFINE_EXPAND:
+       XSTR (x, 2) = add_condition_to_string (XSTR (x, 2), extra);
+       break;
+ 
+     case DEFINE_SPLIT:
+     case DEFINE_PEEPHOLE:
+     case DEFINE_PEEPHOLE2:
+     case DEFINE_COND_EXEC:
+       XSTR (x, 1) = add_condition_to_string (XSTR (x, 1), extra);
+       break;
+ 
+     case DEFINE_INSN_AND_SPLIT:
+       XSTR (x, 2) = add_condition_to_string (XSTR (x, 2), extra);
+       XSTR (x, 4) = add_condition_to_string (XSTR (x, 4), extra);
+       break;
+ 
+     default:
+       break;
+     }
+ }
+ 
+ /* A htab_traverse callback.  Search the EXPR_LIST given by DATA
+    for rtxes that use the macro in *SLOT.  Replace each such rtx
+    with a list of expansions.  */
+ 
+ static int
+ apply_macro_traverse (void **slot, void *data)
+ {
+   struct mapping *macro;
+   struct map_value *v;
+   rtx elem, new_elem, original, x;
+ 
+   macro = (struct mapping *) *slot;
+   for (elem = (rtx) data; elem != 0; elem = XEXP (elem, 1))
+     if (uses_macro_p (XEXP (elem, 0), macro))
+       {
+ 	original = XEXP (elem, 0);
+ 	for (v = macro->values; v != 0; v = v->next)
+ 	  {
+ 	    x = apply_macro_to_rtx (original, macro, v->number);
+ 	    add_condition_to_rtx (x, v->string);
+ 	    if (v != macro->values)
+ 	      {
+ 		/* Insert a new EXPR_LIST node after ELEM and put the
+ 		   new expansion there.  */
+ 		new_elem = rtx_alloc (EXPR_LIST);
+ 		XEXP (new_elem, 1) = XEXP (elem, 1);
+ 		XEXP (elem, 1) = new_elem;
+ 		elem = new_elem;
+ 	      }
+ 	    XEXP (elem, 0) = x;
+ 	  }
+     }
+   return 1;
+ }
+ 
+ /* Add a new "mapping" structure to hashtable TABLE.  NAME is the name
+    of the mapping, GROUP is the group to which it belongs, and INFILE
+    is the file that defined the mapping.  */
+ 
+ static struct mapping *
+ add_mapping (struct macro_group *group, htab_t table,
+ 	     const char *name, FILE *infile)
+ {
+   struct mapping *m;
+   void **slot;
+ 
+   m = XNEW (struct mapping);
+   m->name = xstrdup (name);
+   m->group = group;
+   m->index = htab_elements (table);
+   m->values = 0;
+ 
+   slot = htab_find_slot (table, m, INSERT);
+   if (*slot != 0)
+     fatal_with_file_and_line (infile, "`%s' already defined", name);
+ 
+   *slot = m;
+   return m;
+ }
+ 
+ /* Add the pair (NUMBER, STRING) to a list of map_value structures.
+    END_PTR points to the current null terminator for the list; return
+    a pointer the new null terminator.  */
+ 
+ static struct map_value **
+ add_map_value (struct map_value **end_ptr, int number, const char *string)
+ {
+   struct map_value *value;
+ 
+   value = XNEW (struct map_value);
+   value->next = 0;
+   value->number = number;
+   value->string = string;
+ 
+   *end_ptr = value;
+   return &value->next;
+ }
+ 
+ /* Do one-time initialization of the mode and code attributes.  */
+ 
+ static void
+ initialize_macros (void)
+ {
+   struct mapping *lower, *upper;
+   struct map_value **lower_ptr, **upper_ptr;
+   char *copy, *p;
+   int i;
+ 
+   modes.attrs = htab_create (13, def_hash, def_name_eq_p, 0);
+   modes.macros = htab_create (13, def_hash, def_name_eq_p, 0);
+   modes.num_builtins = MAX_MACHINE_MODE;
+   modes.find_builtin = find_mode;
+   modes.uses_macro_p = uses_mode_macro_p;
+   modes.apply_macro = apply_mode_macro;
+ 
+   codes.attrs = htab_create (13, def_hash, def_name_eq_p, 0);
+   codes.macros = htab_create (13, def_hash, def_name_eq_p, 0);
+   codes.num_builtins = NUM_RTX_CODE;
+   codes.find_builtin = find_code;
+   codes.uses_macro_p = uses_code_macro_p;
+   codes.apply_macro = apply_code_macro;
+ 
+   lower = add_mapping (&modes, modes.attrs, "mode", 0);
+   upper = add_mapping (&modes, modes.attrs, "MODE", 0);
+   lower_ptr = &lower->values;
+   upper_ptr = &upper->values;
+   for (i = 0; i < MAX_MACHINE_MODE; i++)
+     {
+       copy = xstrdup (GET_MODE_NAME (i));
+       for (p = copy; *p != 0; p++)
+ 	*p = TOLOWER (*p);
+ 
+       upper_ptr = add_map_value (upper_ptr, i, GET_MODE_NAME (i));
+       lower_ptr = add_map_value (lower_ptr, i, copy);
+     }
+ 
+   lower = add_mapping (&codes, codes.attrs, "code", 0);
+   upper = add_mapping (&codes, codes.attrs, "CODE", 0);
+   lower_ptr = &lower->values;
+   upper_ptr = &upper->values;
+   for (i = 0; i < NUM_RTX_CODE; i++)
+     {
+       copy = xstrdup (GET_RTX_NAME (i));
+       for (p = copy; *p != 0; p++)
+ 	*p = TOUPPER (*p);
+ 
+       lower_ptr = add_map_value (lower_ptr, i, GET_RTX_NAME (i));
+       upper_ptr = add_map_value (upper_ptr, i, copy);
+     }
+ }
+ 
  /* Read chars from INFILE until a non-whitespace char
     and return that.  Comments, both Lisp style and C style,
     are treated as whitespace.
*************** atoll (const char *p)
*** 398,421 ****
  }
  #endif
  
! /* Given a constant definition, return a hash code for its name.  */
  static hashval_t
  def_hash (const void *def)
  {
    unsigned result, i;
!   const char *string = ((const struct md_constant *) def)->name;
  
!   for (result = i = 0;*string++ != '\0'; i++)
      result += ((unsigned char) *string << (i % CHAR_BIT));
    return result;
  }
  
! /* Given two constant definitions, return true if they have the same name.  */
  static int
  def_name_eq_p (const void *def1, const void *def2)
  {
!   return ! strcmp (((const struct md_constant *) def1)->name,
! 		   ((const struct md_constant *) def2)->name);
  }
  
  /* INFILE is a FILE pointer to read text from.  TMP_CHAR is a buffer suitable
--- 862,887 ----
  }
  #endif
  
! /* Given an object that starts with a char * name field, return a hash
!    code for its name.  */
  static hashval_t
  def_hash (const void *def)
  {
    unsigned result, i;
!   const char *string = *(const char *const *) def;
  
!   for (result = i = 0; *string++ != '\0'; i++)
      result += ((unsigned char) *string << (i % CHAR_BIT));
    return result;
  }
  
! /* Given two objects that start with char * name fields, return true if
!    they have the same name.  */
  static int
  def_name_eq_p (const void *def1, const void *def2)
  {
!   return ! strcmp (*(const char *const *) def1,
! 		   *(const char *const *) def2);
  }
  
  /* INFILE is a FILE pointer to read text from.  TMP_CHAR is a buffer suitable
*************** validate_const_int (FILE *infile, const 
*** 504,509 ****
--- 970,1071 ----
      fatal_with_file_and_line (infile, "invalid decimal constant \"%s\"\n", string);
  }
  
+ /* Search GROUP for a mode or code called NAME and return its numerical
+    identifier.  INFILE is the file that contained NAME.  */
+ 
+ static int
+ find_macro (struct macro_group *group, const char *name, FILE *infile)
+ {
+   struct mapping *m;
+ 
+   m = (struct mapping *) htab_find (group->macros, &name);
+   if (m != 0)
+     return m->index + group->num_builtins;
+   return group->find_builtin (name, infile);
+ }
+ 
+ /* Finish reading a declaration of the form:
+ 
+        (define... <name> [<value1> ... <valuen>])
+ 
+    from INFILE, where each <valuei> is either a bare symbol name or a
+    "(<name> <string>)" pair.  The "(define..." part has already been read.
+ 
+    Represent the declaration as a "mapping" structure; add it to TABLE
+    (which belongs to GROUP) and return it.  */
+ 
+ static struct mapping *
+ read_mapping (struct macro_group *group, htab_t table, FILE *infile)
+ {
+   char tmp_char[256];
+   struct mapping *m;
+   struct map_value **end_ptr;
+   const char *string;
+   int number, c;
+ 
+   /* Read the mapping name and create a structure for it.  */
+   read_name (tmp_char, infile);
+   m = add_mapping (group, table, tmp_char, infile);
+ 
+   c = read_skip_spaces (infile);
+   if (c != '[')
+     fatal_expected_char (infile, '[', c);
+ 
+   /* Read each value.  */
+   end_ptr = &m->values;
+   c = read_skip_spaces (infile);
+   do
+     {
+       if (c != '(')
+ 	{
+ 	  /* A bare symbol name that is implicitly paired to an
+ 	     empty string.  */
+ 	  ungetc (c, infile);
+ 	  read_name (tmp_char, infile);
+ 	  string = "";
+ 	}
+       else
+ 	{
+ 	  /* A "(name string)" pair.  */
+ 	  read_name (tmp_char, infile);
+ 	  string = read_string (infile, false);
+ 	  c = read_skip_spaces (infile);
+ 	  if (c != ')')
+ 	    fatal_expected_char (infile, ')', c);
+ 	}
+       number = group->find_builtin (tmp_char, infile);
+       end_ptr = add_map_value (end_ptr, number, string);
+       c = read_skip_spaces (infile);
+     }
+   while (c != ']');
+ 
+   c = read_skip_spaces (infile);
+   if (c != ')')
+     fatal_expected_char (infile, ')', c);
+ 
+   return m;
+ }
+ 
+ /* Check newly-created code macro MACRO to see whether every code has the
+    same format.  Initialize the macro's entry in bellwether_codes.  */
+ 
+ static void
+ check_code_macro (struct mapping *macro, FILE *infile)
+ {
+   struct map_value *v;
+   enum rtx_code bellwether;
+ 
+   bellwether = macro->values->number;
+   for (v = macro->values->next; v != 0; v = v->next)
+     if (strcmp (GET_RTX_FORMAT (bellwether), GET_RTX_FORMAT (v->number)) != 0)
+       fatal_with_file_and_line (infile, "code macro `%s' combines "
+ 				"different rtx formats", macro->name);
+ 
+   bellwether_codes = XRESIZEVEC (enum rtx_code, bellwether_codes,
+ 				 macro->index + 1);
+   bellwether_codes[macro->index] = bellwether;
+ }
+ 
  /* Read an rtx in printed representation from INFILE
     and return an actual rtx in core constructed accordingly.
     read_rtx is not used in the compiler proper, but rather in
*************** validate_const_int (FILE *infile, const 
*** 512,519 ****
  rtx
  read_rtx (FILE *infile)
  {
!   int i, j;
!   RTX_CODE tmp_code;
    const char *format_ptr;
    /* tmp_char is a buffer used for reading decimal integers
       and names of rtx types and machine modes.
--- 1074,1114 ----
  rtx
  read_rtx (FILE *infile)
  {
!   static rtx queue_head, queue_next;
!   rtx return_rtx;
! 
!   /* Do one-time initialization.  */
!   if (queue_head == 0)
!     {
!       initialize_macros ();
!       queue_head = rtx_alloc (EXPR_LIST);
!     }
! 
!   if (queue_next == 0)
!     {
!       queue_next = queue_head;
! 
!       XEXP (queue_next, 0) = read_rtx_1 (infile);
!       XEXP (queue_next, 1) = 0;
! 
!       htab_traverse (modes.macros, apply_macro_traverse, queue_next);
!       htab_traverse (codes.macros, apply_macro_traverse, queue_next);
!     }
! 
!   return_rtx = XEXP (queue_next, 0);
!   queue_next = XEXP (queue_next, 1);
! 
!   return return_rtx;
! }
! 
! /* Subroutine of read_rtx that reads one construct from INFILE but
!    doesn't apply any macros.  */
! 
! static rtx
! read_rtx_1 (FILE *infile)
! {
!   int i;
!   RTX_CODE real_code, bellwether_code;
    const char *format_ptr;
    /* tmp_char is a buffer used for reading decimal integers
       and names of rtx types and machine modes.
*************** read_rtx (FILE *infile)
*** 524,530 ****
    int tmp_int;
    HOST_WIDE_INT tmp_wide;
  
-   /* Obstack used for allocating RTL objects.  */
    static int initialized;
  
    /* Linked list structure for making RTXs: */
--- 1119,1124 ----
*************** read_rtx (FILE *infile)
*** 540,571 ****
        initialized = 1;
      }
  
! again:
    c = read_skip_spaces (infile); /* Should be open paren.  */
    if (c != '(')
      fatal_expected_char (infile, '(', c);
  
    read_name (tmp_char, infile);
! 
!   tmp_code = UNKNOWN;
! 
!   if (! strcmp (tmp_char, "define_constants"))
      {
        read_constants (infile, tmp_char);
        goto again;
      }
!   for (i = 0; i < NUM_RTX_CODE; i++)
!     if (! strcmp (tmp_char, GET_RTX_NAME (i)))
!       {
! 	tmp_code = (RTX_CODE) i;	/* get value for name */
! 	break;
!       }
! 
!   if (tmp_code == UNKNOWN)
!     fatal_with_file_and_line (infile, "unknown rtx code `%s'", tmp_char);
  
    /* (NIL) stands for an expression that isn't there.  */
!   if (tmp_code == NIL)
      {
        /* Discard the closeparen.  */
        while ((c = getc (infile)) && c != ')')
--- 1134,1175 ----
        initialized = 1;
      }
  
!  again:
    c = read_skip_spaces (infile); /* Should be open paren.  */
    if (c != '(')
      fatal_expected_char (infile, '(', c);
  
    read_name (tmp_char, infile);
!   if (strcmp (tmp_char, "define_constants") == 0)
      {
        read_constants (infile, tmp_char);
        goto again;
      }
!   if (strcmp (tmp_char, "define_mode_attr") == 0)
!     {
!       read_mapping (&modes, modes.attrs, infile);
!       goto again;
!     }
!   if (strcmp (tmp_char, "define_mode_macro") == 0)
!     {
!       read_mapping (&modes, modes.macros, infile);
!       goto again;
!     }
!   if (strcmp (tmp_char, "define_code_attr") == 0)
!     {
!       read_mapping (&codes, codes.attrs, infile);
!       goto again;
!     }
!   if (strcmp (tmp_char, "define_code_macro") == 0)
!     {
!       check_code_macro (read_mapping (&codes, codes.macros, infile), infile);
!       goto again;
!     }
!   real_code = find_macro (&codes, tmp_char, infile);
!   bellwether_code = BELLWETHER_CODE (real_code);
  
    /* (NIL) stands for an expression that isn't there.  */
!   if (real_code == NIL)
      {
        /* Discard the closeparen.  */
        while ((c = getc (infile)) && c != ')')
*************** again:
*** 575,582 ****
      }
  
    /* If we end up with an insn expression then we free this space below.  */
!   return_rtx = rtx_alloc (tmp_code);
!   format_ptr = GET_RTX_FORMAT (GET_CODE (return_rtx));
  
    /* If what follows is `: mode ', read it and
       store the mode in the rtx.  */
--- 1179,1187 ----
      }
  
    /* If we end up with an insn expression then we free this space below.  */
!   return_rtx = rtx_alloc (bellwether_code);
!   format_ptr = GET_RTX_FORMAT (bellwether_code);
!   PUT_CODE (return_rtx, real_code);
  
    /* If what follows is `: mode ', read it and
       store the mode in the rtx.  */
*************** again:
*** 585,598 ****
    if (i == ':')
      {
        read_name (tmp_char, infile);
!       for (j = 0; j < NUM_MACHINE_MODES; j++)
! 	if (! strcmp (GET_MODE_NAME (j), tmp_char))
! 	  break;
! 
!       if (j == MAX_MACHINE_MODE)
! 	fatal_with_file_and_line (infile, "unknown mode `%s'", tmp_char);
! 
!       PUT_MODE (return_rtx, (enum machine_mode) j);
      }
    else
      ungetc (i, infile);
--- 1190,1196 ----
    if (i == ':')
      {
        read_name (tmp_char, infile);
!       PUT_MODE (return_rtx, find_macro (&modes, tmp_char, infile));
      }
    else
      ungetc (i, infile);
*************** again:
*** 607,613 ****
  
        case 'e':
        case 'u':
! 	XEXP (return_rtx, i) = read_rtx (infile);
  	break;
  
        case 'V':
--- 1205,1211 ----
  
        case 'e':
        case 'u':
! 	XEXP (return_rtx, i) = read_rtx_1 (infile);
  	break;
  
        case 'V':
*************** again:
*** 639,645 ****
  	    {
  	      ungetc (c, infile);
  	      list_counter++;
! 	      obstack_ptr_grow (&vector_stack, read_rtx (infile));
  	    }
  	  if (list_counter > 0)
  	    {
--- 1237,1243 ----
  	    {
  	      ungetc (c, infile);
  	      list_counter++;
! 	      obstack_ptr_grow (&vector_stack, read_rtx_1 (infile));
  	    }
  	  if (list_counter > 0)
  	    {
Index: doc/md.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/md.texi,v
retrieving revision 1.106
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.106 md.texi
*** doc/md.texi	20 Jul 2004 07:27:17 -0000	1.106
--- doc/md.texi	7 Aug 2004 16:53:32 -0000
*************** See the next chapter for information on 
*** 45,50 ****
--- 45,51 ----
                             predication.
  * Constant Definitions::Defining symbolic constants that can be used in the
                          md file.
+ * Macros::              Using macros to generate patterns from a template.
  @end menu
  
  @node Overview
*************** (define_insn ""
*** 6109,6111 ****
--- 6110,6381 ----
  The constants that are defined with a define_constant are also output
  in the insn-codes.h header file as #defines.
  @end ifset
+ @ifset INTERNALS
+ @node Macros
+ @section Macros
+ @cindex macros in @file{.md} files
+ 
+ Ports often need to define similar patterns for more than one machine
+ mode or for more than one rtx code.  GCC provides some simple macro
+ facilities to make this process easier.
+ 
+ @menu
+ * Mode Macros::         Generating variations of patterns for different modes.
+ * Code Macros::         Doing the same for codes.
+ @end menu
+ 
+ @node Mode Macros
+ @subsection Mode Macros
+ @cindex mode macros in @file{.md} files
+ 
+ Ports often need to define similar patterns for two or more different modes.
+ For example:
+ 
+ @itemize @bullet
+ @item
+ If a processor has hardware support for both single and double
+ floating-point arithmetic, the @code{SFmode} patterns tend to be
+ very similar to the @code{DFmode} ones.
+ 
+ @item
+ If a port uses @code{SImode} pointers in one configuration and
+ @code{DImode} pointers in another, it will usually have very similar
+ @code{SImode} and @code{DImode} patterns for manipulating pointers.
+ @end itemize
+ 
+ Mode macros allow several patterns to be instantiated from one
+ @file{.md} file template.  They can be used with any type of
+ rtx-based construct, such as a @code{define_insn},
+ @code{define_split}, or @code{define_peephole2}.
+ 
+ @menu
+ * Defining Mode Macros:: Defining a new mode macro.
+ * String Substitutions:: Combining mode macros with string substitutions
+ * Examples::             Examples
+ @end menu
+ 
+ @node Defining Mode Macros
+ @subsubsection Defining Mode Macros
+ @findex define_mode_macro
+ 
+ The syntax for defining a mode macro is:
+ 
+ @smallexample
+ (define_mode_macro @var{name} [(@var{mode1} "@var{cond1}") ... (@var{moden} "@var{condn}")])
+ @end smallexample
+ 
+ This allows subsequent @file{.md} file constructs to use the mode suffix
+ @code{:@var{name}}.  Every construct that does so will be expanded
+ @var{n} times, once with every use of @code{:@var{name}} replaced by
+ @code{:@var{mode1}}, once with every use replaced by @code{:@var{mode2}},
+ and so on.  In the expansion for a particular @var{modei}, every
+ C condition will also require that @var{condi} be true.
+ 
+ For example:
+ 
+ @smallexample
+ (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+ @end smallexample
+ 
+ defines a new mode suffix @code{:P}.  Every construct that uses
+ @code{:P} will be expanded twice, once with every @code{:P} replaced
+ by @code{:SI} and once with every @code{:P} replaced by @code{:DI}.
+ The @code{:SI} version will only apply if @code{Pmode == SImode} and
+ the @code{:DI} version will only apply if @code{Pmode == DImode}.
+ 
+ As with other @file{.md} conditions, an empty string is treated
+ as ``always true''.  @code{(@var{mode} "")} can also be abbreviated
+ to @code{@var{mode}}.  For example:
+ 
+ @smallexample
+ (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
+ @end smallexample
+ 
+ means that the @code{:DI} expansion only applies if @code{TARGET_64BIT}
+ but that the @code{:SI} expansion has no such constraint.
+ 
+ Macros are applied in the order they are defined.  This can be
+ significant if two macros are used in a construct that requires
+ string substitutions.  @xref{String Substitutions}.
+ 
+ @node String Substitutions
+ @subsubsection String Substitution in Mode Macros
+ @findex define_mode_attr
+ 
+ If an @file{.md} file construct uses mode macros, each version of the
+ construct will often need slightly different strings.  For example:
+ 
+ @itemize @bullet
+ @item
+ When a @code{define_expand} defines several @code{add@var{m}3} patterns
+ (@pxref{Standard Names}), each expander will need to use the
+ appropriate mode name for @var{m}.
+ 
+ @item
+ When a @code{define_insn} defines several instruction patterns,
+ each instruction will often use a different assembler mnemonic.
+ @end itemize
+ 
+ GCC supports such variations through a system of ``mode attributes''.
+ There are two standard attributes: @code{mode}, which is the name of
+ the mode in lower case, and @code{MODE}, which is the same thing in
+ upper case.  You can define other attributes using:
+ 
+ @smallexample
+ (define_mode_attr @var{name} [(@var{mode1} "@var{value1}") ... (@var{moden} "@var{valuen}")])
+ @end smallexample
+ 
+ where @var{name} is the name of the attribute and @var{valuei}
+ is the value associated with @var{modei}.
+ 
+ When GCC replaces some @var{:macro} with @var{:mode}, it will
+ scan each string in the pattern for sequences of the form
+ @code{<@var{macro}:@var{attr}>}, where @var{attr} is the name of
+ a mode attribute.  If the attribute is defined for @var{mode}, the
+ whole @code{<...>} sequence will be replaced by the appropriate
+ attribute value.
+ 
+ For example, suppose an @file{.md} file has:
+ 
+ @smallexample
+ (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+ (define_mode_attr load [(SI "lw") (DI "ld")])
+ @end smallexample
+ 
+ If one of the patterns that uses @code{:P} contains the string
+ @code{"<P:load>\t%0,%1"}, the @code{SI} version of that pattern
+ will use @code{"lw\t%0,%1"} and the @code{DI} version will use
+ @code{"ld\t%0,%1"}.
+ 
+ The @code{@var{macro}:} prefix may be omitted, in which case the
+ substitution will be attempted for every macro expansion.
+ 
+ @node Examples
+ @subsubsection Mode Macro Examples
+ 
+ Here is an example from the MIPS port.  It defines the following
+ modes and attributes (among others):
+ 
+ @smallexample
+ (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
+ (define_mode_attr d [(SI "") (DI "d")])
+ @end smallexample
+ 
+ and uses the following template to define both @code{subsi3}
+ and @code{subdi3}:
+ 
+ @smallexample
+ (define_insn "sub<mode>3"
+   [(set (match_operand:GPR 0 "register_operand" "=d")
+         (minus:GPR (match_operand:GPR 1 "register_operand" "d")
+                    (match_operand:GPR 2 "register_operand" "d")))]
+   ""
+   "<d>subu\t%0,%1,%2"
+   [(set_attr "type" "arith")
+    (set_attr "mode" "<MODE>")])
+ @end smallexample
+ 
+ This is exactly equivalent to:
+ 
+ @smallexample
+ (define_insn "subsi3"
+   [(set (match_operand:SI 0 "register_operand" "=d")
+         (minus:SI (match_operand:SI 1 "register_operand" "d")
+                   (match_operand:SI 2 "register_operand" "d")))]
+   ""
+   "subu\t%0,%1,%2"
+   [(set_attr "type" "arith")
+    (set_attr "mode" "SI")])
+ 
+ (define_insn "subdi3"
+   [(set (match_operand:DI 0 "register_operand" "=d")
+         (minus:DI (match_operand:DI 1 "register_operand" "d")
+                   (match_operand:DI 2 "register_operand" "d")))]
+   ""
+   "dsubu\t%0,%1,%2"
+   [(set_attr "type" "arith")
+    (set_attr "mode" "DI")])
+ @end smallexample
+ 
+ @node Code Macros
+ @subsection Code Macros
+ @cindex code macros in @file{.md} files
+ @findex define_code_macro
+ @findex define_code_attr
+ 
+ Code macros operate in a similar way to mode macros.  @xref{Mode Macros}.
+ 
+ The construct:
+ 
+ @smallexample
+ (define_code_macro @var{name} [(@var{code1} "@var{cond1}") ... (@var{coden} "@var{condn}")])
+ @end smallexample
+ 
+ defines a pseudo rtx code @var{name} that can be instantiated as
+ @var{codei} if condition @var{condi} is true.  Each @var{codei}
+ must have the same rtx format.  @xref{RTL Classes}.
+ 
+ As with mode macros, each pattern that uses @var{name} will be
+ expanded @var{n} times, once with all uses of @var{name} replaced by
+ @var{code1}, once with all uses replaced by @var{code2}, and so on.
+ @xref{Defining Mode Macros}.
+ 
+ It is possible to define attributes for codes as well as for modes.
+ There are two standard code attributes: @code{code}, the name of the
+ code in lower case, and @code{CODE}, the name of the code in upper case.
+ Other attributes are defined using:
+ 
+ @smallexample
+ (define_code_attr @var{name} [(@var{code1} "@var{value1}") ... (@var{coden} "@var{valuen}")])
+ @end smallexample
+ 
+ Here's an example of code macros in action, taken from the MIPS port:
+ 
+ @smallexample
+ (define_code_macro anycond [unordered ordered unlt unge uneq ltgt unle ungt
+                             eq ne gt ge lt le gtu geu ltu leu])
+ 
+ (define_expand "b<code>"
+   [(set (pc)
+         (if_then_else (anycond:CC (cc0)
+                                   (const_int 0))
+                       (label_ref (match_operand 0 ""))
+                       (pc)))]
+   ""
+ {
+   gen_conditional_branch (operands, <CODE>);
+   DONE;
+ })
+ @end smallexample
+ 
+ This is equivalent to:
+ 
+ @smallexample
+ (define_expand "bunordered"
+   [(set (pc)
+         (if_then_else (unordered:CC (cc0)
+                                     (const_int 0))
+                       (label_ref (match_operand 0 ""))
+                       (pc)))]
+   ""
+ {
+   gen_conditional_branch (operands, UNORDERED);
+   DONE;
+ })
+ 
+ (define_expand "bordered"
+   [(set (pc)
+         (if_then_else (ordered:CC (cc0)
+                                   (const_int 0))
+                       (label_ref (match_operand 0 ""))
+                       (pc)))]
+   ""
+ {
+   gen_conditional_branch (operands, ORDERED);
+   DONE;
+ })
+ 
+ ...
+ @end smallexample
+ 
+ @end ifset

[-- Attachment #5: macro-mips.diff.bz2 --]
[-- Type: application/octet-stream, Size: 12648 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-07 18:38 RFC: Using mode and code macros in *.md files Richard Sandiford
@ 2004-08-08  4:30 ` James E Wilson
  2004-08-08  8:43   ` Richard Sandiford
  2004-08-09  9:02   ` Michael Matz
  2004-08-10  8:57 ` Segher Boessenkool
  2004-08-23 10:32 ` Zack Weinberg
  2 siblings, 2 replies; 17+ messages in thread
From: James E Wilson @ 2004-08-08  4:30 UTC (permalink / raw)
  To: Richard Sandiford; +Cc: gcc

Richard Sandiford wrote:
> This is an RFC about using mode and code macros in *.md files.
> I've attached a patch that implements the suggested constructs
> and an example of how they might be used in mips.md.

Some interesting stuff.

My first question would be how this affects debugging gcc.  Being able 
to match rtl insns to the md pattern for them is important.  These 
macros obscure the connection.  If I have a insn that has been 
recognized, and claims to match the slesi pattern, then I will be 
confused if I can't find such a pattern.  How am I supposed to know to 
look for the s<floatcond><mode> pattern instead?  The port maintainer 
would know this, but someone else wouldn't.  Maybe it would help to 
print md file line numbers instead of or in addition to pattern names 
when dumping rtl.

If I have an insn that hasn't been recognized, then I have a similar but 
slightly different problem.  If I try grepping for the operator (le:SI I 
am not going to find it.  How I am supposed to know to search for 
(<floatcond>:<mode> instead?

This stuff will probably work itself out eventually.  People will get 
used to the new syntax and learn to look for macros.

> For example, code macros allow us to combine 7 of the c.cond.fmt patterns:

You can already do this via match_operator.  Just define a predicate 
that accepts the 7 comparison codes you care about, and you can write a 
single pattern to patch all 7.  This gives a somewhat different affect 
though, as your macro approach gives 7 patterns whereas we only have one 
pattern if we use match_operator.

Match_operator has some of the same issues with respect to debugging. 
Once you use match_operator, it gets harder to find the pattern, as a 
simple grep for the operation code won't find the pattern that matches 
it.  Your proposal seems a little friendlier, since at least the macro 
definition is in the md file, whereas the match_operator predicate has 
to be in the .c file.

We should consider whether we need or want two different mechanisms that 
do the same thing.

If we don't need match_operator, then we also don't need match_op_dup.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-08  4:30 ` James E Wilson
@ 2004-08-08  8:43   ` Richard Sandiford
  2004-08-09 18:29     ` James E Wilson
  2004-08-09  9:02   ` Michael Matz
  1 sibling, 1 reply; 17+ messages in thread
From: Richard Sandiford @ 2004-08-08  8:43 UTC (permalink / raw)
  To: James E Wilson; +Cc: gcc

Thanks for the feedback.

James E Wilson <wilson@specifixinc.com> writes:
> My first question would be how this affects debugging gcc.  Being able
> to match rtl insns to the md pattern for them is important.  These
> macros obscure the connection.  If I have a insn that has been
> recognized, and claims to match the slesi pattern, then I will be
> confused if I can't find such a pattern.  How am I supposed to know to
> look for the s<floatcond><mode> pattern instead?  The port maintainer
> would know this, but someone else wouldn't.  Maybe it would help to
> print md file line numbers instead of or in addition to pattern names
> when dumping rtl.

Sound like a good idea.

> If I have an insn that hasn't been recognized, then I have a similar but
> slightly different problem.  If I try grepping for the operator (le:SI I
> am not going to find it.  How I am supposed to know to search for
> (<floatcond>:<mode> instead?

I can see that could be a problem.  I guess it depends on the habits
of the coder.

FWIW, I tend to use '\ble\b' (within emacs) when searching for an
operator name, and the first hit for that would be the macro definition.
(I mostly use '\b' because I can never remember which re syntaxes use
'(' as a grouping operator and which use '\(').

>> For example, code macros allow us to combine 7 of the c.cond.fmt patterns:
>
> You can already do this via match_operator.  Just define a predicate
> that accepts the 7 comparison codes you care about, and you can write a
> single pattern to patch all 7.  This gives a somewhat different affect
> though, as your macro approach gives 7 patterns whereas we only have one
> pattern if we use match_operator.

For matching, yes, but the point is that these are named patterns.
OK, so at the moment, only gen_slt_sf() is actually used (by one
of the reload patterns), but match_operator gives a less friendly
gen_*() interface.  If you have:

    (set (match_operand:SF 0 "register_operand" "=f")
         (match_operator:SF 1 "float_cmp_operator"
            [(match_operand:SF 2 "register_operand" "f")
             (match_operand:SF 2 "register_operand" "f")]))

then the gen_*() function will have four arguments.  From memory,
arguments 2 and 3 are ignored, and you need to pass gen_rtx_LT (...)
for argument 1.

In practice, we'd probably end up adding a new expander specifically for
"slt_sf", or perhaps just synthesising it directly using gen_rtx_*()
functions.

> We should consider whether we need or want two different mechanisms that
> do the same thing.

Well, match_operator is a bit more general, in that it can (if necessary)
match codes with different formats.  I don't know how important that is
in practice.

Richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-08  4:30 ` James E Wilson
  2004-08-08  8:43   ` Richard Sandiford
@ 2004-08-09  9:02   ` Michael Matz
  2004-08-09 18:09     ` James E Wilson
  1 sibling, 1 reply; 17+ messages in thread
From: Michael Matz @ 2004-08-09  9:02 UTC (permalink / raw)
  To: James E Wilson; +Cc: Richard Sandiford, gcc

Hi,

On Sat, 7 Aug 2004, James E Wilson wrote:

> My first question would be how this affects debugging gcc.  Being able to
> match rtl insns to the md pattern for them is important.  These macros obscure
> the connection.
...
> If I have an insn that hasn't been recognized, then I have a similar but
> slightly different problem.

Perhaps such problems could be solved by emitting a "preprocessed" .md
file (where every such macro is explicitely expanded) when gcc is not
configured with --disable-checking, or with a special option or even in 
every case?


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-09  9:02   ` Michael Matz
@ 2004-08-09 18:09     ` James E Wilson
  0 siblings, 0 replies; 17+ messages in thread
From: James E Wilson @ 2004-08-09 18:09 UTC (permalink / raw)
  To: Michael Matz; +Cc: Richard Sandiford, gcc

Michael Matz wrote:
> Perhaps such problems could be solved by emitting a "preprocessed" .md
> file

Yes, that is a good idea.  Another idea that occured to me over the 
weekend is to have a debugging recog.  It would be nice if recog could 
tell us what it was doing.

Trying to match reg:SI for insns 177, 178, 179, 224, 225
Success.
Trying to match eq:SI for insn 177
Failure.
Trying to match ne:SI for insn 178
Success.

That would make it easier to find some kinds of bugs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-08  8:43   ` Richard Sandiford
@ 2004-08-09 18:29     ` James E Wilson
  0 siblings, 0 replies; 17+ messages in thread
From: James E Wilson @ 2004-08-09 18:29 UTC (permalink / raw)
  To: Richard Sandiford; +Cc: gcc

Richard Sandiford wrote:
> For matching, yes, but the point is that these are named patterns.

That is a good point.  You can't use match_operator for a standard named 
pattern like addsi3, but you can use your macros.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-07 18:38 RFC: Using mode and code macros in *.md files Richard Sandiford
  2004-08-08  4:30 ` James E Wilson
@ 2004-08-10  8:57 ` Segher Boessenkool
  2004-08-23 10:32 ` Zack Weinberg
  2 siblings, 0 replies; 17+ messages in thread
From: Segher Boessenkool @ 2004-08-10  8:57 UTC (permalink / raw)
  To: Richard Sandiford; +Cc: gcc

>       It would be nice to be able to write:
>
>         (set (pc) (match_operand:P 0 "register_operand" "d"))
>
>       instead.

Indeed!

Don't know about the other stuff.


Segher

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-07 18:38 RFC: Using mode and code macros in *.md files Richard Sandiford
  2004-08-08  4:30 ` James E Wilson
  2004-08-10  8:57 ` Segher Boessenkool
@ 2004-08-23 10:32 ` Zack Weinberg
  2004-08-26 21:08   ` Richard Sandiford
  2 siblings, 1 reply; 17+ messages in thread
From: Zack Weinberg @ 2004-08-23 10:32 UTC (permalink / raw)
  To: Richard Sandiford; +Cc: gcc

Richard Sandiford <rsandifo@redhat.com> writes:

> This is an RFC about using mode and code macros in *.md files.
> I've attached a patch that implements the suggested constructs
> and an example of how they might be used in mips.md.

This is rather belated, but I'd like to throw in a few comments.  In
general I really like this, it looks like it's got potential to make
it much easier to write machine descriptions.  I've got some
suggestions, though, which which I think can be implemented as
incremental improvements to the patch you've already got.

First thing is, Pmode is a bit of a special case.  For one thing,
we've got a "pmode_register_operand" predicate which does exactly what
you want for *this* use of Pmode.  You could write

        (define_insn "indirect_jump_internal"
          [(set (pc) (match_operand 0 "pmode_register_operand" "d"))]
          ""
          "%*j\t%0%/"
          [(set_attr "type" "jump")
           (set_attr "mode" "none")])

However, this doesn't help with any other place where one would like
to use a :P mode suffix.  And I agree that :P should work.

The other way Pmode is special is that it's already defined by every
target, and it would be nice if every target didn't have to re-specify
it with a mode macro in order to get it to work in the machine
description.  When Pmode is a compile-time constant, in fact, you
ought to get the same code out of gen* that you would if you
search-and-replaced every :P in the machine description with the
underlying mode.

When it's not a compile-time constant the question becomes more
difficult, but I think it's still doable; one has to think carefully
about the code that genrecog would have to emit, but the rest of the
generated code doesn't change much.

The other thing I wonder about is extension to places where the
pattern varies, not just the strings.  For instance, consider the
floating point patterns in ia64.md.  Notionally, every DFmode pattern
is multiplied fourfold, like so:

(define_insn "adddf3"
  [(set (match_operand:DF 0 "fr_register_operand" "=f")
        (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                 (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))]
  ""
  "fadd.d %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_alts"
  [(set (match_operand:DF 0 "fr_register_operand" "=f")
        (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                 (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))
   (use (match_operand:SI 3 "const_int_operand" ""))]
  ""
  "fadd.d.s%4 %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_trunc"
  [(set (match_operand:SF 0 "fr_register_operand" "=f")
        (float_truncate:SF
          (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                   (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))]
  ""
  "fadd.s %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_trunc_alts"
  [(set (match_operand:SF 0 "fr_register_operand" "=f")
        (float_truncate:SF
          (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                   (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))
   (use (match_operand:SI 3 "const_int_operand" ""))]
  ""
  "fadd.s.s%4 %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

You won't actually find these "_alts" patterns in ia64.md, because
they haven't been added consistently, but you will find the "_trunc"
variant.  Now, this was definitely out of scope of your original
patch, and (since the extra patterns are for matching only) it might
be feasible to use match_operator for them.  In fact, that's on my
list of things to try in the near future.  But if I do do it with
match_operator, the result may not be all that readable, and the code
one has to write for a nontrivial match_operator predicate isn't
exactly nice, either.  So I'm curious if you have any ideas for how to
handle this sort of thing.

zw

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-23 10:32 ` Zack Weinberg
@ 2004-08-26 21:08   ` Richard Sandiford
  2004-08-31 18:19     ` Steve Ellcey
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Sandiford @ 2004-08-26 21:08 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: gcc

Zack Weinberg <zack@codesourcery.com> writes:
> First thing is, Pmode is a bit of a special case.  For one thing,
> we've got a "pmode_register_operand" predicate which does exactly what
> you want for *this* use of Pmode.  You could write
>
>         (define_insn "indirect_jump_internal"
>           [(set (pc) (match_operand 0 "pmode_register_operand" "d"))]
>           ""
>           "%*j\t%0%/"
>           [(set_attr "type" "jump")
>            (set_attr "mode" "none")])
>
> However, this doesn't help with any other place where one would like
> to use a :P mode suffix.  And I agree that :P should work.
>
> The other way Pmode is special is that it's already defined by every
> target, and it would be nice if every target didn't have to re-specify
> it with a mode macro in order to get it to work in the machine
> description.  When Pmode is a compile-time constant, in fact, you
> ought to get the same code out of gen* that you would if you
> search-and-replaced every :P in the machine description with the
> underlying mode.

With the current implementation, it would be fairly easy to define Pmode
(and ptr_mode and word_mode?) in the *.md file and get the gen* programs
to generate the #define automatically.  There would just need to be new
constructs specifically for "one of" (as opposed to "any of") macros.
However...

> When it's not a compile-time constant the question becomes more
> difficult, but I think it's still doable; one has to think carefully
> about the code that genrecog would have to emit, but the rest of the
> generated code doesn't change much.

...it sounds like you're thinking about _generating_ single Pmode
patterns, even when the target has more than one pointer mode.
Is that right?

I did wonder about that, but it decided it would be a lot of work.
It would mean auditing all uses of insn_data[] (including reload, yikes!)
so that operand[].modes of Pmode are converted to the appropriate "real"
mode in time.  I guess one way would be to define new accessor functions
for insn_data[] and make the mode accessor do the conversion.

It would also mean auditing most uses of modes in the gen* programs.
As you say, things like genrecog would have to be changed so that the
optimiser no longer says "is this the same mode as that?" but rather
"do these two modes overlap?".

I still agree this is a good idea though.

> The other thing I wonder about is extension to places where the
> pattern varies, not just the strings.  For instance, consider the
> floating point patterns in ia64.md.  Notionally, every DFmode pattern
> is multiplied fourfold, like so:
>
> (define_insn "adddf3"
>   [(set (match_operand:DF 0 "fr_register_operand" "=f")
>         (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
>                  (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))]
>   ""
>   "fadd.d %0 = %1, %F2"
>   [(set_attr "itanium_class" "fmac")])
>
> (define_insn "*adddf3_alts"
>   [(set (match_operand:DF 0 "fr_register_operand" "=f")
>         (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
>                  (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))
>    (use (match_operand:SI 3 "const_int_operand" ""))]
>   ""
>   "fadd.d.s%4 %0 = %1, %F2"
>   [(set_attr "itanium_class" "fmac")])
>
> (define_insn "*adddf3_trunc"
>   [(set (match_operand:SF 0 "fr_register_operand" "=f")
>         (float_truncate:SF
>           (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
>                    (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))]
>   ""
>   "fadd.s %0 = %1, %F2"
>   [(set_attr "itanium_class" "fmac")])
>
> (define_insn "*adddf3_trunc_alts"
>   [(set (match_operand:SF 0 "fr_register_operand" "=f")
>         (float_truncate:SF
>           (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
>                    (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))
>    (use (match_operand:SI 3 "const_int_operand" ""))]
>   ""
>   "fadd.s.s%4 %0 = %1, %F2"
>   [(set_attr "itanium_class" "fmac")])
>
> You won't actually find these "_alts" patterns in ia64.md, because
> they haven't been added consistently, but you will find the "_trunc"
> variant.  Now, this was definitely out of scope of your original
> patch, and (since the extra patterns are for matching only) it might
> be feasible to use match_operator for them.  In fact, that's on my
> list of things to try in the near future.  But if I do do it with
> match_operator, the result may not be all that readable, and the code
> one has to write for a nontrivial match_operator predicate isn't
> exactly nice, either.  So I'm curious if you have any ideas for how to
> handle this sort of thing.

Couldn't you use code macros to cover all the binary operations in
one go?  I.e. have one pattern that implements all the binary *_alts,
one that implements all the binary *_truncs, etc.  Something like:

(define_code_macro float_operator [plus ...])
(define_code_attr insn [(plus "fadd") ...])
(define_code_attr class [(plus "fmac") ...])

...

(define_insn "*<code>df3_alts"
  [(set (match_operand:DF 0 "fr_register_operand" "=f")
        (float_operator:DF (match_operand:DF 1 "fr_register_operand" "%f")
                           (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))
   (use (match_operand:SI 3 "const_int_operand" ""))]
  ""
  "<insn>.d.s%4 %0 = %1, %F2"
  [(set_attr "itanium_class" "<class>")])

...

Or are the instructions not regular enough for that?

[ Although, even if they are, code like the above probably isn't going
  to be to everyone's taste.  I have started using it in the MIPS port
  though. ;)  See yesterday's shift macroisation patch for a more
  concrete example. ]

BTW, as a general comment, not really in reply to the above:  I'm not
very good at coming up with new syntax.  The macro stuff was very much
a case of "I want to specify these patterns from the same template"
rather than "I want to write the template with this syntax".  If
anyone has any ideas for making templates like the above more
readable, please shout ;)

Richard

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-26 21:08   ` Richard Sandiford
@ 2004-08-31 18:19     ` Steve Ellcey
  2004-08-31 18:37       ` Richard Sandiford
  0 siblings, 1 reply; 17+ messages in thread
From: Steve Ellcey @ 2004-08-31 18:19 UTC (permalink / raw)
  To: gcc; +Cc: rsandifo

I have a question about the mode macros.

On IA64, extending a floating point operand in a register is a noop so
it would be useful to fold that into actual floating point operations.

So if I had something like:

  ;; AF == Any floating point type that can fit in a register.
  (define_mode_macro AF [(SF "") (DF "") (XF "")])

  (define_insn "*addxf3_extend"
    [(set (match_operand:XF 0 "fr_register_operand" "=f")
          (plus:XF (float_extend:XF
                     (match_operand:AF 1 "fr_register_operand" "%f"))
                   (float_extend:XF
                     (match_operand:AF 2 "fr_reg_or_fp01_operand" "fG"))))]
    ""
    "fadd %0 = %1, %F2"
    [(set_attr "itanium_class" "fmac")])

Am I right in assuming that this would allow two SF operands, two DF
operands or two XF operands but would not allow, say, one SF operand and
one DF operand?

Could I work around that by defining AF1 and AF2 with the same
definition as AF and then using AF1 and AF2 in the instruction instead
of using AF twice?

It would be nice if I could fold the version of addxf3 that has no
float_extend's into this definition too but I don't think any macros or
existing mechanism would allow me to do that.

Steve Ellcey
sje@cup.hp.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-31 18:19     ` Steve Ellcey
@ 2004-08-31 18:37       ` Richard Sandiford
  2004-08-31 19:27         ` Joern Rennecke
  2004-08-31 21:04         ` Steve Ellcey
  0 siblings, 2 replies; 17+ messages in thread
From: Richard Sandiford @ 2004-08-31 18:37 UTC (permalink / raw)
  To: Steve Ellcey; +Cc: gcc

Steve Ellcey <sje@cup.hp.com> writes:
> On IA64, extending a floating point operand in a register is a noop so
> it would be useful to fold that into actual floating point operations.
>
> So if I had something like:
>
>   ;; AF == Any floating point type that can fit in a register.
>   (define_mode_macro AF [(SF "") (DF "") (XF "")])
>
>   (define_insn "*addxf3_extend"
>     [(set (match_operand:XF 0 "fr_register_operand" "=f")
>           (plus:XF (float_extend:XF
>                      (match_operand:AF 1 "fr_register_operand" "%f"))
>                    (float_extend:XF
>                      (match_operand:AF 2 "fr_reg_or_fp01_operand" "fG"))))]
>     ""
>     "fadd %0 = %1, %F2"
>     [(set_attr "itanium_class" "fmac")])
>
> Am I right in assuming that this would allow two SF operands, two DF
> operands or two XF operands but would not allow, say, one SF operand and
> one DF operand?

'Fraid so.

> Could I work around that by defining AF1 and AF2 with the same
> definition as AF and then using AF1 and AF2 in the instruction instead
> of using AF twice?

That should certainly do the trick.  (Do you really want to
include XF though?  I'm not sure whether it's OK to have
(float_extend:XF (reg:XF ...)).)

> It would be nice if I could fold the version of addxf3 that has no
> float_extend's into this definition too but I don't think any macros or
> existing mechanism would allow me to do that.

Yeah, I know the feeling ;)  It would be nice to do the same thing
on MIPS with SI->DI sign_extends.

I did have one proposal for that:

   http://gcc.gnu.org/ml/gcc/2004-07/msg01126.html

but it didn't seem to take the world by storm ;)  It also doesn't
help when the extension isn't wrapping a matchd_operator.  I.e. it
wouldn't help to reduce the duplication between:

   (set (match_operand:DI ...)
        (sign_extend:DI (plus:SI (match_operand:SI ...)
                                 (match_operand:SI ...))))

and:

   (set (match_operand:SI ...)
        (plus:SI (match_operand:SI ...)
                 (match_operand:SI ...)))

which are the same thing on MIPS[*].  It would also run into problems
if the constraints allow constants, since you might end up reloading:

    (sign_extend:DI (reg:SI psuedo-equivalent-to-const))

to:

    (sign_extend:DI (const_int ...))

and that would be bad.

It would certainly be nice to have a clean way of dealing with this...

Richard

[*] We could probably handle that using match_operator though.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-31 18:37       ` Richard Sandiford
@ 2004-08-31 19:27         ` Joern Rennecke
  2004-08-31 21:04         ` Steve Ellcey
  1 sibling, 0 replies; 17+ messages in thread
From: Joern Rennecke @ 2004-08-31 19:27 UTC (permalink / raw)
  To: Richard Sandiford; +Cc: Steve Ellcey, gcc

> > It would be nice if I could fold the version of addxf3 that has no
> > float_extend's into this definition too but I don't think any macros or
> > existing mechanism would allow me to do that.
> 
> Yeah, I know the feeling ;)  It would be nice to do the same thing
> on MIPS with SI->DI sign_extends.

I think the only sane way to do this is having the match_operand match the
full size register or a float_extend / sign_extend.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-31 18:37       ` Richard Sandiford
  2004-08-31 19:27         ` Joern Rennecke
@ 2004-08-31 21:04         ` Steve Ellcey
  2004-09-01 12:20           ` Joern Rennecke
  1 sibling, 1 reply; 17+ messages in thread
From: Steve Ellcey @ 2004-08-31 21:04 UTC (permalink / raw)
  To: rsandifo, zack; +Cc: gcc

> That should certainly do the trick.  (Do you really want to
> include XF though?  I'm not sure whether it's OK to have
> (float_extend:XF (reg:XF ...)).)

You are right, I probably don't want to include XF, the unfortunate
aspect of this is that I probably need 6 versions of addxf then, one
version where one operand has a float_extend, one where both operands
are extended, and on where neither are extended.  I would also want each
of those to have a version where the result is truncated after the add
because on IA64 we can do that truncation as part of the single add
instruction.

One thought I had was this:  If there were an IF mode (infinite
precision), and a single basic floating point add for that mode

(set (match_operand:IF ...)
     (plus:IF (match_operand:IF ...)
              (match_operand:IF ...)))

and then there would be no basic add instruction for any other floating
point mode (SF, DF, or XF) then GCC will extend any of those to IFmode
to do the add.  I tested that and GCC did the float_extends.

Then all SF, DF, and XF addition could all be handled with one
macro'ized instruction:

;; AF == Any floating point type that can fit in a register.
(define_mode_macro AF0 [(SF "") (DF "") (XF "")])
(define_mode_macro AF1 [(SF "") (DF "") (XF "")])
(define_mode_macro AF2 [(SF "") (DF "") (XF "")])

(set (match_operand:AF0 0 "fr_register_operand" "=f")
     (float_truncate:AF0
       (plus:IF (float_extend:IF
                  (match_operand:AF1 1 "fr_register_operand" "%f"))
                (float_extend:IF
                  (match_operand:AF2 2 "fr_reg_or_fp01_operand" "fG")))))


Steve Ellcey
sje@cup.hp.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-08-31 21:04         ` Steve Ellcey
@ 2004-09-01 12:20           ` Joern Rennecke
  2004-09-01 18:33             ` Steve Ellcey
  0 siblings, 1 reply; 17+ messages in thread
From: Joern Rennecke @ 2004-09-01 12:20 UTC (permalink / raw)
  To: Steve Ellcey; +Cc: rsandifo, zack, gcc

> One thought I had was this:  If there were an IF mode (infinite
> precision), and a single basic floating point add for that mode
> 
> (set (match_operand:IF ...)
>      (plus:IF (match_operand:IF ...)
>               (match_operand:IF ...)))
> 
> and then there would be no basic add instruction for any other floating
> point mode (SF, DF, or XF) then GCC will extend any of those to IFmode
> to do the add.  I tested that and GCC did the float_extends.

But that would make your instructions non-canonical, thus a number of
optimizers - in particular combine - will fail to match your patterns.

Unless you propose to change the canonical form to use extension to IF
in every operation, which would pretty much mean rewriting most of the
rtl optimizers and all the target ports...

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-09-01 12:20           ` Joern Rennecke
@ 2004-09-01 18:33             ` Steve Ellcey
  2004-09-01 19:00               ` James E Wilson
  2004-09-02 10:37               ` Joern Rennecke
  0 siblings, 2 replies; 17+ messages in thread
From: Steve Ellcey @ 2004-09-01 18:33 UTC (permalink / raw)
  To: joern.rennecke; +Cc: gcc

> > One thought I had was this:  If there were an IF mode (infinite
> > precision), and a single basic floating point add for that mode
> > 
> > (set (match_operand:IF ...)
> >      (plus:IF (match_operand:IF ...)
> >               (match_operand:IF ...)))
> > 
> > and then there would be no basic add instruction for any other floating
> > point mode (SF, DF, or XF) then GCC will extend any of those to IFmode
> > to do the add.  I tested that and GCC did the float_extends.
> 
> But that would make your instructions non-canonical, thus a number of
> optimizers - in particular combine - will fail to match your patterns.
> 
> Unless you propose to change the canonical form to use extension to IF
> in every operation, which would pretty much mean rewriting most of the
> rtl optimizers and all the target ports...

I hadn't thought about that.  I did experiment with this a little by
removing the addsf and adddf instructions from my ia64.md file and
forcing it to use addxf.  I added one new optmization to combine,
removing '(float_extend:XF (float_truncate:SF XF)' type constructs if
flag_unsafe_math_optimizations is set.  This is now generating IA64
combined instructions (like add-mult) the way I want, I'll have to
experiment some more to see if it stops other optimizations.

Hopefully, with optimizations moving up into trees and SSA the RTL
optimizations won't come into play as much.

Steve Ellcey
sje@cup.hp.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-09-01 18:33             ` Steve Ellcey
@ 2004-09-01 19:00               ` James E Wilson
  2004-09-02 10:37               ` Joern Rennecke
  1 sibling, 0 replies; 17+ messages in thread
From: James E Wilson @ 2004-09-01 19:00 UTC (permalink / raw)
  To: Steve Ellcey; +Cc: gcc

Steve Ellcey wrote:
> I hadn't thought about that.  I did experiment with this a little by
> removing the addsf and adddf instructions from my ia64.md file and
> forcing it to use addxf.

You should check the effect on stack loads and stores.  SFmode is a 4 
byte access, DFmode is an 8 byte access, but XFmode is a 16 byte access. 
  If you force stuff to be XFmode, then we may end up with more stack 
accesses and larger stack sizes, which could affect performance.  This 
should only affect intermediate values, and we have plenty of FP 
registers, so this seems unlikely to be a problem, but it would be nice 
to check and make sure.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: RFC: Using mode and code macros in *.md files
  2004-09-01 18:33             ` Steve Ellcey
  2004-09-01 19:00               ` James E Wilson
@ 2004-09-02 10:37               ` Joern Rennecke
  1 sibling, 0 replies; 17+ messages in thread
From: Joern Rennecke @ 2004-09-02 10:37 UTC (permalink / raw)
  To: Steve Ellcey; +Cc: joern.rennecke, gcc

> Hopefully, with optimizations moving up into trees and SSA the RTL
> optimizations won't come into play as much.

The tree optimizers can't give you optimizations that have to do with
instruction selection, since they are mostly agnostic of your target
instruction set.  The tree optimizers can do a good job to do optimizations
on the abstract computations, but the rtl optimizers like combine are
important to map these computations efficiently on your target
instruction set.

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2004-09-02 10:37 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-07 18:38 RFC: Using mode and code macros in *.md files Richard Sandiford
2004-08-08  4:30 ` James E Wilson
2004-08-08  8:43   ` Richard Sandiford
2004-08-09 18:29     ` James E Wilson
2004-08-09  9:02   ` Michael Matz
2004-08-09 18:09     ` James E Wilson
2004-08-10  8:57 ` Segher Boessenkool
2004-08-23 10:32 ` Zack Weinberg
2004-08-26 21:08   ` Richard Sandiford
2004-08-31 18:19     ` Steve Ellcey
2004-08-31 18:37       ` Richard Sandiford
2004-08-31 19:27         ` Joern Rennecke
2004-08-31 21:04         ` Steve Ellcey
2004-09-01 12:20           ` Joern Rennecke
2004-09-01 18:33             ` Steve Ellcey
2004-09-01 19:00               ` James E Wilson
2004-09-02 10:37               ` Joern Rennecke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).