next_inactive up previous



Contents

1 The GCC 3.3.3 structure

We imagine that the pristine GCC sources generate the target compiler in two phases: (1) generate the target compiler, and (2) build the target compiler.

1.1 Target Compiler Generation

A target is introduced into the compiler through the machine description files. These files are grafted into the source tree at a certain point and access mechanisms to it are specified through the config* files. The first phase of building the target compiler uses these access mechanism to feed the machine descriptions to the compiler generator. In particular, it introduces commands in the Makefile to extract various pieces of information from the machine descriptions and populate corresponding data structures for the generated target compiler. It then introduces commands in the Makefile to build the compiler.

The commands to generate the target compiler are typically named with the prefix gen. In Section (2.1), we detail out the information to be extracted from the machine description, the data structures populated in the output and other aspects of the basic operation of each of these files.

Certain macros are frequently used in the GCC sources. These are listed in Section (7).

2 Building the Target Compiler

Figure 1 shows the generation of the target specific instance of the GCC sources. The pristine GCC sources are given the desired target via the configure command. Once the desired target is known, a set of generators operate on the corresponding machine description and generate the target specific components of the compiler. The pristine GCC sources are parametrised with ``place holders'' for target specific information. From this perspective, the generators are said to ``generate'' the target specific instance of the generic GCC sources. We emphasise again that at this point we have generated a target specific version of the GCC sources which are yet to be compiled into a binary. One could also say that the generators adapt the GCC sources for the given target.

Figure 1: Basic Target Compiler Generation Process
\begin{figure}\centering
\epsfxsize =0.8\textwidth
\epsffile{gcc.build.001.eps}
\end{figure}
Figure 2: Detail Target Compiler Generation Process
\begin{figure}\centering
\epsfxsize =0.8\textwidth
\epsffile{gcc.build.002.eps}
\end{figure}

The leftmost part of Figure 1 shows the structure of the generators. The common functionalities are memoized into libiberty.a and a few source files. Each generator uses these files and it's own main code to extract information from the target specific machine description. These files are described (succinctly and then in detail) in Section (2.1). Figure 2 shows the data structures generated by the generators for the target specific compiler. We will shortly connect them to the various operational components of the compiler.

The exact sequence of the generation amd build of the target compiler is studied by looking at the sequence of the commands that are executed by a make on the sources after their configuration. The commands are collected in a file. An examination of these commands permits us to assign concpetual boundaries in the build process so that one can identify the initially the support routines are built and collected into the libiberty.a library, the generators are converted into process that extract the information from the machine descriptions and finally the compiler for the desired language is built. This technique captures the build for a given version of the compiler and cannot insulate us from architectural variations in future build techniques of the compiler. However, the idea is to try identifying the various logical components of a compiler build to create a foundation for understanding any future variations in the architecture.

A study of the make of the compiler gives the following structure of compilations:

  1. libiberty/: Generates libiberty.a.
  2. libiberty/testsuite/: Nothing occurs here!
  3. zlib/: Generates libz.a.
  4. fastjar/: Generates a few JAR tools.
  5. gcc/ See Table (1)
  6. gcc/intl/: Nothing occurs here!
  7. gcc/ See Tables (2,3)
  8. gcc/fixinc/
  9. gcc/

The libiberty library contains general, multipurpose routines (to handle common tasks like regular expressions manipulations) which are used in the other programs that build the final compiler.

Table 1: Thinking a good caption...

\begin{tabular}{\vert l\vert l\vert l\vert l\vert}
\hline
In GCC Sources & Bu...
...tt ggc-none.c} & & & \\
\& {\tt libiberty.a} & & & \\
\hline
\end{tabular}



Table 2: Thinking another good caption (2-1)...

\begin{tabular}{\vert l\vert l\vert l\vert l\vert}
\hline
In GCC Sources & Bu...
...tt ggc-none.c} & & & \\
\& {\tt libiberty.a} & & & \\
\hline
\end{tabular}



Table 3: Thinking another good caption (2-2)...

\begin{tabular}{\vert l\vert l\vert l\vert l\vert}
\hline
In GCC Sources & Bu...
...tt ggc-none.c} & & & \\
\& {\tt libiberty.a} & & & \\
\hline
\end{tabular}


The backend (internal) library contains routines that perform various analyses and optimizations on the RTL representation. These routines are common to all front ends and are therefore collected into a library libbackend.a and are shown in tables 4, 5 and 6.


Table 4: Compiler files and their contents

\begin{tabular}{\vert l\vert l\vert}
\hline
Source File & Use \\
\hline
{\tt al...
...ront end tree to a backend RTL \\
& \hfill $\ldots$ \\
\hline
\end{tabular}



Table 5: Compiler files and their contents

\begin{tabular}{\vert l\vert l\vert}
\hline
Source File & Use \\
\hline
& \hfi...
... of move
instructions needed. \\
& \hfill $\ldots$ \\
\hline
\end{tabular}



Table 6: Compiler files and their contents (contd.)

\begin{tabular}{\vert l\vert l\vert}
\hline
Source File & Use \\
\hline
& \hfi...
... collector \\
{\tt i386.c} & i386 machine description \\
\hline
\end{tabular}


A compiler for a given language, say C, is built using the front end processor files in the respective directories, a few common routines from libiberty.a and the backend library libbackend.a. For C, the files used are shown in table 7 and are used to generate the compiler cc1.


Table 7: Compiler files and their contents for cc1

\begin{tabular}{\vert l\vert l\vert}
\hline
Source File & Use \\
\hline
c-parse...
...erty.a & GNU CC internal collection of useful routines \\
\hline
\end{tabular}



2.1 The gen Files

The code number of an insn is simply its position in the machine description. They are assigned sequentially to entries in the description, starting with code number 0.


Table: A brief description of the various gen files

\begin{tabular}{ll}
{\tt gensupport.c} & Support routines for the various genera...
...rotos.c} & Massages a list of prototypes, for use by fixproto. \\
\end{tabular}



2.1.1 gensupport

SYNOPSIS: Support routines for the various generation passes.

This file has a number of functions that are useful at various points of the target compiler generation. In particular, init_md_reader and read_md_rtx are used to setup the reading of a machine description file and reading a single rtx in it. The function maybe_eval_c_test takes a string representing a C test expression, looks it up in the condition table and reports whether or not its value is known at compile time.


2.1.2 genconditions

SYNOPSIS: Calculate constant conditions.

GENERATES: insn-conditions.c

In a machine description, all of the insn patterns - define_insn, define_expand, define_split, define_peephole, define_peephole2 - contain an optional C expression which makes the final decision about whether or not this pattern is usable. That expression may turn out to be always false when the compiler is built. If it is, most of the programs that generate code from the machine description can simply ignore the entire pattern.


2.1.3 genconstants

SYNOPSIS: Generate a series of #define statements, one for each constant named in a (define_constants ...) pattern.

GENERATES: insn-constants.h

This program does not use gensupport.c because it does looks only at the define_constants.


2.1.4 genflags

SYNOPSIS: Generate flags HAVE_... saying which simple standard instructions are available for this machine.

GENERATES: insn-flags.h

We scan the define_insn's and define_expand's in the machine description and look at ``instructions'' with names that are either not NULL or begin with any other character except a *. In other words, the so-called ``standard instructions'' are accepted, the rest are ignored. Thus we create a list of those ``standard instructions'' that the given processor ``knows''. An instruction in the MD file could have an associated condition expressed in C. This is the second ``field'' of the description of the instruction. The genconditions program would have already looked at each of these and memoized the compile time constants. The instruction pattern is practically non existent if the condition is false. We therefore, list out only those instruction patterns for which the condition is known to be true or it's value is not known at compile time. If the condition is known to be true, we define an ``existence'' macro. If the condition is not known at compile time, then we define the macro to be the condition itself. Note that the genconditions program is concerned with the conditions in all the RTL constructs, while we focus only on the ``instructions'' constructs, i.e. define_insn and define_expand. However, since the genconditions program has already looked at all the condition expressions and memoized them, we directly use the table that it constructs.


2.1.5 genconfig

SYNOPSIS: Generate some #define configuration flags.

GENERATES: insn-config.h

e.g. (am i sure that what follows is an example of the comment above ?) flags to determine output of machine description dependent #define's.


2.1.6 gencodes

SYNOPSIS: Generate some macros CODE_FOR_... giving the insn_code_number value for each of the defined standard insn names.

GENERATES: insn-codes.h


2.1.7 genpreds

SYNOPSIS: Generate some macros CODE_FOR_... giving the insn_code_number value for each of the defined standard insn names.


2.1.8 genattr

SYNOPSIS: Generate attribute information (insn-attr.h).

GENERATES: insn-attr.h


2.1.9 genattrtab

SYNOPSIS: Generate code to compute values of attributes.

GENERATES: insn-attrtab.c

USES: genautomata.c (for pipeline hazard description system in MD files)

This program handles insn attributes and the DEFINE_DELAY and DEFINE_-FUNCTION_UNIT definitions.

It produces a series of functions named `get_attr_...', one for each insn attribute. Each of these is given the rtx for an insn and returns a member of the enum for the attribute.

These subroutines have the form of a `switch' on the INSN_CODE (via `recog_-memoized'). Each case either returns a constant attribute value or a value that depends on tests on other attributes, the form of operands, or some random C expression (encoded with a SYMBOL_REF expression).

If the attribute `alternative', or a random C expression is present, `constrain_ope-rands' is called. If either of these cases of a reference to an operand is found, `extract_insn' is called.

The special attribute `length' is also recognized. For this operand, expressions involving the address of an operand or the current insn, (address (pc)), are valid. In this case, an initial pass is made to set all lengths that do not depend on address. Those that do are set to the maximum length. Then each insn that depends on an address is checked and possibly has its length changed. The process repeats until no further changed are made. The resulting lengths are saved for use by `get_attr_length'.

A special form of DEFINE_ATTR, where the expression for default value is a CONST expression, indicates an attribute that is constant for a given run of the compiler. The subroutine generated for these attributes has no parameters as it does not depend on any particular insn. Constant attributes are typically used to specify which variety of processor is used.

Internal attributes are defined to handle DEFINE_DELAY and DEFINE_FUN-CTION_UNIT. Special routines are output for these cases.

This program works by keeping a list of possible values for each attribute. These include the basic attribute choices, default values for attribute, and all derived quantities.

As the description file is read, the definition for each insn is saved in a `struct insn_def'. When the file reading is complete, a `struct insn_ent' is created for each insn and chained to the corresponding attribute value, either that specified, or the default.

An optimization phase is then run. This simplifies expressions for each insn. EQ_ATTR tests are resolved, whenever possible, to a test that indicates when the attribute has the specified value for the insn. This avoids recursive calls during compilation.

The strategy used when processing DEFINE_DELAY and DEFINE_FUNC-TION_UNIT definitions is to create arbitrarily complex expressions and have the optimization simplify them.

Once optimization is complete, any required routines and definitions will be written.

An optimization that is not yet implemented is to hoist the constant expressions entirely out of the routines and definitions that are written. A way to do this is to iterate over all possible combinations of values for constant attributes and generate a set of functions for that given combination. An initialization function would be written that evaluates the attributes and installs the corresponding set of routines and definitions (each would be accessed through a pointer).

We use the flags in an RTX as follows:

`unchanging' (ATTR_IND_SIMPLIFIED_P): This rtx is fully simplified independent of the insn code.

`in_struct' (ATTR_CURR_SIMPLIFIED_P): This rtx is fully simplified for the insn code currently being processed (see optimize_attrs).

`integrated' (ATTR_PERMANENT_P): This rtx is permanent and unique (see attr_rtx).

`volatil' (ATTR_EQ_ATTR_P): During simplify_by_exploding the value of an EQ_ATTR rtx is true if !volatil and false if volatil.


2.1.10 genemit

SYNOPSIS: Generate code to emit insns as rtl.


2.1.11 genextract

SYNOPSIS: Generate code to extract operands from insn as rtl.


2.1.12 genopinit

SYNOPSIS: Generate code to initialize optabs from machine description.

GENERATES: insn-opinit.c

Many parts of GCC use arrays that are indexed by machine mode and contain the insn codes for pattern in the MD file that perform a given operation on operands of that mode.

These patterns are present in the MD file with names that contain the mode(s) used and the name of the operation. This program writes a function `init_all_op-tabs' that initializes the optabs with all the insn codes of the relevant patterns present in the MD file.

This array contains a list of optabs that need to be initialized. Within each string, the name of the pattern to be matched against is delimited with $( and $). In the string, $a and $b are used to match a short mode name (the part of the mode name not including `mode' and converted to lower-case). When writing out the initializer, the entire string is used. $A and $B are replaced with the full name of the mode; $a and $b are replaced with the short form of the name, as above.

If $N is present in the pattern, it means the two modes must be consecutive widths in the same mode class (e.g, QImode and HImode). $I means that only full integer modes should be considered for the next mode, and $F means that only float modes should be considered. $P means that both full and partial integer modes should be considered.

$V means to emit 'v' if the first mode is a MODE_FLOAT mode.

For some optabs, we store the operation by RTL codes. These are only used for comparisons. In that case, $c and $C are the lower-case and upper-case forms of the comparison, respectively.


2.1.13 genoutput

SYNOPSIS: Generate code to output assembler insns as recognized from rtl.

GENERATES: insn-output.c

This program reads the machine description for the compiler target machine and produces a file containing these things:

  1. An array of `struct insn_data', which is indexed by insn code number, which contains:

    1. `name' is the name for that pattern. Nameless patterns are given a name.

    2. `output' hold either the output template, an array of output templates, or an output function.

    3. `genfun' is the function to generate a body for that pattern, given operands as arguments.

    4. `n_operands' is the number of distinct operands in the pattern for that insn,

    5. `n_dups' is the number of match_dup's that appear in the insn's pattern. This says how many elements of `recog_data.dup_loc' are significant after an insn has been recognized.

    6. `n_alternatives' is the number of alternatives in the constraints of each pattern.

    7. `output_format' tells what type of thing `output' is.

    8. `operand' is the base of an array of operand data for the insn.

  2. An array of `struct insn_operand data', used by `operand' above.

    1. `predicate', an int-valued function, is the match_operand predicate for this operand.

    2. `constraint' is the constraint for this operand. This exists only if register constraints appear in match_ope-rand rtx's.

    3. `address_p' indicates that the operand appears within ADDRESS rtx's. This exists only if there are *no* register constraints in the match_operand rtx's.

    4. `mode' is the machine mode that that operand is supposed to have.

    5. `strict_low', is nonzero for operands contained in a STRICT_LOW_-PART.

    6. `eliminable', is nonzero for operands that are matched normally by MATCH_OPERAND; it is zero for operands that should not be changed during register elimination such as MATCH_OPERATORs.

Since the code number of an insn is simply its position in the machine description, the following entry in the machine description

    (define_insn "clrdf"
      [(set (match_operand:DF 0 "general_operand" "")
            (const_int 0))]
      ""
      "clrd %0")
  
assuming it is the 25th entry present, would cause insn_data[24].template to be "clrd %0", and insn_data[24]. n_operands to be 1.


2.1.14 genpeep

SYNOPSIS: Generate code to perform peephole optimizations.


2.1.15 genrecog

SYNOPSIS: Generate code to recognize rtl as insns.

GENERATES: insn-recog.c

This program is used to produce insn-recog.c, which contains a function called `recog' plus its subroutines. These functions contain a decision tree that recognizes whether an rtx, the argument given to recog, is a valid instruction.

recog returns -1 if the rtx is not valid. If the rtx is valid, recog returns a nonnegative number which is the insn code number for the pattern that matched. This is the same as the order in the machine description of the entry that matched. This number can be used as an index into various insn_* tables, such as insn_template, insn_outfun, and insn_n_operands (found in insn-output.c).

The third argument to recog is an optional pointer to an int. If present, recog will accept a pattern if it matches except for missing CLOBBER expressions at the end. In that case, the value pointed to by the optional pointer will be set to the number of CLOBBERs that need to be added (it should be initialized to zero by the caller). If it is set nonzero, the caller should allocate a PARALLEL of the appropriate size, copy the initial entries, and call add_clobbers (found in insn-emit.c) to fill in the CLOBBERs.

This program also generates the function `split_insns', which returns 0 if the rtl could not be split, or it returns the split rtl as an INSN list.

This program also generates the function `peephole2_insns', which returns 0 if the rtl could not be matched. If there was a match, the new rtl is returned in an INSN list, and LAST_INSN will point to the last recognized insn in the old sequence.


2.1.16 gencheck

SYNOPSIS: Generate check macros for tree codes.


2.1.17 gengenrtl

SYNOPSIS: Generate code to allocate RTL structures.


2.1.18 genrtl

SYNOPSIS: Generated automatically by gengenrtl from rtl.def.


2.1.19 gengtype

SYNOPSIS: Process source files and output type information.


2.1.20 genautomata

SYNOPSIS: Pipeline hazard description translator.


2.1.21 gen-protos

SYNOPSIS: A lexical scanner generated by flex


2.1.22 gengtype-lex

SYNOPSIS: A Bison parser, made from gengtype-yacc.y.


2.1.23 gengtype-yacc

SYNOPSIS: Massages a list of prototypes, for use by fixproto.

3 Classifying Target Description Macros

The GCC system uses a set of macros to primarily describe the target system and also a few other parameters. We present a classification below.

The macros are arbitrarily classified into the following categories:

  1. Source Language Related
  2. Target Processor Related
  3. Target Machine Architecture Related
  4. Target Assembly Language Related
  5. Target Compiler Operation Related

3.1 Source Language Related

The source languages that GCC can parse use a stack based discipline for procedure activations and deactivations. Specifications like these are a consequence of the source language properties. Other aspects like the data types supported by the source language and their representation on the target are included in this category.

3.1.1 Layout of Source Language Data Types

 INT_TYPE_SIZE                       SHORT_TYPE_SIZE
 LONG_TYPE_SIZE                      ADA_LONG_TYPE_SIZE
 MAX_LONG_TYPE_SIZE                  LONG_LONG_TYPE_SIZE
 CHAR_TYPE_SIZE                      BOOL_TYPE_SIZE
 FLOAT_TYPE_SIZE                     DOUBLE_TYPE_SIZE
 LONG_DOUBLE_TYPE_SIZE               TARGET_FLT_EVAL_METHOD
 WIDEST_HARDWARE_FP_SIZE             DEFAULT_SIGNED_CHAR
 DEFAULT_SHORT_ENUMS                 SIZE_TYPE
 PTRDIFF_TYPE                        WCHAR_TYPE
 WCHAR_TYPE_SIZE                     MAX_WCHAR_TYPE_SIZE
 GCOV_TYPE_SIZE                      WINT_TYPE
 INTMAX_TYPE                         UINTMAX_TYPE
 TARGET_PTRMEMFUNC_VBIT_LOCATION     TARGET_VTABLE_USES_DESCRIPTORS
 TARGET_VTABLE_ENTRY_ALIGN           TARGET_VTABLE_DATA_ENTRY_DISTANCE

3.1.2 Stack Layout and Calling Conventions

3.1.2.1 Basic Stack Layout

    STACK_GROWS_DOWNWARD              STACK_PUSH_CODE
    FRAME_GROWS_DOWNWARD              ARGS_GROW_DOWNWARD
    STARTING_FRAME_OFFSET             STACK_POINTER_OFFSET
    FIRST_PARM_OFFSET (FUNDECL)       STACK_DYNAMIC_OFFSET (FUNDECL)
    DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) SETUP_FRAME_ADDRESSES
    BUILTIN_SETJMP_FRAME_VALUE        RETURN_ADDR_RTX (COUNT, FRAMEADDR)
    RETURN_ADDR_IN_PREVIOUS_FRAME     INCOMING_RETURN_ADDR_RTX
    INCOMING_FRAME_SP_OFFSET          ARG_POINTER_CFA_OFFSET (FUNDECL)
    SMALL_STACK

3.1.2.2 Exception Handling Support

    EH_RETURN_DATA_REGNO (N)
    EH_RETURN_STACKADJ_RTX
    EH_RETURN_HANDLER_RTX
    ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL)
    ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX(FILE, ENCODING, SIZE, ADDR, DONE)
    MD_FALLBACK_FRAME_STATE_FOR(CONTEXT, FS, SUCCESS)
    MD_HANDLE_UNWABI(CONTEXT, FS)

3.1.2.3 Specifying How Stack Checking is Done

    STACK_CHECK_BUILTIN         STACK_CHECK_PROBE_INTERVAL
    STACK_CHECK_PROBE_LOAD      STACK_CHECK_PROTECT
    STACK_CHECK_MAX_FRAME_SIZE  STACK_CHECK_FIXED_FRAME_SIZE
    STACK_CHECK_MAX_VAR_SIZE

3.1.2.4 Registers That Address the Stack Frame

    STACK_POINTER_REGNUM            FRAME_POINTER_REGNUM
    HARD_FRAME_POINTER_REGNUM       ARG_POINTER_REGNUM
    RETURN_ADDRESS_POINTER_REGNUM   STATIC_CHAIN_REGNUM
    STATIC_CHAIN_INCOMING_REGNUM    STATIC_CHAIN
    STATIC_CHAIN_INCOMING           DWARF_FRAME_REGISTERS
    PRE_GCC3_DWARF_FRAME_REGISTERS

3.1.2.5 Eliminating Frame Pointer and Arg Pointer

    FRAME_POINTER_REQUIRED
    INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
    ELIMINABLE_REGS
    CAN_ELIMINATE (FROM-REG, TO-REG)
    INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)

3.1.2.6 Passing Function Arguments on the Stack

      PROMOTE_PROTOTYPES
      PUSH_ARGS
      PUSH_ROUNDING (NPUSHED)
      ACCUMULATE_OUTGOING_ARGS
      REG_PARM_STACK_SPACE (FNDECL)
      MAYBE_REG_PARM_STACK_SPACE
      FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)
      OUTGOING_REG_PARM_STACK_SPACE
      STACK_PARMS_IN_REG_PARM_AREA
      RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)
      CALL_POPS_ARGS (CUM)

3.1.2.7 Passing Arguments in Registers

      FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
      MUST_PASS_IN_STACK (MODE, TYPE)
      FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
      FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)
      FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)
      FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)
      CUMULATIVE_ARGS
      INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)
      INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
      INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
      FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
      FUNCTION_ARG_PADDING (MODE, TYPE)
      PAD_VARARGS_DOWN
      FUNCTION_ARG_BOUNDARY (MODE, TYPE)
      FUNCTION_ARG_REGNO_P (REGNO)
      LOAD_ARGS_REVERSED

3.1.2.8 How Scalar Function Values Are Returned

      FUNCTION_VALUE (VALTYPE, FUNC)
      FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)
      LIBCALL_VALUE (MODE)
      FUNCTION_VALUE_REGNO_P (REGNO)
      APPLY_RESULT_SIZE

3.1.2.9 How Large Values Are Returned

      RETURN_IN_MEMORY (TYPE)
      DEFAULT_PCC_STRUCT_RETURN
      STRUCT_VALUE_REGNUM
      STRUCT_VALUE
      STRUCT_VALUE_INCOMING_REGNUM
      STRUCT_VALUE_INCOMING
      PCC_STATIC_STRUCT_RETURN

3.1.2.10 Caller-Saves Register Allocation

      DEFAULT_CALLER_SAVES
      CALLER_SAVE_PROFITABLE (REFS, CALLS)
      HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)

3.1.2.11 Function Entry and Exit

      - Target Hook: void 
                     TARGET_ASM_FUNCTION_PROLOGUE 
                     (FILE *FILE, HOST_WIDE_INT SIZE)
      - Target Hook: void 
                     TARGET_ASM_FUNCTION_END_PROLOGUE 
                     (FILE *FILE)
      - Target Hook: void 
                     TARGET_ASM_FUNCTION_BEGIN_EPILOGUE 
                     (FILE *FILE)
      - Target Hook: void 
                     TARGET_ASM_FUNCTION_EPILOGUE 
                     (FILE *FILE, HOST_WIDE_INT SIZE)
      EXIT_IGNORE_STACK
      EPILOGUE_USES (REGNO)
      EH_USES (REGNO)
      DELAY_SLOTS_FOR_EPILOGUE
      ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
      - Target Hook: void 
                     TARGET_ASM_OUTPUT_MI_THUNK 
                     (FILE *FILE, 
                      tree THUNK_FNDECL, 
                      HOST_WIDE_INT DELTA, 
                      tree FUNCTION)
      - Target Hook: void 
                     TARGET_ASM_OUTPUT_MI_VCALL_THUNK 
                     (FILE *FILE, 
                      tree THUNK_FNDECL, 
                      HOST_WIDE_INT DELTA, 
                      int VCALL_OFFSET, 
                      tree FUNCTION)

3.1.2.12 Generating Code for Profiling

      FUNCTION_PROFILER (FILE, LABELNO)
      PROFILE_HOOK
      NO_PROFILE_COUNTERS
      PROFILE_BEFORE_PROLOGUE

3.1.2.13 Permitting tail calls

      FUNCTION_OK_FOR_SIBCALL (DECL)

3.1.3 Trampolines for Nested Functions

      TRAMPOLINE_TEMPLATE (FILE)
      TRAMPOLINE_SECTION
      TRAMPOLINE_SIZE
      TRAMPOLINE_ALIGNMENT
      INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)
      TRAMPOLINE_ADJUST_ADDRESS (ADDR)
      ALLOCATE_TRAMPOLINE (FP)
      INSN_CACHE_SIZE
      INSN_CACHE_LINE_WIDTH
      INSN_CACHE_DEPTH
      CLEAR_INSN_CACHE (BEG, END)
      TRANSFER_FROM_TRAMPOLINE

3.1.4 Library routines for operations not supported on the architecture

      MULSI3_LIBCALL
      DIVSI3_LIBCALL
      UDIVSI3_LIBCALL
      MODSI3_LIBCALL
      UMODSI3_LIBCALL
      MULDI3_LIBCALL
      DIVDI3_LIBCALL
      UDIVDI3_LIBCALL
      MODDI3_LIBCALL
      UMODDI3_LIBCALL
      DECLARE_LIBRARY_RENAMES
      INIT_TARGET_OPTABS
      FLOAT_LIB_COMPARE_RETURNS_BOOL
      TARGET_EDOM
      GEN_ERRNO_RTX
      TARGET_MEM_FUNCTIONS
      LIBGCC_NEEDS_DOUBLE
      NEXT_OBJC_RUNTIME

3.2 Target Machine Architecture Related

Although all the machines for which we have GCC are built according to the von Neumann prescription, the target architecture can differ in a number of minute details with respect to the host or the build system. Two major subcategories that can occur here are the details of the target CPU and the target core memory.

3.2.1 Target Character Escape Sequences

      TARGET_BELL
      TARGET_ESC
      TARGET_BS
      TARGET_TAB
      TARGET_NEWLINE
      TARGET_VT
      TARGET_FF
      TARGET_CR

3.2.2 Target CPU Architecture Related

The instruction set is one of the main points of differences between a host and a target, especially for non native compilers. This is usually taken care of separately in the .md file. Macros specify other details like the registers set, special registers, available condition codes etc.

3.2.2.1 Register Usage

3.2.2.1.1 Basic Characteristics of Registers
      FIRST_PSEUDO_REGISTER
      FIXED_REGISTERS
      CALL_USED_REGISTERS
      CALL_REALLY_USED_REGISTERS
      HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
      CONDITIONAL_REGISTER_USAGE
      NON_SAVING_SETJMP
      INCOMING_REGNO (OUT)
      OUTGOING_REGNO (IN)
      LOCAL_REGNO (REGNO)

3.2.2.1.2 Order of Allocation of Registers
      REG_ALLOC_ORDER
      ORDER_REGS_FOR_LOCAL_ALLOC

3.2.2.1.3 How Values Fit in Registers
      HARD_REGNO_NREGS (REGNO, MODE)
      HARD_REGNO_MODE_OK (REGNO, MODE)
      MODES_TIEABLE_P (MODE1, MODE2)
      AVOID_CCMODE_COPIES

3.2.2.1.4 Handling Leaf Functions
      LEAF_REGISTERS
      LEAF_REG_REMAP (REGNO)

3.2.2.1.5 Registers That Form a Stack
      STACK_REGS
      FIRST_STACK_REG
      LAST_STACK_REG

3.2.2.2 Register Classes

      enum reg_class
      N_REG_CLASSES
      REG_CLASS_NAMES
      REG_CLASS_CONTENTS
      REGNO_REG_CLASS (REGNO)
      BASE_REG_CLASS
      MODE_BASE_REG_CLASS (MODE)
      INDEX_REG_CLASS
      REG_CLASS_FROM_LETTER (CHAR)
      REGNO_OK_FOR_BASE_P (NUM)
      REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
      REGNO_OK_FOR_INDEX_P (NUM)
      PREFERRED_RELOAD_CLASS (X, CLASS)
      PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
      LIMIT_RELOAD_CLASS (MODE, CLASS)
      SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
      SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
      SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
      SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
      SECONDARY_MEMORY_NEEDED_RTX (MODE)
      SECONDARY_MEMORY_NEEDED_MODE (MODE)
      SMALL_REGISTER_CLASSES
      CLASS_LIKELY_SPILLED_P (CLASS)
      CLASS_MAX_NREGS (CLASS, MODE)
      CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)
      CONST_OK_FOR_LETTER_P (VALUE, C)
      CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
      EXTRA_CONSTRAINT (VALUE, C)
      EXTRA_MEMORY_CONSTRAINT (C)
      EXTRA_ADDRESS_CONSTRAINT (C)

3.2.3 Addressing Modes

      HAVE_PRE_INCREMENT
      HAVE_PRE_DECREMENT
      HAVE_POST_INCREMENT
      HAVE_POST_DECREMENT
      HAVE_PRE_MODIFY_DISP
      HAVE_POST_MODIFY_DISP
      HAVE_PRE_MODIFY_REG
      HAVE_POST_MODIFY_REG
      CONSTANT_ADDRESS_P (X)
      MAX_REGS_PER_ADDRESS
      GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
      REG_OK_FOR_BASE_P (X)
      REG_MODE_OK_FOR_BASE_P (X, MODE)
      REG_OK_FOR_INDEX_P (X)
      FIND_BASE_TERM (X)
      LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)
      LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)
      GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
      LEGITIMATE_CONSTANT_P (X)

3.2.4 Condition Code Status

      CC_STATUS_MDEP
      CC_STATUS_MDEP_INIT
      NOTICE_UPDATE_CC (EXP, INSN)
      EXTRA_CC_MODES
      SELECT_CC_MODE (OP, X, Y)
      CANONICALIZE_COMPARISON (CODE, OP0, OP1)
      REVERSIBLE_CC_MODE (MODE)
      REVERSE_CONDEXEC_PREDICATES_P (CODE1, CODE2)

3.2.5 Describing Relative Costs of Operations

      CONST_COSTS (X, CODE, OUTER_CODE)
      RTX_COSTS (X, CODE, OUTER_CODE)
      DEFAULT_RTX_COSTS (X, CODE, OUTER_CODE)
      ADDRESS_COST (ADDRESS)
      REGISTER_MOVE_COST (MODE, FROM, TO)
      MEMORY_MOVE_COST (MODE, CLASS, IN)
      BRANCH_COST
      SLOW_BYTE_ACCESS
      SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
      DONT_REDUCE_ADDR
      MOVE_RATIO
      MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
      MOVE_MAX_PIECES
      CLEAR_RATIO
      CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
      USE_LOAD_POST_INCREMENT (MODE)
      USE_LOAD_POST_DECREMENT (MODE)
      USE_LOAD_PRE_INCREMENT (MODE)
      USE_LOAD_PRE_DECREMENT (MODE)
      USE_STORE_POST_INCREMENT (MODE)
      USE_STORE_POST_DECREMENT (MODE)
      USE_STORE_PRE_INCREMENT (MODE)
      USE_STORE_PRE_DECREMENT (MODE)
      NO_FUNCTION_CSE
      NO_RECURSIVE_FUNCTION_CSE

3.2.6 Target Core Memory Layout Related

The Target machine could have a different core memory layout. Thus the target system could be different from the host or the build regarding, for example, it's word size, it's endianness, the address bus size etc. A collection of macros is used to specify such properties. We regard the layout of the activation record as a ``source language issue'' rather than a target memory layout issue.

3.2.6.1 Basic Storage Layout

      BITS_BIG_ENDIAN
      BYTES_BIG_ENDIAN
      WORDS_BIG_ENDIAN
      LIBGCC2_WORDS_BIG_ENDIAN
      FLOAT_WORDS_BIG_ENDIAN
      BITS_PER_UNIT
      BITS_PER_WORD
      MAX_BITS_PER_WORD
      UNITS_PER_WORD
      MIN_UNITS_PER_WORD
      POINTER_SIZE
      POINTERS_EXTEND_UNSIGNED
      PROMOTE_MODE (M, UNSIGNEDP, TYPE)
      PROMOTE_FUNCTION_ARGS
      PROMOTE_FUNCTION_RETURN
      PROMOTE_FOR_CALL_ONLY
      PARM_BOUNDARY
      STACK_BOUNDARY
      PREFERRED_STACK_BOUNDARY
      FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
      FUNCTION_BOUNDARY
      BIGGEST_ALIGNMENT
      MINIMUM_ATOMIC_ALIGNMENT
      BIGGEST_FIELD_ALIGNMENT
      ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
      MAX_OFILE_ALIGNMENT
      DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
      CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
      LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
      EMPTY_FIELD_BOUNDARY
      STRUCTURE_SIZE_BOUNDARY
      STRICT_ALIGNMENT
      PCC_BITFIELD_TYPE_MATTERS
      BITFIELD_NBYTES_LIMITED
      MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
      ROUND_TYPE_SIZE (TYPE, COMPUTED, SPECIFIED)
      ROUND_TYPE_SIZE_UNIT (TYPE, COMPUTED, SPECIFIED)
      ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
      MAX_FIXED_MODE_SIZE
      VECTOR_MODE_SUPPORTED_P(MODE)
      STACK_SAVEAREA_MODE (SAVE_LEVEL)
      STACK_SIZE_MODE
      TARGET_FLOAT_FORMAT
         IEEE_FLOAT_FORMAT
         VAX_FLOAT_FORMAT
         IBM_FLOAT_FORMAT
         C4X_FLOAT_FORMAT
         UNKNOWN_FLOAT_FORMAT
      MODE_HAS_NANS (MODE)
      MODE_HAS_INFINITIES (MODE)
      MODE_HAS_SIGNED_ZEROS (MODE)
      MODE_HAS_SIGN_DEPENDENT_ROUNDING (MODE)
      ROUND_TOWARDS_ZERO
      LARGEST_EXPONENT_IS_NORMAL (SIZE)
      - Target Hook: bool 
                     TARGET_MS_BITFIELD_LAYOUT_P 
                     (tree RECORD_TYPE)

3.2.6.2 Position Independent Code

      PIC_OFFSET_TABLE_REGNUM
      PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
      FINALIZE_PIC
      LEGITIMATE_PIC_OPERAND_P (X)

3.3 Target Assembly Language Related

An assembly program is just a program representation in the target assembly language. This representation depends on the conventions adopted for the target tools chain. These conventions could be different from the host or the build system. Thus the macros in this category specify the details of the conventions regarding the assembly code layout on the target.

3.3.1 Dividing the Output into Sections (Texts, Data, ...)

      TEXT_SECTION_ASM_OP
      TEXT_SECTION
      HOT_TEXT_SECTION_NAME
      UNLIKELY_EXECUTED_TEXT_SECTION_NAME
      DATA_SECTION_ASM_OP
      READONLY_DATA_SECTION_ASM_OP
      READONLY_DATA_SECTION
      SHARED_SECTION_ASM_OP
      BSS_SECTION_ASM_OP
      SHARED_BSS_SECTION_ASM_OP
      INIT_SECTION_ASM_OP
      FINI_SECTION_ASM_OP
      CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
      FORCE_CODE_SECTION_ALIGN
      EXTRA_SECTIONS
      EXTRA_SECTION_FUNCTIONS
      JUMP_TABLES_IN_TEXT_SECTION
      - Target Hook: void TARGET_ASM_SELECT_SECTION (tree EXP, int RELOC,
          unsigned HOST_WIDE_INT ALIGN)
      - Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
      - Target Hook: void TARGET_ASM_SELECT_RTX_SECTION (enum machine_mode
          MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
      - Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, int
          NEW_DECL_P)
      - Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char
          *name)
      - Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP)
      - Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION
      - Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP)
      - Variable: Target Hook bool TARGET_HAVE_TLS

3.3.2 Defining the Output Assembler Language

3.3.2.1 The Overall Framework of an Assembler File

      ASM_FILE_START (STREAM)
      ASM_FILE_END (STREAM)
      ASM_COMMENT_START
      ASM_APP_ON
      ASM_APP_OFF
      ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
      OUTPUT_QUOTED_STRING (STREAM, STRING)
      ASM_OUTPUT_SOURCE_LINE (STREAM, LINE)
      ASM_OUTPUT_IDENT (STREAM, STRING)
      OBJC_PROLOGUE
      - Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
          unsigned int FLAGS, unsigned int ALIGN)
      - Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
      - Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
          const char *NAME, int RELOC)

3.3.2.2 Output of Data

      - Target Hook: const char * TARGET_ASM_BYTE_OP
      - Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
      - Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
      - Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
      - Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
      - Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
      - Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
      - Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
      - Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
      - Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
          ALIGNED_P)
      OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
      ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
      ASM_OUTPUT_FDESC (STREAM, DECL, N)
      CONSTANT_POOL_BEFORE_FUNCTION
      ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
      ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, JUMPTO)
      CONSTANT_AFTER_FUNCTION_P (EXP)
      ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
      IS_ASM_LOGICAL_LINE_SEPARATOR (C)
      - Target Hook: const char * TARGET_ASM_CLOSE_PAREN
      REAL_VALUE_TO_TARGET_SINGLE (X, L)
      REAL_VALUE_TO_TARGET_DOUBLE (X, L)
      REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)

3.3.2.3 Output of Uninitialized Variables

      ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
      ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
      ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, ALIGNMENT)
      ASM_OUTPUT_SHARED_COMMON (STREAM, NAME, SIZE, ROUNDED)
      ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
      ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
      ASM_OUTPUT_SHARED_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
      ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
      ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
      ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, ALIGNMENT)
      ASM_OUTPUT_SHARED_LOCAL (STREAM, NAME, SIZE, ROUNDED)

3.3.2.4 Output and Generation of Labels

      ASM_OUTPUT_LABEL (STREAM, NAME)
      SIZE_ASM_OP
      ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
      ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
      TYPE_ASM_OP
      TYPE_OPERAND_FMT
      ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
      ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
      ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
      ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
      ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE)
      ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
      ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
      - Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
          char *NAME)
      ASM_WEAKEN_LABEL (STREAM, NAME)
      ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
      SUPPORTS_WEAK
      MAKE_DECL_ONE_ONLY
      SUPPORTS_ONE_ONLY
      - Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL,
               const char *VISIBILITY)
      ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
      ASM_OUTPUT_EXTERNAL_LIBCALL (STREAM, SYMREF)
      ASM_OUTPUT_LABELREF (STREAM, NAME)
      ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
      ASM_OUTPUT_LABEL_REF (STREAM, BUF)
      ASM_OUTPUT_INTERNAL_LABEL (STREAM, PREFIX, NUM)
      ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
      ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
      ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
      ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
      ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, DECL_OF_VALUE)
      ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
      OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, SEL_NAME)
      ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
      ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)

3.3.2.5 How Initialization Functions Are Handled

3.3.2.6 Macros Controlling Initialization Routines

      INIT_SECTION_ASM_OP
      HAS_INIT_SECTION
      LD_INIT_SWITCH
      LD_FINI_SWITCH
      COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
      COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
      INVOKE__main
      SUPPORTS_INIT_PRIORITY
      - Target Hook: bool TARGET_HAVE_CTORS_DTORS
      - Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
      - Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
      OBJECT_FORMAT_COFF
      OBJECT_FORMAT_ROSE
      REAL_NM_FILE_NAME
      LDD_SUFFIX
      PARSE_LDD_OUTPUT (PTR)

3.3.2.7 Output of Assembler Instructions

      REGISTER_NAMES
      ADDITIONAL_REGISTER_NAMES
      ASM_OUTPUT_OPCODE (STREAM, PTR)
      FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
      FINAL_PRESCAN_LABEL
      PRINT_OPERAND (STREAM, X, CODE)
      PRINT_OPERAND_PUNCT_VALID_P (CODE)
      PRINT_OPERAND_ADDRESS (STREAM, X)
      DBR_OUTPUT_SEQEND(FILE)
      REGISTER_PREFIX
      LOCAL_LABEL_PREFIX
      USER_LABEL_PREFIX
      IMMEDIATE_PREFIX
      ASM_FPRINTF_EXTENSIONS(FILE, ARGPTR, FORMAT)
      ASSEMBLER_DIALECT
      ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
      ASM_OUTPUT_REG_POP (STREAM, REGNO)

3.3.2.8 Output of Dispatch Tables

      ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
      ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
      ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
      ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)

3.3.2.9 Assembler Commands for Exception Regions

      EH_FRAME_SECTION_NAME
      EH_FRAME_IN_DATA_SECTION
      MASK_RETURN_ADDR
      DWARF2_UNWIND_INFO
      DWARF_CIE_DATA_ALIGNMENT
      - Target Hook: void TARGET_ASM_EXCEPTION_SECTION ()
      - Target Hook: void TARGET_ASM_EH_FRAME_SECTION ()
      - Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO

3.3.2.10 Assembler Commands for Alignment

      JUMP_ALIGN (LABEL)
      LABEL_ALIGN_AFTER_BARRIER (LABEL)
      LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
      LOOP_ALIGN (LABEL)
      LOOP_ALIGN_MAX_SKIP
      LABEL_ALIGN (LABEL)
      LABEL_ALIGN_MAX_SKIP
      ASM_OUTPUT_SKIP (STREAM, NBYTES)
      ASM_NO_SKIP_IN_TEXT
      ASM_OUTPUT_ALIGN (STREAM, POWER)
      ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
      ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)

3.3.3 Controlling Debugging Information Format

3.3.3.1 Macros Affecting All Debugging Formats

      DBX_REGISTER_NUMBER (REGNO)
      DEBUGGER_AUTO_OFFSET (X)
      DEBUGGER_ARG_OFFSET (OFFSET, X)
      PREFERRED_DEBUGGING_TYPE

3.3.3.2 Specific Options for DBX Output

      DBX_DEBUGGING_INFO
      XCOFF_DEBUGGING_INFO
      DEFAULT_GDB_EXTENSIONS
      DEBUG_SYMS_TEXT
      ASM_STABS_OP
      ASM_STABD_OP
      ASM_STABN_OP
      DBX_NO_XREFS
      DBX_CONTIN_LENGTH
      DBX_CONTIN_CHAR
      DBX_STATIC_STAB_DATA_SECTION
      DBX_TYPE_DECL_STABS_CODE
      DBX_STATIC_CONST_VAR_CODE
      DBX_REGPARM_STABS_CODE
      DBX_REGPARM_STABS_LETTER
      DBX_MEMPARM_STABS_LETTER
      DBX_FUNCTION_FIRST
      DBX_LBRAC_FIRST
      DBX_BLOCKS_FUNCTION_RELATIVE
      DBX_USE_BINCL

3.3.3.3 Open-Ended Hooks for DBX Format

      DBX_OUTPUT_LBRAC (STREAM, NAME)
      DBX_OUTPUT_RBRAC (STREAM, NAME)
      DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
      DBX_OUTPUT_ENUM (STREAM, TYPE)
      DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)
      DBX_OUTPUT_STANDARD_TYPES (SYMS)
      NO_DBX_FUNCTION_END

3.3.3.4 File Names in DBX Format

      DBX_WORKING_DIRECTORY
      DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
      DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)
      DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
      DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)

3.3.3.5 Macros for SDB and DWARF Output

      SDB_DEBUGGING_INFO
      DWARF_DEBUGGING_INFO
      DWARF2_DEBUGGING_INFO
      DWARF2_FRAME_INFO
      LINKER_DOES_NOT_WORK_WITH_DWARF2
      DWARF2_GENERATE_TEXT_SECTION_LABEL
      DWARF2_ASM_LINE_DEBUG_INFO
      ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
      ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL)
      ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
      PUT_SDB_...
      SDB_DELIM
      SDB_GENERATE_FAKE
      SDB_ALLOW_UNKNOWN_REFERENCES
      SDB_ALLOW_FORWARD_REFERENCES

3.3.3.6 Macros for VMS Debug Format

      VMS_DEBUGGING_INFO

3.4 Target Compiler Operation Related

These are used to specify the behaviour of the compiler when built. A number of aspects of the behaviour are specifiable here. Aspects like operation environment (e.g. search paths for files and libraries to be included), target specific command line switches of the compiler etc. are specified.

3.4.1 Controlling the Compilation Driver gcc

      SWITCH_TAKES_ARG (CHAR)
      WORD_SWITCH_TAKES_ARG (NAME)
      SWITCH_CURTAILS_COMPILATION (CHAR)
      SWITCHES_NEED_SPACES
      TARGET_OPTION_TRANSLATE_TABLE
      DRIVER_SELF_SPECS
      CPP_SPEC
      CPLUSPLUS_CPP_SPEC
      CC1_SPEC
      CC1PLUS_SPEC
      ASM_SPEC
      ASM_FINAL_SPEC
      LINK_SPEC
      LIB_SPEC
      LIBGCC_SPEC
      STARTFILE_SPEC
      ENDFILE_SPEC
      THREAD_MODEL_SPEC
      EXTRA_SPECS
      LINK_LIBGCC_SPECIAL
      LINK_LIBGCC_SPECIAL_1
      LINK_GCC_C_SEQUENCE_SPEC
      LINK_COMMAND_SPEC
      LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
      MULTILIB_DEFAULTS
      RELATIVE_PREFIX_NOT_LINKDIR
      STANDARD_EXEC_PREFIX
      MD_EXEC_PREFIX
      STANDARD_STARTFILE_PREFIX
      MD_STARTFILE_PREFIX
      MD_STARTFILE_PREFIX_1
      INIT_ENVIRONMENT
      LOCAL_INCLUDE_DIR
      MODIFY_TARGET_NAME
      SYSTEM_INCLUDE_DIR
      STANDARD_INCLUDE_DIR
      STANDARD_INCLUDE_COMPONENT
      INCLUDE_DEFAULTS

3.4.2 Run-time Target Specification

      TARGET_CPU_CPP_BUILTINS()
      TARGET_OS_CPP_BUILTINS()
      CPP_PREDEFINES
      extern int target_flags;
      TARGET_...
      TARGET_SWITCHES
      TARGET_OPTIONS
      TARGET_VERSION
      OVERRIDE_OPTIONS
      OPTIMIZATION_OPTIONS (LEVEL, SIZE)
      CAN_DEBUG_WITHOUT_FP

3.4.3 Adjusting the Instruction Scheduler

      - Target Hook: int 
                     TARGET_SCHED_ISSUE_RATE 
                     (void)
      - Target Hook: int 
                     TARGET_SCHED_VARIABLE_ISSUE 
                     (FILE *FILE, int VERBOSE, rtx INSN, int MORE)
      - Target Hook: int 
                     TARGET_SCHED_ADJUST_COST 
                     (rtx INSN, rtx LINK, rtx DEP_INSN, int COST)
      - Target Hook: int 
                     TARGET_SCHED_ADJUST_PRIORITY 
                     (rtx INSN, int PRIORITY)
      - Target Hook: int 
                     TARGET_SCHED_REORDER 
                     (FILE *FILE, int VERBOSE, rtx *READY, 
                      int *N_READYP, int CLOCK)
      - Target Hook: int 
                     TARGET_SCHED_REORDER2 
                     (FILE *FILE, int VERBOSE, rtx *READY, 
                     int *N_READY, CLOCK)
      - Target Hook: void 
                     TARGET_SCHED_INIT 
                     (FILE *FILE, int VERBOSE, int MAX_READY)
      - Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
      - Target Hook: int TARGET_SCHED_USE_DFA_PIPELINE_INTERFACE (void)
      - Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
      - Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
      - Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
      - Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
      - Target Hook: int 
                     TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
                     (void)
      - Target Hook: void TARGET_SCHED_INIT_DFA_BUBBLES (void)
      - Target Hook: rtx TARGET_SCHED_DFA_BUBBLE (int INDEX)
      TRADITIONAL_PIPELINE_INTERFACE
      DFA_PIPELINE_INTERFACE
      MAX_DFA_ISSUE_RATE

3.5 Where do I put these ?

3.5.1 The Global targetm Variable

      - Variable: struct gcc_target targetm;

3.5.2 Defining data structures for per-function information

      INIT_EXPANDERS
      init_machine_status

3.5.3 Implementing the Varargs Macros

      __builtin_saveregs ()
      __builtin_args_info (CATEGORY)
      __builtin_next_arg (LASTARG)
      __builtin_classify_type (OBJECT)
      EXPAND_BUILTIN_SAVEREGS ()
      SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)
      STRICT_ARGUMENT_NAMING
      PRETEND_OUTGOING_VARARGS_NAMED

3.5.4 Cross Compilation and Floating Point

      - Macro: REAL_VALUE_TYPE
      - Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
      - Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
      - Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
      - Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
          (REAL_VALUE_TYPE X)
      - Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
          machine_mode MODE)
      - Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
      - Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
      - Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
      - Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
          CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
      - Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
      - Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
      - Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
          enum machine_mode X)
      - Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
          HIGH, REAL_VALUE_TYPE X)
      - Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
          LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)

3.5.5 Mode Switching Instructions

      OPTIMIZE_MODE_SWITCHING (ENTITY)
      NUM_MODES_FOR_MODE_SWITCHING
      MODE_NEEDED (ENTITY, INSN)
      NORMAL_MODE (ENTITY)
      MODE_PRIORITY_TO_MODE (ENTITY, N)
      EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)

3.5.6 Defining target-specific uses of `__attribute__'

      - Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
      - Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree TYPE2)
      - Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
      - Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
          TYPE2)
      - Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
          NEWDECL)
      - Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
          *ATTR_PTR)
      - Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree FNDECL)

3.5.7 Defining coprocessor specifics for MIPS targets

      ALL_COP_ADDITIONAL_REGISTER_NAMES

3.5.8 Miscellaneous Parameters

      PREDICATE_CODES
      SPECIAL_MODE_PREDICATES
      CASE_VECTOR_MODE
      CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
      CASE_VECTOR_PC_RELATIVE
      CASE_DROPS_THROUGH
      CASE_VALUES_THRESHOLD
      WORD_REGISTER_OPERATIONS
      LOAD_EXTEND_OP (MODE)
      SHORT_IMMEDIATES_SIGN_EXTEND
      FIXUNS_TRUNC_LIKE_FIX_TRUNC
      MOVE_MAX
      MAX_MOVE_MAX
      SHIFT_COUNT_TRUNCATED
      TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)
      STORE_FLAG_VALUE
      FLOAT_STORE_FLAG_VALUE (MODE)
      Pmode
      FUNCTION_MODE
      INTEGRATE_THRESHOLD (DECL)
      STDC_0_IN_SYSTEM_HEADERS
      NO_IMPLICIT_EXTERN_C
      HANDLE_PRAGMA (GETC, UNGETC, NAME)
      REGISTER_TARGET_PRAGMAS (PFILE)
      HANDLE_SYSV_PRAGMA
      HANDLE_PRAGMA_PACK_PUSH_POP
      DOLLARS_IN_IDENTIFIERS
      NO_DOLLAR_IN_LABEL
      NO_DOT_IN_LABEL
      DEFAULT_MAIN_RETURN
      NEED_ATEXIT
      ON_EXIT
      EXIT_BODY
      INSN_SETS_ARE_DELAYED (INSN)
      INSN_REFERENCES_ARE_DELAYED (INSN)
      MACHINE_DEPENDENT_REORG (INSN)
      MULTIPLE_SYMBOL_SPACES
      MD_ASM_CLOBBERS (CLOBBERS)
      MAX_INTEGER_COMPUTATION_MODE
      MATH_LIBRARY
      LIBRARY_PATH_ENV
      TARGET_HAS_F_SETLKW
      MAX_CONDITIONAL_EXECUTE
      IFCVT_MODIFY_TESTS(CE_INFO, TRUE_EXPR, FALSE_EXPR)
      IFCVT_MODIFY_MULTIPLE_TESTS(CE_INFO, BB, TRUE_EXPR, FALSE_EXPR)
      IFCVT_MODIFY_INSN(CE_INFO, PATTERN, INSN)
      IFCVT_MODIFY_FINAL(CE_INFO)
      IFCVT_MODIFY_CANCEL(CE_INFO)
      IFCVT_INIT_EXTRA_FIELDS(CE_INFO)
      IFCVT_EXTRA_FIELDS
      - Target Hook: void TARGET_INIT_BUILTINS ()
      - Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
          SUBTARGET, enum machine_mode MODE, int IGNORE)
      MD_CAN_REDIRECT_BRANCH(BRANCH1, BRANCH2)
      ALLOCATE_INITIAL_VALUE(HARD_REG)
      TARGET_OBJECT_SUFFIX
      TARGET_EXECUTABLE_SUFFIX
      COLLECT_EXPORT_LIST
      MODIFY_JNI_METHOD_CALL (MDECL)
      - Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)

4 Classifying RTLs

The GCC RTXs are classified into two major categories (are these disjoint ?) as:

  1. RTXs used to describe machines,
  2. RTXs used to represent actual code

Both these RTXs are listed in rtl.def.

4.1 Machine Description RTXs

The following macros are described first and then a few details are listed. These appear only in the machine description unless stated otherwise.

4.1.1 DEFINE constructs

The DEFINE constructs would be used to introduce information into the machine description.

DEFINE_INSN: Defines the pattern for one kind of instruction.

DEFINE_PEEPHOLE: Definition of a peephole optimization.

DEFINE_SPLIT: Definition of a split operation.

DEFINE_INSN_AND_SPLIT: Definition of an insn and associated split. This is the concatenation, with a few modifications, of a define_insn and a define_split which share the same pattern.

DEFINE_PEEPHOLE2: Definition of an RTL peephole operation. Follows the same arguments as define_split.

DEFINE_COMBINE: Definition of a combiner pattern. Operands not defined yet.

DEFINE_EXPAND: Define how to generate multiple insns for a standard insn name.

DEFINE_DELAY: Define a requirement for delay slots.

DEFINE_FUNCTION_UNIT: Define a set of insns that requires a function unit. This means that these insns produce their result after a delay and that there may be restrictions on the number of insns of this type that can be scheduled simultaneously. More than one DEFINE_FUNCTION_UNIT can be specified for a function unit. Each gives a set of operations and associated delays. The first three operands must be the same for each operation for the same function unit. All delays are specified in cycles.

DEFINE_ASM_ATTRIBUTES: Define attribute computation for `asm' instructions.

DEFINE_COND_EXEC: 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.

4.1.2 MATCH constructs

The MATCH constructs would be used during the pattern matching phase. There would be two matching phases: AST $\rightarrow$ RTL (the generation of RTL from the AST) phase, and the RTL $\rightarrow$ Target-ASM (the generation of the target ASM code) phase. We need to determine which of the following are used when.

MATCH_OPERAND: Means use the function named by the second arg (the string) as a predicate; if matched, store the structure that was matched in the operand table at index specified by the first arg (the integer). If the second arg is the null string, the structure is just stored.

MATCH_SCRATCH: Means match a SCRATCH or a register. When used to generate rtl, a SCRATCH is generated. As for MATCH_OPERAND, the mode specifies the desired mode and the first argument is the operand number. The second argument is the constraint.

MATCH_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument.

MATCH_OPERATOR: Means apply a predicate, AND match recursively the operands of the rtx.

MATCH_PARALLEL: Means to match a PARALLEL of arbitrary length. The predicate is applied to the PARALLEL and the initial expressions in the PARALLEL are matched.

MATCH_OP_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument. For MATCH_OPERATOR.

MATCH_PAR_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument. For MATCH_PARALLEL.

MATCH_INSN: Operand 0 is the operand number, as in match_operand. Operand 1 is the predicate to apply to the insn.

4.1.3 CPU PIPELINE constructs

Constructions for CPU pipeline description described by NDFAs. These do not appear in actual rtl code in the compiler. (SACHIN!)

DEFINE_CPU_UNIT: (define_cpu_unit string [string]) describes cpu functional units (separated by comma). All define_reservations, define_cpu_units, and define_query_cpu_units should have unique names which may not be "nothing".

DEFINE_QUERY_CPU_UNIT: (define_query_cpu_unit string [string]): describes cpu functional units analogously to define_cpu_unit. If we use automaton without minimization, the reservation of such units can be queried for automaton state.

EXCLUSION_SET: (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.

PRESENCE_SET: (presence_set string string) means that each CPU functional unit in the first string can not be reserved unless at least one of units whose names are in the second string is reserved. This is an asymmetric relation. CPU units in the string are separated by commas. For example, it is useful for description that slot1 is reserved after slot0 reservation for VLIW processor. All CPU functional units in a set should belong the same automaton.

ABSENCE_SET: (absence_set string string) means that each CPU functional unit in the first string can not be reserved only if each unit whose name is in the second string is not reserved. This is an asymmetric relation (actually exclusion set is analogous to this one but it is symmetric). CPU units in the string are separated by commas. For example, it is useful for description that slot0 can not be reserved after slot1 or slot2 reservation for VLIW processor. All CPU functional units in a set should belong the same automaton.

DEFINE_BYPASS: (define_bypass number out_insn_names in_insn_names) names bypass with given latency (the first number) from insns given by the first string (see define_insn_reservation) into insns given by the second string. Insn names in the strings are separated by commas. The third operand is optional name of function which is additional guard for the bypass. The function will get the two insns as parameters. If the function returns zero the bypass will be ignored for this case. Additional guard is necessary to recognize complicated bypasses, e.g. when consumer is load address.

DEFINE_AUTOMATON: (define_automaton string) describes names of automata generated and used for pipeline hazards recognition. The names are separated by comma. Actually it is possibly to generate the single automaton but unfortunately it can be very large. If we use more one automata, the summary size of the automata usually is less than the single one. The automaton name is used in define_cpu_unit and define_query_cpu_unit. All automata should have unique names.

AUTOMATA_OPTION: (automata_option string) describes option for generation of automata.

DEFINE_RESERVATION: (define_reservation string string) names reservation (the first string) of cpu functional units (the 2nd string). Sometimes unit reservations for different insns contain common parts. In such case, you can describe common part and use its name (the 1st parameter) in regular expression in define_insn_reservation. All define_reservations, define_cpu_units, and define_query_cpu_units should have unique names which may not be "nothing".

DEFINE_INSN_RESERVATION: (define_insn_reservation name default_latency condition regexpr) describes reservation of cpu functional units (the 3nd operand) for instruction which is selected by the condition (the 2nd parameter). The first parameter is used for output of debugging information. The reservations are described by a regular expression according the a syntax.

4.1.4 INSN Attributes constructs

DEFINE_ATTR: Definition of an insn attribute.

ATTR: Marker for the name of an attribute.

SET_ATTR: For use in the last (optional) operand of DEFINE_INSN or DEFINE_PEEPHOLE and in DEFINE_ASM_INSN to specify an attribute to assign to insns matching that pattern.
(set_attr "name" "value") is equivalent to (set (attr "name") (const_string "value"))

SET_ATTR_ALTERNATIVE: In the last operand of DEFINE_INSN and DEFINE_PEEPHOLE, this can be used to specify that attribute values are to be assigned according to the alternative matched.

EQ_ATTR: A conditional expression true if the value of the specified attribute of the current insn equals the specified value.

ATTR_FLAG: A conditional expression which is true if the specified flag is true for the insn being scheduled in reorg.
genattr.c defines the following flags which can be tested by (attr_flag "foo") expressions in eligible_for_delay.
forward, backward, very_likely, likely, very_unlikely, and unlikely.

4.1.5 Miscellaneous constructs

I could not put these in one of the above. Neither could I precisely express their existence. Something is unknown to me about the following, so for the moment they are classified as ``MISCELLANEOUS''.

SEQUENCE: SEQUENCE appears in the result of a `gen_...' function for a DEFINE_EXPAND that wants to make several insns. Its elements are the bodies of the insns that should be made. `emit_insn' takes the SEQUENCE apart and makes separate insns.

ADDRESS: Refers to the address of its argument. This is only used in alias.c.

4.2 Source Program Representation RTXs

These are expressions used for structuring the RTL representation of an input program to the target compiler that will be built. Expression definitions and descriptions for all targets are here. Some may not be used/useful for some targets. Using genflags, GCC establishes which of the following rtxs does the target machine support.

4.2.1 Expressions used in constructing lists.

EXPR_LIST: A linked list of expressions

INSN_LIST: A linked list of instructions. The insns are represented in print by their uids.

4.2.2 Expression types used for things in the instruction chain.

All formats must start with "iuu" to handle the chain. Each insn expression holds an rtl instruction and its semantics during back-end processing. See macros in "rtl.h" for the meaning of each rtx-$>$fld[]. We further classify them into a few kinds of instructions. Some ``instructions'' represent actual machine code, the others influence the machine code generation (e.g. PARALLEL).

4.2.2.1 Actual Machine Code

These are actual machine instructions.

4.2.2.1.1 General Machine Instructions

INSN: An instruction that cannot jump.

JUMP_INSN: An instruction that can possibly jump. Fields ( rtx-$>$fld[] ) have exact same meaning as INSN's.

CALL_INSN: An instruction that can possibly call a subroutine but which will not change which instruction comes next in the current function.

CALL: Call a subroutine. Operand 1 is the address to call. Operand 2 is the number of arguments.

RETURN: Return from a subroutine.

SET: Assignment. ALL assignment must use SET. Instructions that do multiple assignments must use multiple SET, under PARALLEL.

IF_THEN_ELSE: if_then_else. This is used in representing ordinary conditional jump instructions.

COND: General conditional. The first operand is a vector composed of pairs of expressions. The first element of each pair is evaluated, in turn. The value of the conditional is the second expression of the first pair whose first expression evaluates nonzero. If none of the expressions is true, the second operand will be used as the value of the conditional. This should be replaced with use of IF_THEN_ELSE.

4.2.2.1.2 Output Target ASM lines

ASM_INPUT: A string that is passed through to the assembler as input. One can obviously pass comments through by using the assembler comment syntax. These occur in an insn all by themselves as the PATTERN. They also appear inside an ASM_OPERANDS as a convenient way to hold a string.

ASM_OPERANDS: An assembler instruction with operands.

LABEL_REF: Reference to an assembler label in the code for this function. The operand is a CODE_LABEL found in the insn chain. The unprinted fields 1 and 2 are used in flow.c for the LABEL_NEXTREF and CONTAINING_INSN.

SYMBOL_REF: Reference to a named label: the string that is the first operand, with `_' added implicitly in front. Exception: if the first character explicitly given is `*', to give it to the assembler, remove the `*' and do not add `_'.

4.2.2.1.3 (Core) Memory Related

ADDR_VEC: Vector of addresses, stored as full words. Each element is a LABEL_REF to a CODE_LABEL whose address we want.

ADDR_DIFF_VEC: Vector of address differences X0 - BASE, X1 - BASE, ...

PREFETCH: Memory prefetch, with attributes supported on some targets.

MEM: A memory location; operand is the address. The second operand is the alias set to which this MEM belongs. We use `0' instead of `w' for this field so that the field need not be specified in machine descriptions.

4.2.2.1.4 Data Representation Related

CONST_INT: Numeric integer constant

CONST_DOUBLE: Numeric floating point constant.

CONST_VECTOR: Describes a vector constant.

CONST_STRING: String constant. Used only for attributes right now.

CONST: This is used to encapsulate an expression whose value is constant (such as the sum of a SYMBOL_REF and a CONST_INT) so that it will be recognized as a constant operand rather than by arithmetic instructions.

4.2.2.1.5 Generic Objects

PC: Program Counter. Ordinary jumps are represented by a SET whose first operand is (PC).

VALUE: Used in the cselib routines to describe a value.

REG: A register. The "operand" is the register number, accessed with the REGNO macro. If this number is less than FIRST_PSEUDO_REGISTER than a hardware register is being referred to. The second operand holds the original register number - this will be different for a pseudo register that got turned into a hard register. This rtx needs to have as many (or more) fields as a MEM, since we can change REG rtx's into MEMs during reload.

SCRATCH: A scratch register. This represents a register used only within a single insn. It will be turned into a REG during register allocation or reload unless the constraint indicates that the register won't be needed, in which case it can remain a SCRATCH. This code is marked as having one operand so it can be turned into a REG.

SUBREG: One word of a multi-word value. The first operand is the complete value; the second says which word. The WORDS_BIG_ENDIAN flag controls whether word number 0 (as numbered in a SUBREG) is the most or least significant word. This is also used to refer to a value in a different machine mode. For example, it can be used to refer to a SImode value as if it were Qimode, or vice versa. Then the word number is always 0.

STRICT_LOW_PART: This one-argument rtx is used for move instructions that are guaranteed to alter only the low part of a destination. Thus, (SET (SUBREG:HI (REG...)) (MEM:HI ...)) has an unspecified effect on the high part of REG, but (SET (STRICT_LOW_PART (SUBREG:HI (REG...))) (MEM:HI ...)) is guaranteed to alter only the bits of REG that are in HImode. The actual instruction used is probably the same in both cases, but the register constraints may be tighter when STRICT_LOW_PART is in use.

CC0: 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.

4.2.2.1.6 Arithmetic Operations

PLUS: plus

MINUS: Operand 0 minus operand 1.

NEG: Minus operand 0.

MULT

DIV: Operand 0 divided by operand 1.

MOD: Remainder of operand 0 divided by operand 1.

UDIV: Unsigned divide and remainder.

UMOD:

: Operand: 0: value to be shifted. 1: number of bits.

ASHIFT: shift left

ROTATE: rotate left

ASHIFTRT: arithmetic shift right

LSHIFTRT: logical shift right

ROTATERT: rotate right

SMIN: Minimum and maximum values of two operands. We need both signed and unsigned forms. (We cannot use MIN for SMIN because it conflicts with a macro of the same name.)

SMAX:

UMIN:

UMAX:

SIGN_EXTEND: Represents the result of sign-extending the sole operand. The machine modes of the operand and of the SIGN_EXTEND expression determine how much sign-extension is going on.

ZERO_EXTEND: Similar for zero-extension (such as unsigned short to int).

TRUNCATE: Similar but here the operand has a wider mode.

FLOAT_EXTEND: Similar for extending floating-point values (such as SFmode to DFmode).

FLOAT_TRUNCATE:

FLOAT: Conversion of fixed point operand to floating point value.

FIX: With fixed-point machine mode: Conversion of floating point operand to fixed point value. Value is defined only when the operand's value is an integer. With floating-point machine mode (and operand with same mode): Operand is rounded toward zero to produce an integer value represented in floating point.

UNSIGNED_FLOAT: Conversion of unsigned fixed point operand to floating point value.

UNSIGNED_FIX: With fixed-point machine mode: Conversion of floating point operand to *unsigned* fixed point value. Value is defined only when the operand's value is an integer.

ABS: Absolute value

SQRT: Square root

FFS: Find first bit that is set. Value is 1 + number of trailing zeros in the arg., or 0 if arg is 0.

SIGN_EXTRACT: Reference to a signed bit-field of specified size and position. Operand 0 is the memory unit (usually SImode or QImode) which contains the field's first bit. Operand 1 is the width, in bits. Operand 2 is the number of bits in the memory unit before the first bit of this field. If BITS_BIG_ENDIAN is defined, the first bit is the msb and operand 2 counts from the msb of the memory unit. Otherwise, the first bit is the lsb and operand 2 counts from the lsb of the memory unit.

ZERO_EXTRACT: Similar for unsigned bit-field.

: For RISC machines. These save memory when splitting insns. HIGH: HIGH are the high-order bits of a constant expression.

LO_SUM: LO_SUM is the sum of a register and the low-order bits of a constant expression.

SS_PLUS: Addition with signed saturation

US_PLUS: Addition with unsigned saturation

SS_MINUS: Operand 0 minus operand 1, with signed saturation.

US_MINUS: Operand 0 minus operand 1, with unsigned saturation.

SS_TRUNCATE: Signed saturating truncate.

US_TRUNCATE: Unsigned saturating truncate.

4.2.2.1.7 Logical Operations

COMPARE: Comparison, produces a condition code result.

AND: Bitwise operations.

IOR:

XOR:

NOT:

NE: Comparison operations. The ordered comparisons exist in two flavors, signed and unsigned.

EQ:

GE:

GT:

LE:

LT:

GEU:

GTU:

LEU:

LTU:

UNORDERED: Additional floating point unordered comparision flavors.

ORDERED:

UNEQ: These are equivalent to unordered or ...

UNGE:

UNGT:

UNLE:

UNLT:

LTGT: This is an ordered NE, ie !UNEQ, ie false for NaN.

4.2.2.1.8 Unary Operations

: These unary operations are used to represent incrementation and decrementation as they occur in memory addresses. The amount of increment or decrement are not represented because they can be understood from the machine-mode of the containing MEM. These operations exist in only two cases:
1. pushes onto the stack.
2. created automatically by the life_analysis pass in flow.c.

PRE_DEC:

PRE_INC:

POST_DEC:

POST_INC:

4.2.2.1.9 Binary Operations

: These binary operations are used to represent generic address side-effects in memory addresses, except for simple incrementation or decrementation which use the above operations. They are created automatically by the life_analysis pass in flow.c. The first operand is a REG which is used as the address. The second operand is an expression that is assigned to the register, either before (PRE_MODIFY) or after (POST_MODIFY) evaluating the address.
Currently, the compiler can only handle second operands of the form (plus (reg) (reg)) and (plus (reg) (const_int)), where the first operand of the PLUS has to be the same register as the first operand of the *_MODIFY.

PRE_MODIFY:

POST_MODIFY:

4.2.2.1.10 None-of-the-above kind

PHI: The SSA phi operator.
The argument is a vector of 2N rtxes. Element 2N+1 is a CONST_INT containing the block number of the predecessor through which control has passed when the register at element 2N is used.
Note that PHI may only appear at the beginning of a basic block.
Issue: There may be multiple PHI insns, but they are all evaluated in parallel. This probably ought to be changed to use a real PARALLEL, as that would be less confusing and more in the spirit of canonical RTL. It is, however, easier to manipulate this way.

UNSPEC: A machine-specific operation.

UNSPEC_VOLATILE: Similar, but a volatile operation and one which may trap.

4.2.2.2 Instructions for Machine Code Generation

These are hints to the machine code generator system of GCC. They are arbitrarily classified and at times it is unclear as to which particular category they ought to belong.

4.2.2.2.1 Control Flow related

BARRIER: A marker that indicates that control will not flow through.

COND_EXEC: Conditionally execute code.

PARALLEL: Several operations to be done in parallel (perhaps under COND_EXEC).

4.2.2.2.2 Comments, Notes etc.

NOTE: Say where in the code a source line starts, for symbol table's sake.

USE: Indicate something is used in a way that we don't want to explain. For example, subroutine calls will use the register in which the static chain is passed.

CLOBBER: Indicate something is clobbered in a way that we don't want to explain. For example, subroutine calls will clobber some physical registers (the ones that are by convention not saved).

QUEUED: 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.

CALL_PLACEHOLDER: A placeholder for a CALL_INSN which may be turned into a normal call, a sibling (tail) call or tail recursion. Immediately after RTL generation, this placeholder will be replaced by the insns to perform the call, sibcall or tail recursion.

4.2.2.2.3 Symbol or Value Manipulators

CONCAT: (CONCAT a b) represents the virtual concatenation of a and b to make a value that has as many bits as a and b put together. This is used for complex values. Normally it appears only in DECL_RTLs and during RTL generation, but not in the insn chain.

CONSTANT_P_RTX: A unary `__builtin_constant_p' expression. These are only emitted during RTL generation, and then only if optimize $>$ 0. They are eliminated by the first CSE pass.

4.2.2.2.4 Information Recorders

ADDRESSOF: 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.

CODE_LABEL: Holds a label that is followed by instructions.

RANGE_INFO: Header for range information. Operand 0 is the NOTE_INSN_RANGE_BEG insn. Operand 1 is the NOTE_INSN_RANGE_END insn. Operand 2 is a vector of all of the registers that can be substituted within this range. Operand 3 is the number of calls in the range. Operand 4 is the number of insns in the range. Operand 5 is the unique range number for this range. Operand 6 is the basic block # of the start of the live range. Operand 7 is the basic block # of the end of the live range. Operand 8 is the loop depth. Operand 9 is a bitmap of the registers live at the start of the range. Operand 10 is a bitmap of the registers live at the end of the range. Operand 11 is marker number for the start of the range. Operand 12 is the marker number for the end of the range.

RANGE_REG: Registers that can be substituted within the range. Operand 0 is the original pseudo register number. Operand 1 will be filled in with the pseudo register the value is copied for the duration of the range. Operand 2 is the number of references within the range to the register. Operand 3 is the number of sets or clobbers of the register in the range. Operand 4 is the number of deaths the register has. Operand 5 is the copy flags that give the status of whether a copy is needed from the original register to the new register at the beginning of the range, or whether a copy from the new register back to the original at the end of the range. Operand 6 is the live length. Operand 7 is the number of calls that this register is live across. Operand 8 is the symbol node of the variable if the register is a user variable. Operand 9 is the block node that the variable is declared in if the register is a user variable.

RANGE_VAR: Information about a local variable's ranges. Operand 0 is an EXPR_LIST of the different ranges a variable is in where it is copied to a different pseudo register. Operand 1 is the block that the variable is declared in. Operand 2 is the number of distinct ranges.

RANGE_LIVE: Information about the registers that are live at the current point. Operand 0 is the live bitmap. Operand 1 is the original block number.

VEC_MERGE: Describes a merge operation between two vector values. Operands 0 and 1 are the vectors to be merged, operand 2 is a bitmask that specifies where the parts of the result are taken from. Set bits indicate operand 0, clear bits indicate operand 1. The parts are defined by the mode of the vectors.

VEC_SELECT: Describes an operation that selects parts of a vector. Operands 0 is the source vector, operand 1 is a PARALLEL that contains a CONST_INT for each of the subparts of the result vector, giving the number of the source subpart that should be stored into it.

VEC_CONCAT: Describes a vector concat operation. Operands 0 and 1 are the source vectors, the result is a vector that is as long as operands 0 and 1 combined and is the concatenation of the two source vectors.

VEC_DUPLICATE: Describes an operation that converts a small vector into a larger one by duplicating the input values. The output vector mode must have the same submodes as the input vector mode, and the number of output parts must be an integer multiple of the number of input parts.

4.2.2.3 Where do I place these ?

The following RTXs did not seem to be a part of any of the two above. I need to study them more.

TRAP_IF: Conditional trap. For an unconditional trap, make the condition (const_int 1).

RESX: Placeholder for _Unwind_Resume before we know if a function call or a branch is needed. Operand 1 is the exception region from which control is flowing.

4.2.3 Miscellaneous

UNKNOWN: An expression code name unknown to the reader

NIL: (NIL) is used by rtl reader and printer to represent a null pointer.

INCLUDE: Include a file

5 Standard Pattern Names

Giving one of the following names to an insn tells the RTL generation pass that it can use the pattern to accomplish a certain task.

6 Grammar of the RTL Machine Description Language

6.1 Basic RTL Grammar

Regular Expressions syntax: ``['', ``]'' are used to express sets. ``+'' denotes one or more occurrences of the preceding regexp. ``*'' denotes 0 or more occurrences of the preceding regexp. ``$\vert$'' denotes a choice of one from amongst the many. ``?'' denotes 0 or 1 occurrence of the preceding expression. If the syntax of the RTL uses any of the above characters, then they are escaped by prefixing a ``$\backslash$'' character to them. Thus, for example, since a vector is syntactically represented by enclosing it's members within ``['' and ``]'', we write these characters as ``$\backslash$['' and ``$\backslash$]'' to denote their syntactic use rather than their use for expressing regexps. Keywords are delimited using the ``!'' symbol from cut #2 onwards. Terminals are prefixed by ``='' and upper case does not necessarily imply that the symbol is a terminal - contrary to the convention. Sets of terminal symbols are represented as a $\vert$ separated list of symbols in the standard regexp set notation - i.e. enclosed by ``['' and ``]''. Comments start with the ``#'' symbol and continue till the end of the line.

CUT #2

rtl_source_representation: src_expression*   # Elaborate AFTER basic
                                             # RTL is done.
rtl_md_representation: md_expression*        # Elaborate AFTER basic
                                             # RTL is done.
###
# An RTL expression, rtx, is made up of FIVE objects
###
rtx: int | string | wide int | vector | expression

###
# Our usual integer.  Written form uses decimal digits
###
int: [0-9]+

###
# Like our usual integer, but of type HOST_WIDE_INT.  
# Written form uses decimal digits
###
wide int: ="HOST_WIDE_INT"

###
# A string is a sequence of characters. In core it is represented
# as a char *  in usual C fashion, and it is  written in C syntax
# as  well. However, strings  in RTL  may never  be null.  If you
# write  an  empty  string   in  a  machine  description,  it  is
# represented in core as a  null pointer rather than as a pointer
# to a null character.   In certain contexts, these null pointers
# instead of strings are valid. Within RTL code, strings are most
# commonly found  inside symbol_ref expressions,  but they appear
# in other contexts  in the RTL expressions that  make up machine
# descriptions.
# 
# There is also a special syntax for strings, which can be useful
# when C  code is embedded  in a machine description.  Wherever a
# string can  appear, it is also  valid to write  a C-style brace
# block. The entire brace  block, including the outermost pair of
# braces, is  considered to be the string  constant. Double quote
# characters inside the braces are not special. Therefore, if you
# write string constants in the  C code, you need not escape each
# quote character with a backslash.
###

string: [char]* | \{string\}
char: =[:ASCII - NUL:]
string constant: (string)

###
# A vector contains an arbitrary number of pointers to expressions.
# The number of elements in the vector is explicitly present in
# the vector. The written form of a vector consists of square
# brackets ([...]) surrounding the elements, in sequence and
# with whitespace separating them. Vectors of length zero are
# not created; null pointers are used instead.  
###
vector: NULL_PTR | \[ [expr_ptr WS]+ \]
NULL_PTR: =NULL Pointer
expr_ptr: =Pointer to expression

###
# Our notion of a white space
###
WS: =[\b\t]*

###
# 
###
expr_flag: =[f|j|i|c|u|v|s]

expr_machine_mode: mode_int | mode_partial_int | mode_float |
                   mode_complex_int | mode_complex_float |
                   mode_function | mode_cc | mode_random
mode_int:           =[BImode|QImode|HImode|SImode|DImode|TImode|OImode]
mode_partial_int:   =[PQImode|PHImode|PSImode|PDImode]
mode_float:         =[QFmode|HFmode|TQFmode|SFmode|DFmode|XFmode|TFmode]
mode_complex_int:   =[CQImode|CHImode|CSImode|CDImode|COImode|CTImode]
mode_complex_float: =[QCmode|HCmode,SCmode|DCmode|XCmode|TCmode]
mode_function:
mode_cc:            =[CCmode]
mode_random:        =[VOIDmode|BLKmode]

expression: (nil) | const_expr | regs_mem_expr | arith_expr | 
            comparison_expr | bit_fields_expr | vector_ops_expr | 
            conversion_expr | rtl_decls_expr |  side_effects_expr |
            incdec_expr | assembler_expr | insns_expr
(nil) : NULL_PTR

const_expr: (=const_int int)                                 |
            (=const_double:expr_machine_mode mem_expr i1 i2 ...) |
            (=const_vector:expr_macine_mode [x1 x2 ...])     |
            (=const_string  string)                          |
            (=symbol_ref:PMode symbol)                       |
            (=label_ref label)                               |
            (=const:PMode careful_exp)                       |
            (=high:PMode exp)


expr_op: expr_name[/expr_flag]*[:expr_machine_mode]?

expr_name: const | regs_mem | arith | comparison | bit_fields | 
           vector_ops | conversion | rtl_decls | side_effects |
           incdec | assembler | insns
const: =[const_int|const_double|const_string|const_vector,
        const|symbol_ref|label_ref|high]
regs_mem: =[reg|subreg|cc0|scratch|pc|mem|addressof]
arith: =[plus|lo_sum|minus|ss_plus|us_plus|ss_minus|us_minus,
        compare|neg|mult|div|udiv|mod|umo|smin|smax|umin,
        umax|not|and|ior|xor|ashift|ashiftrt|lshiftrt|rotate,
        rotatert|abs|sqrt|ffs]
comparison: =[eq|ne|gt|gtu|ge|geu|lt|ltu|if_then_else|cond]
bit_fields: =[sign_extract|zero_extract]
vector_ops: =[vec_select|vec_merge|vec_concat|vec_const,
             vec_duplicate]
conversion: =[sign_extend|zero_extend|float_extend|truncate,
             ss_truncate|us_truncate|float_truncate|float,
             unsigned_float|fix|unsigned_fix]
rtl_decls: =[strict_low_part]
side_effects: =[set|return|call|clobber|use|parallel|cond_exec,
               sequence|asm_input|unspec|unspec_volatile|addr_vec,
               addr_diff_vec|prefetch]
incdec: =[pre_dec|pre_inc|post_dec|post_inc|pre_modify,
         post_modify] 
assembler: =[asm_operands]
insns: =[insn|jump_insn|call_insn|code_label|barrier|note]

6.1.1 DEFINE constructs

The DEFINE constructs would be used to introduce information into the machine description.

DEFINE_INSN: Defines the pattern for one kind of instruction.

insn: (define_insn
         {name}
         rtl-template
         c-condition
         output-template
         attribute-values-vector
      )
name: string
rtl-template: rtx vector
c-condition: c-boolean-expression
output-template: output-string
attribute-values-vector: vector

DEFINE_PEEPHOLE: Definition of a peephole optimization.

DEFINE_SPLIT: Definition of a split operation.

DEFINE_INSN_AND_SPLIT: Definition of an insn and associated split. This is the concatenation, with a few modifications, of a define_insn and a define_split which share the same pattern.

DEFINE_PEEPHOLE2: Definition of an RTL peephole operation. Follows the same arguments as define_split.

DEFINE_COMBINE: Definition of a combiner pattern. Operands not defined yet.

DEFINE_EXPAND: Define how to generate multiple insns for a standard insn name.

DEFINE_DELAY: Define a requirement for delay slots.

DEFINE_FUNCTION_UNIT: Define a set of insns that requires a function unit. This means that these insns produce their result after a delay and that there may be restrictions on the number of insns of this type that can be scheduled simultaneously. More than one DEFINE_FUNCTION_UNIT can be specified for a function unit. Each gives a set of operations and associated delays. The first three operands must be the same for each operation for the same function unit. All delays are specified in cycles.

DEFINE_ASM_ATTRIBUTES: Define attribute computation for `asm' instructions.

DEFINE_COND_EXEC: 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.

6.1.2 MATCH constructs

The MATCH constructs would be used during the pattern matching phase. There would be two matching phases: AST $\rightarrow$ RTL (the generation of RTL from the AST) phase, and the RTL $\rightarrow$ Target-ASM (the generation of the target ASM code) phase. We need to determine which of the following are used when.

MATCH_OPERAND: Means use the function named by the second arg (the string) as a predicate; if matched, store the structure that was matched in the operand table at index specified by the first arg (the integer). If the second arg is the null string, the structure is just stored.

MATCH_SCRATCH: Means match a SCRATCH or a register. When used to generate rtl, a SCRATCH is generated. As for MATCH_OPERAND, the mode specifies the desired mode and the first argument is the operand number. The second argument is the constraint.

MATCH_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument.

MATCH_OPERATOR: Means apply a predicate, AND match recursively the operands of the rtx.

MATCH_PARALLEL: Means to match a PARALLEL of arbitrary length. The predicate is applied to the PARALLEL and the initial expressions in the PARALLEL are matched.

MATCH_OP_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument. For MATCH_OPERATOR.

MATCH_PAR_DUP: Means match only something equal to what is stored in the operand table at the index specified by the argument. For MATCH_PARALLEL.

MATCH_INSN: Operand 0 is the operand number, as in match_operand. Operand 1 is the predicate to apply to the insn.

6.1.3 CPU PIPELINE constructs

Constructions for CPU pipeline description described by NDFAs. These do not appear in actual rtl code in the compiler. (SACHIN!)

DEFINE_CPU_UNIT: (define_cpu_unit string [string]) describes cpu functional units (separated by comma). All define_reservations, define_cpu_units, and define_query_cpu_units should have unique names which may not be "nothing".

DEFINE_QUERY_CPU_UNIT: (define_query_cpu_unit string [string]): describes cpu functional units analogously to define_cpu_unit. If we use automaton without minimization, the reservation of such units can be queried for automaton state.

EXCLUSION_SET: (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.

PRESENCE_SET: (presence_set string string) means that each CPU functional unit in the first string can not be reserved unless at least one of units whose names are in the second string is reserved. This is an asymmetric relation. CPU units in the string are separated by commas. For example, it is useful for description that slot1 is reserved after slot0 reservation for VLIW processor. All CPU functional units in a set should belong the same automaton.

ABSENCE_SET: (absence_set string string) means that each CPU functional unit in the first string can not be reserved only if each unit whose name is in the second string is not reserved. This is an asymmetric relation (actually exclusion set is analogous to this one but it is symmetric). CPU units in the string are separated by commas. For example, it is useful for description that slot0 can not be reserved after slot1 or slot2 reservation for VLIW processor. All CPU functional units in a set should belong the same automaton.

DEFINE_BYPASS: (define_bypass number out_insn_names in_insn_names) names bypass with given latency (the first number) from insns given by the first string (see define_insn_reservation) into insns given by the second string. Insn names in the strings are separated by commas. The third operand is optional name of function which is additional guard for the bypass. The function will get the two insns as parameters. If the function returns zero the bypass will be ignored for this case. Additional guard is necessary to recognize complicated bypasses, e.g. when consumer is load address.

DEFINE_AUTOMATON: (define_automaton string) describes names of automata generated and used for pipeline hazards recognition. The names are separated by comma. Actually it is possibly to generate the single automaton but unfortunately it can be very large. If we use more one automata, the summary size of the automata usually is less than the single one. The automaton name is used in define_cpu_unit and define_query_cpu_unit. All automata should have unique names.

AUTOMATA_OPTION: (automata_option string) describes option for generation of automata.

DEFINE_RESERVATION: (define_reservation string string) names reservation (the first string) of cpu functional units (the 2nd string). Sometimes unit reservations for different insns contain common parts. In such case, you can describe common part and use its name (the 1st parameter) in regular expression in define_insn_reservation. All define_reservations, define_cpu_units, and define_query_cpu_units should have unique names which may not be "nothing".

DEFINE_INSN_RESERVATION: (define_insn_reservation name default_latency condition regexpr) describes reservation of cpu functional units (the 3nd operand) for instruction which is selected by the condition (the 2nd parameter). The first parameter is used for output of debugging information. The reservations are described by a regular expression according the a syntax.

6.1.4 INSN Attributes constructs

DEFINE_ATTR: Definition of an insn attribute.

ATTR: Marker for the name of an attribute.

SET_ATTR: For use in the last (optional) operand of DEFINE_INSN or DEFINE_PEEPHOLE and in DEFINE_ASM_INSN to specify an attribute to assign to insns matching that pattern.
(set_attr "name" "value") is equivalent to (set (attr "name") (const_string "value"))

SET_ATTR_ALTERNATIVE: In the last operand of DEFINE_INSN and DEFINE_PEEPHOLE, this can be used to specify that attribute values are to be assigned according to the alternative matched.

EQ_ATTR: A conditional expression true if the value of the specified attribute of the current insn equals the specified value.

ATTR_FLAG: A conditional expression which is true if the specified flag is true for the insn being scheduled in reorg.
genattr.c defines the following flags which can be tested by (attr_flag "foo") expressions in eligible_for_delay.
forward, backward, very_likely, likely, very_unlikely, and unlikely.

6.1.5 Miscellaneous constructs

I could not put these in one of the above. Neither could I precisely express their existence. Something is unknown to me about the following, so for the moment they are classified as ``MISCELLANEOUS''.

SEQUENCE: SEQUENCE appears in the result of a `gen_...' function for a DEFINE_EXPAND that wants to make several insns. Its elements are the bodies of the insns that should be made. `emit_insn' takes the SEQUENCE apart and makes separate insns.

ADDRESS: Refers to the address of its argument. This is only used in alias.c.


7 Useful GCC macros


Table 8: A few useful GCC macros

\begin{tabular}{\vert l\vert l\vert l\vert}
\hline
Macro Name & In File & Purp...
...\
& &
operand number $idx$ of
expression $exp$ \\
\hline
\end{tabular}



next_inactive up previous
Abhijat Vichare 2006-01-27

Email: amv[at]cfdvs.iitb.ac.in
© 2004,2005,2006.
Programming Languages Group,
IIT Bombay, INDIA.
Last Site Update:
Feb. 16, 2006