d30v.md

gcc-you can use this code to learn something about gcc, and inquire further into linux,

(define_attr "predicable" "no,yes"
  (const_string "yes"))

;; ::::::::::::::::::::
;; ::
;; :: Function Units
;; ::
;; ::::::::::::::::::::

;; On most RISC machines, there are instructions whose results are not
;; available for a specific number of cycles.  Common cases are instructions
;; that load data from memory.  On many machines, a pipeline stall will result
;; if the data is referenced too soon after the load instruction.

;; In addition, many newer microprocessors have multiple function units,
;; usually one for integer and one for floating point, and often will incur
;; pipeline stalls when a result that is needed is not yet ready.

;; The descriptions in this section allow the specification of how much time
;; must elapse between the execution of an instruction and the time when its
;; result is used.  It also allows specification of when the execution of an
;; instruction will delay execution of similar instructions due to function
;; unit conflicts.

;; For the purposes of the specifications in this section, a machine is divided
;; into "function units", each of which execute a specific class of
;; instructions in first-in-first-out order.  Function units that accept one
;; instruction each cycle and allow a result to be used in the succeeding
;; instruction (usually via forwarding) need not be specified.  Classic RISC
;; microprocessors will normally have a single function unit, which we can call
;; `memory'.  The newer "superscalar" processors will often have function units
;; for floating point operations, usually at least a floating point adder and
;; multiplier.

;; Each usage of a function units by a class of insns is specified with a
;; `define_function_unit' expression, which looks like this:

;; (define_function_unit NAME MULTIPLICITY SIMULTANEITY TEST READY-DELAY
;;   ISSUE-DELAY [CONFLICT-LIST])

;; NAME is a string giving the name of the function unit.

;; MULTIPLICITY is an integer specifying the number of identical units in the
;; processor.  If more than one unit is specified, they will be scheduled
;; independently.  Only truly independent units should be counted; a pipelined
;; unit should be specified as a single unit.  (The only common example of a
;; machine that has multiple function units for a single instruction class that
;; are truly independent and not pipelined are the two multiply and two
;; increment units of the CDC 6600.)

;; SIMULTANEITY specifies the maximum number of insns that can be executing in
;; each instance of the function unit simultaneously or zero if the unit is
;; pipelined and has no limit.

;; All `define_function_unit' definitions referring to function unit NAME must
;; have the same name and values for MULTIPLICITY and SIMULTANEITY.

;; TEST is an attribute test that selects the insns we are describing in this
;; definition.  Note that an insn may use more than one function unit and a
;; function unit may be specified in more than one `define_function_unit'.

;; READY-DELAY is an integer that specifies the number of cycles after which
;; the result of the instruction can be used without introducing any stalls.

;; ISSUE-DELAY is an integer that specifies the number of cycles after the
;; instruction matching the TEST expression begins using this unit until a
;; subsequent instruction can begin.  A cost of N indicates an N-1 cycle delay.
;; A subsequent instruction may also be delayed if an earlier instruction has a
;; longer READY-DELAY value.  This blocking effect is computed using the
;; SIMULTANEITY, READY-DELAY, ISSUE-DELAY, and CONFLICT-LIST terms.  For a
;; normal non-pipelined function unit, SIMULTANEITY is one, the unit is taken
;; to block for the READY-DELAY cycles of the executing insn, and smaller
;; values of ISSUE-DELAY are ignored.

;; CONFLICT-LIST is an optional list giving detailed conflict costs for this
;; unit.  If specified, it is a list of condition test expressions to be
;; applied to insns chosen to execute in NAME following the particular insn
;; matching TEST that is already executing in NAME.  For each insn in the list,
;; ISSUE-DELAY specifies the conflict cost; for insns not in the list, the cost
;; is zero.  If not specified, CONFLICT-LIST defaults to all instructions that
;; use the function unit.

;; Typical uses of this vector are where a floating point function unit can
;; pipeline either single- or double-precision operations, but not both, or
;; where a memory unit can pipeline loads, but not stores, etc.

;; As an example, consider a classic RISC machine where the result of a load
;; instruction is not available for two cycles (a single "delay" instruction is
;; required) and where only one load instruction can be executed
;; simultaneously.  This would be specified as:

;; (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)

;; For the case of a floating point function unit that can pipeline
;; either single or double precision, but not both, the following could be
;; specified:
;;
;; (define_function_unit "fp" 1 0
;;   (eq_attr "type" "sp_fp") 4 4
;;   [(eq_attr "type" "dp_fp")])
;;
;; (define_function_unit "fp" 1 0
;;   (eq_attr "type" "dp_fp") 4 4
;;   [(eq_attr "type" "sp_fp")])

;; Note: The scheduler attempts to avoid function unit conflicts and uses all
;; the specifications in the `define_function_unit' expression.  It has
;; recently come to our attention that these specifications may not allow
;; modeling of some of the newer "superscalar" processors that have insns using
;; multiple pipelined units.  These insns will cause a potential conflict for
;; the second unit used during their execution and there is no way of
;; representing that conflict.  We welcome any examples of how function unit
;; conflicts work in such processors and suggestions for their representation.

(define_function_unit "iu" 1 0
  (eq_attr "type" "iu,either")
  1 1
  [(eq_attr "type" "long,lcmp,lload,multi,unknown")])

(define_function_unit "iu" 1 0
  (eq_attr "type" "scmp,mul,scarry")
  2 1
  [(eq_attr "type" "long,lcmp,lload,multi,unknown")])

(define_function_unit "mu" 1 0
  (eq_attr "type" "mu,br,br2,either")
  1 1
  [(eq_attr "type" "long,lcmp,lload,multi,unknown")])

(define_function_unit "mu" 1 0
  (eq_attr "type" "scarry,scmp,sload")
  2 1
  [(eq_attr "type" "long,lcmp,lload,multi,unknown")])

(define_function_unit "long" 1 0
  (eq_attr "type" "long,multi,unknown")
  1 1
  [(eq_attr "type" "iu,mu,scarry,scmp,sload,mul,br,br2,either")])

(define_function_unit "long" 1 0
  (eq_attr "type" "lcmp,lload,lcarry")
  2 1
  [(eq_attr "type" "iu,mu,scarry,scmp,sload,mul,br,br2,either")])


;; ::::::::::::::::::::
;; ::
;; :: Delay Slots
;; ::
;; ::::::::::::::::::::

;; The insn attribute mechanism can be used to specify the requirements for
;; delay slots, if any, on a target machine.  An instruction is said to require
;; a "delay slot" if some instructions that are physically after the
;; instruction are executed as if they were located before it.  Classic
;; examples are branch and call instructions, which often execute the following
;; instruction before the branch or call is performed.

;; On some machines, conditional branch instructions can optionally "annul"
;; instructions in the delay slot.  This means that the instruction will not be
;; executed for certain branch outcomes.  Both instructions that annul if the
;; branch is true and instructions that annul if the branch is false are
;; supported.

;; Delay slot scheduling differs from instruction scheduling in that
;; determining whether an instruction needs a delay slot is dependent only
;; on the type of instruction being generated, not on data flow between the
;; instructions.  See the next section for a discussion of data-dependent
;; instruction scheduling.

;; The requirement of an insn needing one or more delay slots is indicated via
;; the `define_delay' expression.  It has the following form:
;;
;; (define_delay TEST
;;   [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
;;    DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
;;    ...])

;; TEST is an attribute test that indicates whether this `define_delay' applies
;; to a particular insn.  If so, the number of required delay slots is
;; determined by the length of the vector specified as the second argument.  An
;; insn placed in delay slot N must satisfy attribute test DELAY-N.
;; ANNUL-TRUE-N is an attribute test that specifies which insns may be annulled
;; if the branch is true.  Similarly, ANNUL-FALSE-N specifies which insns in
;; the delay slot may be annulled if the branch is false.  If annulling is not
;; supported for that delay slot, `(nil)' should be coded.

;; For example, in the common case where branch and call insns require a single
;; delay slot, which may contain any insn other than a branch or call, the
;; following would be placed in the `md' file:

;; (define_delay (eq_attr "type" "branch,call")
;;		 [(eq_attr "type" "!branch,call") (nil) (nil)])

;; Multiple `define_delay' expressions may be specified.  In this case, each
;; such expression specifies different delay slot requirements and there must
;; be no insn for which tests in two `define_delay' expressions are both true.

;; For example, if we have a machine that requires one delay slot for branches
;; but two for calls, no delay slot can contain a branch or call insn, and any
;; valid insn in the delay slot for the branch can be annulled if the branch is
;; true, we might represent this as follows:

;; (define_delay (eq_attr "type" "branch")
;;   [(eq_attr "type" "!branch,call")
;;    (eq_attr "type" "!branch,call")
;;    (nil)])
;;
;; (define_delay (eq_attr "type" "call")
;;   [(eq_attr "type" "!branch,call") (nil) (nil)
;;    (eq_attr "type" "!branch,call") (nil) (nil)])


;; ::::::::::::::::::::
;; ::
;; :: Moves
;; ::
;; ::::::::::::::::::::

;; Wrap moves in define_expand to prevent memory->memory moves from being
;; generated at the RTL level, which generates better code for most machines
;; which can't do mem->mem moves.

;; If operand 0 is a `subreg' with mode M of a register whose own mode is wider
;; than M, the effect of this instruction is to store the specified value in
;; the part of the register that corresponds to mode M.  The effect on the rest
;; of the register is undefined.

;; This class of patterns is special in several ways.  First of all, each of
;; these names *must* be defined, because there is no other way to copy a datum
;; from one place to another.

;; Second, these patterns are not used solely in the RTL generation pass.  Even
;; the reload pass can generate move insns to copy values from stack slots into
;; temporary registers.  When it does so, one of the operands is a hard
;; register and the other is an operand that can need to be reloaded into a
;; register.

;; Therefore, when given such a pair of operands, the pattern must
;; generate RTL which needs no reloading and needs no temporary
;; registers--no registers other than the operands.  For example, if
;; you support the pattern with a `define_expand', then in such a
;; case the `define_expand' mustn't call `force_reg' or any other such
;; function which might generate new pseudo registers.

;; This requirement exists even for subword modes on a RISC machine
;; where fetching those modes from memory normally requires several
;; insns and some temporary registers.  Look in `spur.md' to see how
;; the requirement can be satisfied.

;; During reload a memory reference with an invalid address may be passed as an
;; operand.  Such an address will be replaced with a valid address later in the
;; reload pass.  In this case, nothing may be done with the address except to
;; use it as it stands.  If it is copied, it will not be replaced with a valid
;; address.  No attempt should be made to make such an address into a valid
;; address and no routine (such as `change_address') that will do so may be
;; called.  Note that `general_operand' will fail when applied to such an
;; address.
;;
;; The global variable `reload_in_progress' (which must be explicitly declared
;; if required) can be used to determine whether such special handling is
;; required.
;;
;; The variety of operands that have reloads depends on the rest of
;; the machine description, but typically on a RISC machine these can
;; only be pseudo registers that did not get hard registers, while on
;; other machines explicit memory references will get optional
;; reloads.
;;
;; If a scratch register is required to move an object to or from memory, it
;; can be allocated using `gen_reg_rtx' prior to reload.  But this is
;; impossible during and after reload.  If there are cases needing scratch
;; registers after reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and
;; perhaps also `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
;; patterns `reload_inM' or `reload_outM' to handle them.  *Note Register
;; Classes::.

;; The constraints on a `moveM' must permit moving any hard register to any
;; other hard register provided that `HARD_REGNO_MODE_OK' permits mode M in
;; both registers and `REGISTER_MOVE_COST' applied to their classes returns a
;; value of 2.

;; It is obligatory to support floating point `moveM' instructions
;; into and out of any registers that can hold fixed point values,
;; because unions and structures (which have modes `SImode' or
;; `DImode') can be in those registers and they may have floating
;; point members.

;; There may also be a need to support fixed point `moveM' instructions in and
;; out of floating point registers.  Unfortunately, I have forgotten why this
;; was so, and I don't know whether it is still true.  If `HARD_REGNO_MODE_OK'
;; rejects fixed point values in floating point registers, then the constraints
;; of the fixed point `moveM' instructions must be designed to avoid ever
;; trying to reload into a floating point register.

(define_expand "movqi"
  [(set (match_operand:QI 0 "general_operand" "")
	(match_operand:QI 1 "general_operand" ""))]
  ""
  "
{
  if (!reload_in_progress && !reload_completed
      && !register_operand (operands[0], QImode)
      && !reg_or_0_operand (operands[1], QImode))
    operands[1] = copy_to_mode_reg (QImode, operands[1]);
}")

(define_insn "*movqi_internal"
  [(set (match_operand:QI 0 "move_output_operand" "=d,d,d,d,Q,m,Q,m,d,c")
	(match_operand:QI 1 "move_input_operand" "dI,i,Q,m,d,d,O,O,c,d"))]
  "register_operand (operands[0], QImode) || reg_or_0_operand (operands[1], QImode)"
  "@
    or%: %0,%.,%1
    or%: %0,%.,%1
    ldb%: %0,%M1
    ldb%: %0,%M1
    stb%: %1,%M0
    stb%: %1,%M0
    stb%: %.,%M0
    stb%: %.,%M0
    mvfsys%: %0,%1
    mvtsys%: %0,%1"
  [(set_attr "length" "4,8,4,8,4,8,4,8,4,4")
   (set_attr "type" "either,long,sload,lload,mu,long,mu,long,mu,mu")])

(define_expand "movhi"
  [(set (match_operand:HI 0 "general_operand" "")
	(match_operand:HI 1 "general_operand" ""))]
  ""
  "
{
  if (!reload_in_progress && !reload_completed
      && !register_operand (operands[0], HImode)
      && !reg_or_0_operand (operands[1], HImode))
    operands[1] = copy_to_mode_reg (HImode, operands[1]);
}")

(define_insn "*movhi_internal"
  [(set (match_operand:HI 0 "move_output_operand" "=d,d,d,d,Q,m,Q,m,d,c")
	(match_operand:HI 1 "move_input_operand" "dI,i,Q,m,d,d,O,O,c,d"))]
  "register_operand (operands[0], HImode) || reg_or_0_operand (operands[1], HImode)"
  "@
    or%: %0,%.,%1
    or%: %0,%.,%1
    ldh%: %0,%M1
    ldh%: %0,%M1
    sth%: %1,%M0
    sth%: %1,%M0
    sth%: %.,%M0
    sth%: %.,%M0
    mvfsys%: %0,%1
    mvtsys%: %0,%1"
  [(set_attr "length" "4,8,4,8,4,8,4,8,4,4")
   (set_attr "type" "either,long,sload,lload,mu,long,mu,long,mu,mu")])

(define_expand "movsi"
  [(set (match_operand:SI 0 "general_operand" "")
	(match_operand:SI 1 "general_operand" ""))]
  ""
  "
{
  if (!reload_in_progress && !reload_completed
      && !register_operand (operands[0], SImode)
      && !reg_or_0_operand (operands[1], SImode))
    operands[1] = copy_to_mode_reg (SImode, operands[1]);

  /* Convert addressing modes into the appropriate add/sub with the clobbers
     needed.  This is generated by builtin_setjmp in the exception handling. */
  if (GET_CODE (operands[1]) == PLUS)
    {
      emit_insn (gen_addsi3 (operands[0], XEXP (operands[1], 0),
			     XEXP (operands[1], 1)));
      DONE;
    }