-/* The condition code register is represented, in our imagination,
- as a register holding a value that can be compared to zero.
- In fact, the machine has already compared them and recorded the
- results; but instructions that look at the condition code
- pretend to be looking at the entire value and comparing it. */
-DEF_RTL_EXPR(CC0, "cc0", "", 'o')
-
-/* Reference to the address of a register. Removed by purge_addressof after
- CSE has elided as many as possible.
- 1st operand: the register we may need the address of.
- 2nd operand: the original pseudo regno we were generated for.
- 3rd operand: the decl for the object in the register, for
- put_reg_in_stack. */
-
-DEF_RTL_EXPR(ADDRESSOF, "addressof", "eit", 'o')
-
-/* =====================================================================
- A QUEUED expression really points to a member of the queue of instructions
- to be output later for postincrement/postdecrement.
- QUEUED expressions never become part of instructions.
- When a QUEUED expression would be put into an instruction,
- instead either the incremented variable or a copy of its previous
- value is used.
-
- Operands are:
- 0. the variable to be incremented (a REG rtx).
- 1. the incrementing instruction, or 0 if it hasn't been output yet.
- 2. A REG rtx for a copy of the old value of the variable, or 0 if none yet.
- 3. the body to use for the incrementing instruction
- 4. the next QUEUED expression in the queue.
- ====================================================================== */
-
-DEF_RTL_EXPR(QUEUED, "queued", "eeeee", 'x')
+/* Define how to generate multiple insns for a standard insn name.
+ 1st operand: the insn name.
+ 2nd operand: vector of insn-patterns.
+ Use match_operand to substitute an element of `recog_data.operand'.
+ 3rd operand: C expression that must be true for this to be available.
+ This may not test any operands.
+ 4th operand: Extra C code to execute before generating the insns.
+ This might, for example, create some RTX's and store them in
+ elements of `recog_data.operand' for use by the vector of
+ insn-patterns.
+ (`operands' is an alias here for `recog_data.operand'). */
+DEF_RTL_EXPR(DEFINE_EXPAND, "define_expand", "sEss", RTX_EXTRA)
+
+/* Define a requirement for delay slots.
+ 1st operand: Condition involving insn attributes that, if true,
+ indicates that the insn requires the number of delay slots
+ shown.
+ 2nd operand: Vector whose length is the three times the number of delay
+ slots required.
+ Each entry gives three conditions, each involving attributes.
+ The first must be true for an insn to occupy that delay slot
+ location. The second is true for all insns that can be
+ annulled if the branch is true and the third is true for all
+ insns that can be annulled if the branch is false.
+
+ Multiple DEFINE_DELAYs may be present. They indicate differing
+ requirements for delay slots. */
+DEF_RTL_EXPR(DEFINE_DELAY, "define_delay", "eE", RTX_EXTRA)
+
+/* Define attribute computation for `asm' instructions. */
+DEF_RTL_EXPR(DEFINE_ASM_ATTRIBUTES, "define_asm_attributes", "V", RTX_EXTRA)
+
+/* Definition of a conditional execution meta operation. Automatically
+ generates new instances of DEFINE_INSN, selected by having attribute
+ "predicable" true. The new pattern will contain a COND_EXEC and the
+ predicate at top-level.
+
+ Operand:
+ 0: The predicate pattern. The top-level form should match a
+ relational operator. Operands should have only one alternative.
+ 1: A C expression giving an additional condition for recognizing
+ the generated pattern.
+ 2: A template or C code to produce assembler output. */
+DEF_RTL_EXPR(DEFINE_COND_EXEC, "define_cond_exec", "Ess", RTX_EXTRA)
+
+/* Definition of an operand predicate. The difference between
+ DEFINE_PREDICATE and DEFINE_SPECIAL_PREDICATE is that genrecog will
+ not warn about a match_operand with no mode if it has a predicate
+ defined with DEFINE_SPECIAL_PREDICATE.
+
+ Operand:
+ 0: The name of the predicate.
+ 1: A boolean expression which computes whether or not the predicate
+ matches. This expression can use IOR, AND, NOT, MATCH_OPERAND,
+ MATCH_CODE, and MATCH_TEST. It must be specific enough that genrecog
+ can calculate the set of RTX codes that can possibly match.
+ 2: A C function body which must return true for the predicate to match.
+ Optional. Use this when the test is too complicated to fit into a
+ match_test expression. */
+DEF_RTL_EXPR(DEFINE_PREDICATE, "define_predicate", "ses", RTX_EXTRA)
+DEF_RTL_EXPR(DEFINE_SPECIAL_PREDICATE, "define_special_predicate", "ses", RTX_EXTRA)
+
+/* Definition of a register operand constraint. This simply maps the
+ constraint string to a register class.
+
+ Operand:
+ 0: The name of the constraint (often, but not always, a single letter).
+ 1: A C expression which evaluates to the appropriate register class for
+ this constraint. If this is not just a constant, it should look only
+ at -m switches and the like.
+ 2: A docstring for this constraint, in Texinfo syntax; not currently
+ used, in future will be incorporated into the manual's list of
+ machine-specific operand constraints. */
+DEF_RTL_EXPR(DEFINE_REGISTER_CONSTRAINT, "define_register_constraint", "sss", RTX_EXTRA)
+
+/* Definition of a non-register operand constraint. These look at the
+ operand and decide whether it fits the constraint.
+
+ DEFINE_CONSTRAINT gets no special treatment if it fails to match.
+ It is appropriate for constant-only constraints, and most others.
+
+ DEFINE_MEMORY_CONSTRAINT tells reload that this constraint can be made
+ to match, if it doesn't already, by converting the operand to the form
+ (mem (reg X)) where X is a base register. It is suitable for constraints
+ that describe a subset of all memory references.
+
+ DEFINE_ADDRESS_CONSTRAINT tells reload that this constraint can be made
+ to match, if it doesn't already, by converting the operand to the form
+ (reg X) where X is a base register. It is suitable for constraints that
+ describe a subset of all address references.
+
+ When in doubt, use plain DEFINE_CONSTRAINT.
+
+ Operand:
+ 0: The name of the constraint (often, but not always, a single letter).
+ 1: A docstring for this constraint, in Texinfo syntax; not currently
+ used, in future will be incorporated into the manual's list of
+ machine-specific operand constraints.
+ 2: A boolean expression which computes whether or not the constraint
+ matches. It should follow the same rules as a define_predicate
+ expression, including the bit about specifying the set of RTX codes
+ that could possibly match. MATCH_TEST subexpressions may make use of
+ these variables:
+ `op' - the RTL object defining the operand.
+ `mode' - the mode of `op'.
+ `ival' - INTVAL(op), if op is a CONST_INT.
+ `hval' - CONST_DOUBLE_HIGH(op), if op is an integer CONST_DOUBLE.
+ `lval' - CONST_DOUBLE_LOW(op), if op is an integer CONST_DOUBLE.
+ `rval' - CONST_DOUBLE_REAL_VALUE(op), if op is a floating-point
+ CONST_DOUBLE.
+ Do not use ival/hval/lval/rval if op is not the appropriate kind of
+ RTL object. */
+DEF_RTL_EXPR(DEFINE_CONSTRAINT, "define_constraint", "sse", RTX_EXTRA)
+DEF_RTL_EXPR(DEFINE_MEMORY_CONSTRAINT, "define_memory_constraint", "sse", RTX_EXTRA)
+DEF_RTL_EXPR(DEFINE_ADDRESS_CONSTRAINT, "define_address_constraint", "sse", RTX_EXTRA)
+
+
+/* Constructions for CPU pipeline description described by NDFAs. */
+
+/* (define_cpu_unit string [string]) describes cpu functional
+ units (separated by comma).
+
+ 1st operand: Names of cpu functional units.
+ 2nd operand: Name of automaton (see comments for DEFINE_AUTOMATON).
+
+ All define_reservations, define_cpu_units, and
+ define_query_cpu_units should have unique names which may not be
+ "nothing". */
+DEF_RTL_EXPR(DEFINE_CPU_UNIT, "define_cpu_unit", "sS", RTX_EXTRA)
+
+/* (define_query_cpu_unit string [string]) describes cpu functional
+ units analogously to define_cpu_unit. The reservation of such
+ units can be queried for automaton state. */
+DEF_RTL_EXPR(DEFINE_QUERY_CPU_UNIT, "define_query_cpu_unit", "sS", RTX_EXTRA)
+
+/* (exclusion_set string string) means that each CPU functional unit
+ in the first string can not be reserved simultaneously with any
+ unit whose name is in the second string and vise versa. CPU units
+ in the string are separated by commas. For example, it is useful
+ for description CPU with fully pipelined floating point functional
+ unit which can execute simultaneously only single floating point
+ insns or only double floating point insns. All CPU functional
+ units in a set should belong to the same automaton. */
+DEF_RTL_EXPR(EXCLUSION_SET, "exclusion_set", "ss", RTX_EXTRA)
+
+/* (presence_set string string) means that each CPU functional unit in
+ the first string can not be reserved unless at least one of pattern
+ of units whose names are in the second string is reserved. This is
+ an asymmetric relation. CPU units or unit patterns in the strings
+ are separated by commas. Pattern is one unit name or unit names
+ separated by white-spaces.
+
+ For example, it is useful for description that slot1 is reserved
+ after slot0 reservation for a VLIW processor. We could describe it
+ by the following construction
+
+ (presence_set "slot1" "slot0")
+
+ Or slot1 is reserved only after slot0 and unit b0 reservation. In
+ this case we could write