This is doc/gcc.info, produced by makeinfo version 4.0b from
doc/gcc.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU compiler.


   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA


   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001 Free Software Foundation, Inc.


   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.


File: gcc.info,  Node: Expression trees,  Prev: Attributes,  Up: Trees

Expressions
===========

   The internal representation for expressions is for the most part
quite straightforward.  However, there are a few facts that one must
bear in mind.  In particular, the expression "tree" is actually a
directed acyclic graph.  (For example there may be many references to
the integer constant zero throughout the source program; many of these
will be represented by the same expression node.)  You should not rely
on certain kinds of node being shared, nor should rely on certain kinds
of nodes being unshared.

   The following macros can be used with all expression nodes:

`TREE_TYPE'
     Returns the type of the expression.  This value may not be
     precisely the same type that would be given the expression in the
     original program.

   In what follows, some nodes that one might expect to always have type
`bool' are documented to have either integral or boolean type.  At some
point in the future, the C front end may also make use of this same
intermediate representation, and at this point these nodes will
certainly have integral type.  The previous sentence is not meant to
imply that the C++ front end does not or will not give these nodes
integral type.

   Below, we list the various kinds of expression nodes.  Except where
noted otherwise, the operands to an expression are accessed using the
`TREE_OPERAND' macro.  For example, to access the first operand to a
binary plus expression `expr', use:

     TREE_OPERAND (expr, 0)

As this example indicates, the operands are zero-indexed.

   The table below begins with constants, moves on to unary expressions,
then proceeds to binary expressions, and concludes with various other
kinds of expressions:

`INTEGER_CST'
     These nodes represent integer constants.  Note that the type of
     these constants is obtained with `TREE_TYPE'; they are not always
     of type `int'.  In particular, `char' constants are represented
     with `INTEGER_CST' nodes.  The value of the integer constant `e' is
     given by
          ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
          + TREE_INST_CST_LOW (e))

     HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
     Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a
     `HOST_WIDE_INT'.  The value of an `INTEGER_CST' is interpreted as
     a signed or unsigned quantity depending on the type of the
     constant.  In general, the expression given above will overflow,
     so it should not be used to calculate the value of the constant.

     The variable `integer_zero_node' is an integer constant with value
     zero.  Similarly, `integer_one_node' is an integer constant with
     value one.  The `size_zero_node' and `size_one_node' variables are
     analogous, but have type `size_t' rather than `int'.

     The function `tree_int_cst_lt' is a predicate which holds if its
     first argument is less than its second.  Both constants are
     assumed to have the same signedness (i.e., either both should be
     signed or both should be unsigned.)  The full width of the
     constant is used when doing the comparison; the usual rules about
     promotions and conversions are ignored.  Similarly,
     `tree_int_cst_equal' holds if the two constants are equal.  The
     `tree_int_cst_sgn' function returns the sign of a constant.  The
     value is `1', `0', or `-1' according on whether the constant is
     greater than, equal to, or less than zero.  Again, the signedness
     of the constant's type is taken into account; an unsigned constant
     is never less than zero, no matter what its bit-pattern.

`REAL_CST'
     FIXME: Talk about how to obtain representations of this constant,
     do comparisons, and so forth.

`COMPLEX_CST'
     These nodes are used to represent complex number constants, that
     is a `__complex__' whose parts are constant nodes.  The
     `TREE_REALPART' and `TREE_IMAGPART' return the real and the
     imaginary parts respectively.

`STRING_CST'
     These nodes represent string-constants.  The `TREE_STRING_LENGTH'
     returns the length of the string, as an `int'.  The
     `TREE_STRING_POINTER' is a `char*' containing the string itself.
     The string may not be `NUL'-terminated, and it may contain
     embedded `NUL' characters.  Therefore, the `TREE_STRING_LENGTH'
     includes the trailing `NUL' if it is present.

     For wide string constants, the `TREE_STRING_LENGTH' is the number
     of bytes in the string, and the `TREE_STRING_POINTER' points to an
     array of the bytes of the string, as represented on the target
     system (that is, as integers in the target endianness).  Wide and
     non-wide string constants are distinguished only by the `TREE_TYPE'
     of the `STRING_CST'.

     FIXME: The formats of string constants are not well-defined when
     the target system bytes are not the same width as host system
     bytes.

`PTRMEM_CST'
     These nodes are used to represent pointer-to-member constants.  The
     `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or
     `UNION_TYPE' within which the pointer points), and the
     `PTRMEM_CST_MEMBER' is the declaration for the pointed to object.
     Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in
     general different from the `PTRMEM_CST_CLASS'.  For example, given:
          struct B { int i; };
          struct D : public B {};
          int D::*dp = &D::i;

     The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the
     `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is
     a member of `B', not `D'.

`VAR_DECL'
     These nodes represent variables, including static data members.
     For more information, *note Declarations::.

`NEGATE_EXPR'
     These nodes represent unary negation of the single operand, for
     both integer and floating-point types.  The type of negation can be
     determined by looking at the type of the expression.

`BIT_NOT_EXPR'
     These nodes represent bitwise complement, and will always have
     integral type.  The only operand is the value to be complemented.

`TRUTH_NOT_EXPR'
     These nodes represent logical negation, and will always have
     integral (or boolean) type.  The operand is the value being
     negated.

`PREDECREMENT_EXPR'
`PREINCREMENT_EXPR'
`POSTDECREMENT_EXPR'
`POSTINCREMENT_EXPR'
     These nodes represent increment and decrement expressions.  The
     value of the single operand is computed, and the operand
     incremented or decremented.  In the case of `PREDECREMENT_EXPR' and
     `PREINCREMENT_EXPR', the value of the expression is the value
     resulting after the increment or decrement; in the case of
     `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before
     the increment or decrement occurs.  The type of the operand, like
     that of the result, will be either integral, boolean, or
     floating-point.

`ADDR_EXPR'
     These nodes are used to represent the address of an object.  (These
     expressions will always have pointer or reference type.)  The
     operand may be another expression, or it may be a declaration.

     As an extension, GCC allows users to take the address of a label.
     In this case, the operand of the `ADDR_EXPR' will be a
     `LABEL_DECL'.  The type of such an expression is `void*'.

     If the object addressed is not an lvalue, a temporary is created,
     and the address of the temporary is used.

`INDIRECT_REF'
     These nodes are used to represent the object pointed to by a
     pointer.  The operand is the pointer being dereferenced; it will
     always have pointer or reference type.

`FIX_TRUNC_EXPR'
     These nodes represent conversion of a floating-point value to an
     integer.  The single operand will have a floating-point type,
     while the the complete expression will have an integral (or
     boolean) type.  The operand is rounded towards zero.

`FLOAT_EXPR'
     These nodes represent conversion of an integral (or boolean) value
     to a floating-point value.  The single operand will have integral
     type, while the complete expression will have a floating-point
     type.

     FIXME: How is the operand supposed to be rounded?  Is this
     dependent on `-mieee'?

`COMPLEX_EXPR'
     These nodes are used to represent complex numbers constructed from
     two expressions of the same (integer or real) type.  The first
     operand is the real part and the second operand is the imaginary
     part.

`CONJ_EXPR'
     These nodes represent the conjugate of their operand.

`REALPART_EXPR'

`IMAGPART_EXPR'
     These nodes represent respectively the real and the imaginary parts
     of complex numbers (their sole argument).

`NON_LVALUE_EXPR'
     These nodes indicate that their one and only operand is not an
     lvalue.  A back end can treat these identically to the single
     operand.

`NOP_EXPR'
     These nodes are used to represent conversions that do not require
     any code-generation.  For example, conversion of a `char*' to an
     `int*' does not require any code be generated; such a conversion is
     represented by a `NOP_EXPR'.  The single operand is the expression
     to be converted.  The conversion from a pointer to a reference is
     also represented with a `NOP_EXPR'.

`CONVERT_EXPR'
     These nodes are similar to `NOP_EXPR's, but are used in those
     situations where code may need to be generated.  For example, if an
     `int*' is converted to an `int' code may need to be generated on
     some platforms.  These nodes are never used for C++-specific
     conversions, like conversions between pointers to different
     classes in an inheritance hierarchy.  Any adjustments that need to
     be made in such cases are always indicated explicitly.  Similarly,
     a user-defined conversion is never represented by a
     `CONVERT_EXPR'; instead, the function calls are made explicit.

`THROW_EXPR'
     These nodes represent `throw' expressions.  The single operand is
     an expression for the code that should be executed to throw the
     exception.  However, there is one implicit action not represented
     in that expression; namely the call to `__throw'.  This function
     takes no arguments.  If `setjmp'/`longjmp' exceptions are used, the
     function `__sjthrow' is called instead.  The normal GCC back end
     uses the function `emit_throw' to generate this code; you can
     examine this function to see what needs to be done.

`LSHIFT_EXPR'
`RSHIFT_EXPR'
     These nodes represent left and right shifts, respectively.  The
     first operand is the value to shift; it will always be of integral
     type.  The second operand is an expression for the number of bits
     by which to shift.  Right shift should be treated as arithmetic,
     i.e., the high-order bits should be zero-filled when the
     expression has unsigned type and filled with the sign bit when the
     expression has signed type.

`BIT_IOR_EXPR'
`BIT_XOR_EXPR'
`BIT_AND_EXPR'
     These nodes represent bitwise inclusive or, bitwise exclusive or,
     and bitwise and, respectively.  Both operands will always have
     integral type.

`TRUTH_ANDIF_EXPR'
`TRUTH_ORIF_EXPR'
     These nodes represent logical and and logical or, respectively.
     These operators are not strict; i.e., the second operand is
     evaluated only if the value of the expression is not determined by
     evaluation of the first operand.  The type of the operands, and
     the result type, is always of boolean or integral type.

`TRUTH_AND_EXPR'
`TRUTH_OR_EXPR'
`TRUTH_XOR_EXPR'
     These nodes represent logical and, logical or, and logical
     exclusive or.  They are strict; both arguments are always
     evaluated.  There are no corresponding operators in C or C++, but
     the front end will sometimes generate these expressions anyhow, if
     it can tell that strictness does not matter.

`PLUS_EXPR'
`MINUS_EXPR'
`MULT_EXPR'
`TRUNC_DIV_EXPR'
`TRUNC_MOD_EXPR'
`RDIV_EXPR'
     These nodes represent various binary arithmetic operations.
     Respectively, these operations are addition, subtraction (of the
     second operand from the first), multiplication, integer division,
     integer remainder, and floating-point division.  The operands to
     the first three of these may have either integral or floating
     type, but there will never be case in which one operand is of
     floating type and the other is of integral type.

     The result of a `TRUNC_DIV_EXPR' is always rounded towards zero.
     The `TRUNC_MOD_EXPR' of two operands `a' and `b' is always `a -
     a/b' where the division is as if computed by a `TRUNC_DIV_EXPR'.

`ARRAY_REF'
     These nodes represent array accesses.  The first operand is the
     array; the second is the index.  To calculate the address of the
     memory accessed, you must scale the index by the size of the type
     of the array elements.

`EXACT_DIV_EXPR'
     Document.

`LT_EXPR'
`LE_EXPR'
`GT_EXPR'
`GE_EXPR'
`EQ_EXPR'
`NE_EXPR'
     These nodes represent the less than, less than or equal to, greater
     than, greater than or equal to, equal, and not equal comparison
     operators.  The first and second operand with either be both of
     integral type or both of floating type.  The result type of these
     expressions will always be of integral or boolean type.

`MODIFY_EXPR'
     These nodes represent assignment.  The left-hand side is the first
     operand; the right-hand side is the second operand.  The left-hand
     side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or
     other lvalue.

     These nodes are used to represent not only assignment with `=' but
     also compound assignments (like `+='), by reduction to `='
     assignment.  In other words, the representation for `i += 3' looks
     just like that for `i = i + 3'.

`INIT_EXPR'
     These nodes are just like `MODIFY_EXPR', but are used only when a
     variable is initialized, rather than assigned to subsequently.

`COMPONENT_REF'
     These nodes represent non-static data member accesses.  The first
     operand is the object (rather than a pointer to it); the second
     operand is the `FIELD_DECL' for the data member.

`COMPOUND_EXPR'
     These nodes represent comma-expressions.  The first operand is an
     expression whose value is computed and thrown away prior to the
     evaluation of the second operand.  The value of the entire
     expression is the value of the second operand.

`COND_EXPR'
     These nodes represent `?:' expressions.  The first operand is of
     boolean or integral type.  If it evaluates to a nonzero value, the
     second operand should be evaluated, and returned as the value of
     the expression.  Otherwise, the third operand is evaluated, and
     returned as the value of the expression.  As a GNU extension, the
     middle operand of the `?:' operator may be omitted in the source,
     like this:

          x ? : 3

     which is equivalent to

          x ? x : 3

     assuming that `x' is an expression without side-effects.  However,
     in the case that the first operation causes side effects, the
     side-effects occur only once.  Consumers of the internal
     representation do not need to worry about this oddity; the second
     operand will be always be present in the internal representation.

`CALL_EXPR'
     These nodes are used to represent calls to functions, including
     non-static member functions.  The first operand is a pointer to the
     function to call; it is always an expression whose type is a
     `POINTER_TYPE'.  The second argument is a `TREE_LIST'.  The
     arguments to the call appear left-to-right in the list.  The
     `TREE_VALUE' of each list node contains the expression
     corresponding to that argument.  (The value of `TREE_PURPOSE' for
     these nodes is unspecified, and should be ignored.)  For non-static
     member functions, there will be an operand corresponding to the
     `this' pointer.  There will always be expressions corresponding to
     all of the arguments, even if the function is declared with default
     arguments and some arguments are not explicitly provided at the
     call sites.

`STMT_EXPR'
     These nodes are used to represent GCC's statement-expression
     extension.  The statement-expression extension allows code like
     this:
          int f() { return ({ int j; j = 3; j + 7; }); }
     In other words, an sequence of statements may occur where a single
     expression would normally appear.  The `STMT_EXPR' node represents
     such an expression.  The `STMT_EXPR_STMT' gives the statement
     contained in the expression; this is always a `COMPOUND_STMT'.  The
     value of the expression is the value of the last sub-statement in
     the `COMPOUND_STMT'.  More precisely, the value is the value
     computed by the last `EXPR_STMT' in the outermost scope of the
     `COMPOUND_STMT'.  For example, in:
          ({ 3; })
     the value is `3' while in:
          ({ if (x) { 3; } })
     (represented by a nested `COMPOUND_STMT'), there is no value.  If
     the `STMT_EXPR' does not yield a value, it's type will be `void'.

`BIND_EXPR'
     These nodes represent local blocks.  The first operand is a list of
     temporary variables, connected via their `TREE_CHAIN' field.  These
     will never require cleanups.  The scope of these variables is just
     the body of the `BIND_EXPR'.  The body of the `BIND_EXPR' is the
     second operand.

`LOOP_EXPR'
     These nodes represent "infinite" loops.  The `LOOP_EXPR_BODY'
     represents the body of the loop.  It should be executed forever,
     unless an `EXIT_EXPR' is encountered.

`EXIT_EXPR'
     These nodes represent conditional exits from the nearest enclosing
     `LOOP_EXPR'.  The single operand is the condition; if it is
     nonzero, then the loop should be exited.  An `EXIT_EXPR' will only
     appear within a `LOOP_EXPR'.

`CLEANUP_POINT_EXPR'
     These nodes represent full-expressions.  The single operand is an
     expression to evaluate.  Any destructor calls engendered by the
     creation of temporaries during the evaluation of that expression
     should be performed immediately after the expression is evaluated.

`CONSTRUCTOR'
     These nodes represent the brace-enclosed initializers for a
     structure or array.  The first operand is reserved for use by the
     back end.  The second operand is a `TREE_LIST'.  If the
     `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
     `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
     `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
     node will be the expression used to initialize that field.  You
     should not depend on the fields appearing in any particular order,
     nor should you assume that all fields will be represented.
     Unrepresented fields may be assigned any value.

     If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
     the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
     `INTEGER_CST'.  This constant indicates which element of the array
     (indexed from zero) is being assigned to; again, the `TREE_VALUE'
     is the corresponding initializer.  If the `TREE_PURPOSE' is
     `NULL_TREE', then the initializer is for the next available array
     element.

     Conceptually, before any initialization is done, the entire area of
     storage is initialized to zero.

`SAVE_EXPR'
     A `SAVE_EXPR' represents an expression (possibly involving
     side-effects) that is used more than once.  The side-effects should
     occur only the first time the expression is evaluated.  Subsequent
     uses should just reuse the computed value.  The first operand to
     the `SAVE_EXPR' is the expression to evaluate.  The side-effects
     should be executed where the `SAVE_EXPR' is first encountered in a
     depth-first preorder traversal of the expression tree.

`TARGET_EXPR'
     A `TARGET_EXPR' represents a temporary object.  The first operand
     is a `VAR_DECL' for the temporary variable.  The second operand is
     the initializer for the temporary.  The initializer is evaluated,
     and copied (bitwise) into the temporary.

     Often, a `TARGET_EXPR' occurs on the right-hand side of an
     assignment, or as the second operand to a comma-expression which is
     itself the right-hand side of an assignment, etc.  In this case,
     we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is
     "orphaned".  For a normal `TARGET_EXPR' the temporary variable
     should be treated as an alias for the left-hand side of the
     assignment, rather than as a new temporary variable.

     The third operand to the `TARGET_EXPR', if present, is a
     cleanup-expression (i.e., destructor call) for the temporary.  If
     this expression is orphaned, then this expression must be executed
     when the statement containing this expression is complete.  These
     cleanups must always be executed in the order opposite to that in
     which they were encountered.  Note that if a temporary is created
     on one branch of a conditional operator (i.e., in the second or
     third operand to a `COND_EXPR'), the cleanup must be run only if
     that branch is actually executed.

     See `STMT_IS_FULL_EXPR_P' for more information about running these
     cleanups.

`AGGR_INIT_EXPR'
     An `AGGR_INIT_EXPR' represents the initialization as the return
     value of a function call, or as the result of a constructor.  An
     `AGGR_INIT_EXPR' will only appear as the second operand of a
     `TARGET_EXPR'.  The first operand to the `AGGR_INIT_EXPR' is the
     address of a function to call, just as in a `CALL_EXPR'.  The
     second operand are the arguments to pass that function, as a
     `TREE_LIST', again in a manner similar to that of a `CALL_EXPR'.
     The value of the expression is that returned by the function.

     If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the
     initialization is via a constructor call.  The address of the third
     operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is
     taken, and this value replaces the first argument in the argument
     list.  In this case, the value of the expression is the `VAR_DECL'
     given by the third operand to the `AGGR_INIT_EXPR'; constructors do
     not return a value.


File: gcc.info,  Node: RTL,  Next: Machine Desc,  Prev: Trees,  Up: Top

RTL Representation
******************

   Most of the work of the compiler is done on an intermediate
representation called register transfer language.  In this language,
the instructions to be output are described, pretty much one by one, in
an algebraic form that describes what the instruction does.

   RTL is inspired by Lisp lists.  It has both an internal form, made
up of structures that point at other structures, and a textual form
that is used in the machine description and in printed debugging dumps.
The textual form uses nested parentheses to indicate the pointers in
the internal form.

* Menu:

* RTL Objects::       Expressions vs vectors vs strings vs integers.
* RTL Classes::       Categories of RTL expression objects, and their structure.
* Accessors::         Macros to access expression operands or vector elts.
* Flags::             Other flags in an RTL expression.
* Machine Modes::     Describing the size and format of a datum.
* Constants::         Expressions with constant values.
* Regs and Memory::   Expressions representing register contents or memory.
* Arithmetic::        Expressions representing arithmetic on other expressions.
* Comparisons::       Expressions representing comparison of expressions.
* Bit-Fields::        Expressions representing bit-fields in memory or reg.
* Vector Operations:: Expressions involving vector datatypes.
* Conversions::       Extending, truncating, floating or fixing.
* RTL Declarations::  Declaring volatility, constancy, etc.
* Side Effects::      Expressions for storing in registers, etc.
* Incdec::            Embedded side-effects for autoincrement addressing.
* Assembler::         Representing `asm' with operands.
* Insns::             Expression types for entire insns.
* Calls::             RTL representation of function call insns.
* Sharing::           Some expressions are unique; others *must* be copied.
* Reading RTL::       Reading textual RTL from a file.


File: gcc.info,  Node: RTL Objects,  Next: RTL Classes,  Up: RTL

RTL Object Types
================

   RTL uses five kinds of objects: expressions, integers, wide integers,
strings and vectors.  Expressions are the most important ones.  An RTL
expression ("RTX", for short) is a C structure, but it is usually
referred to with a pointer; a type that is given the typedef name `rtx'.

   An integer is simply an `int'; their written form uses decimal
digits.  A wide integer is an integral object whose type is
`HOST_WIDE_INT' (*note Config::); their written form uses decimal
digits.

   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.

   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.

   Expressions are classified by "expression codes" (also called RTX
codes).  The expression code is a name defined in `rtl.def', which is
also (in upper case) a C enumeration constant.  The possible expression
codes and their meanings are machine-independent.  The code of an RTX
can be extracted with the macro `GET_CODE (X)' and altered with
`PUT_CODE (X, NEWCODE)'.

   The expression code determines how many operands the expression
contains, and what kinds of objects they are.  In RTL, unlike Lisp, you
cannot tell by looking at an operand what kind of object it is.
Instead, you must know from its context--from the expression code of
the containing expression.  For example, in an expression of code
`subreg', the first operand is to be regarded as an expression and the
second operand as an integer.  In an expression of code `plus', there
are two operands, both of which are to be regarded as expressions.  In
a `symbol_ref' expression, there is one operand, which is to be
regarded as a string.

   Expressions are written as parentheses containing the name of the
expression type, its flags and machine mode if any, and then the
operands of the expression (separated by spaces).

   Expression code names in the `md' file are written in lower case,
but when they appear in C code they are written in upper case.  In this
manual, they are shown as follows: `const_int'.

   In a few contexts a null pointer is valid where an expression is
normally wanted.  The written form of this is `(nil)'.


File: gcc.info,  Node: RTL Classes,  Next: Accessors,  Prev: RTL Objects,  Up: RTL

RTL Classes and Formats
=======================

   The various expression codes are divided into several "classes",
which are represented by single characters.  You can determine the class
of an RTX code with the macro `GET_RTX_CLASS (CODE)'.  Currently,
`rtx.def' defines these classes:

`o'
     An RTX code that represents an actual object, such as a register
     (`REG') or a memory location (`MEM', `SYMBOL_REF').  Constants and
     basic transforms on objects (`ADDRESSOF', `HIGH', `LO_SUM') are
     also included.  Note that `SUBREG' and `STRICT_LOW_PART' are not
     in this class, but in class `x'.

`<'
     An RTX code for a comparison, such as `NE' or `LT'.

`1'
     An RTX code for a unary arithmetic operation, such as `NEG',
     `NOT', or `ABS'.  This category also includes value extension
     (sign or zero) and conversions between integer and floating point.

`c'
     An RTX code for a commutative binary operation, such as `PLUS' or
     `AND'.  `NE' and `EQ' are comparisons, so they have class `<'.

`2'
     An RTX code for a non-commutative binary operation, such as
     `MINUS', `DIV', or `ASHIFTRT'.

`b'
     An RTX code for a bit-field operation.  Currently only
     `ZERO_EXTRACT' and `SIGN_EXTRACT'.  These have three inputs and
     are lvalues (so they can be used for insertion as well).  *Note
     Bit-Fields::.

`3'
     An RTX code for other three input operations.  Currently only
     `IF_THEN_ELSE'.

`i'
     An RTX code for an entire instruction:  `INSN', `JUMP_INSN', and
     `CALL_INSN'.  *Note Insns::.

`m'
     An RTX code for something that matches in insns, such as
     `MATCH_DUP'.  These only occur in machine descriptions.

`a'
     An RTX code for an auto-increment addressing mode, such as
     `POST_INC'.

`x'
     All other RTX codes.  This category includes the remaining codes
     used only in machine descriptions (`DEFINE_*', etc.).  It also
     includes all the codes describing side effects (`SET', `USE',
     `CLOBBER', etc.) and the non-insns that may appear on an insn
     chain, such as `NOTE', `BARRIER', and `CODE_LABEL'.

   For each expression type `rtl.def' specifies the number of contained
objects and their kinds, with four possibilities: `e' for expression
(actually a pointer to an expression), `i' for integer, `w' for wide
integer, `s' for string, and `E' for vector of expressions.  The
sequence of letters for an expression code is called its "format".  For
example, the format of `subreg' is `ei'.

   A few other format characters are used occasionally:

`u'
     `u' is equivalent to `e' except that it is printed differently in
     debugging dumps.  It is used for pointers to insns.

`n'
     `n' is equivalent to `i' except that it is printed differently in
     debugging dumps.  It is used for the line number or code number of
     a `note' insn.

`S'
     `S' indicates a string which is optional.  In the RTL objects in
     core, `S' is equivalent to `s', but when the object is read, from
     an `md' file, the string value of this operand may be omitted.  An
     omitted string is taken to be the null string.

`V'
     `V' indicates a vector which is optional.  In the RTL objects in
     core, `V' is equivalent to `E', but when the object is read from
     an `md' file, the vector value of this operand may be omitted.  An
     omitted vector is effectively the same as a vector of no elements.

`0'
     `0' means a slot whose contents do not fit any normal category.
     `0' slots are not printed at all in dumps, and are often used in
     special ways by small parts of the compiler.

   There are macros to get the number of operands and the format of an
expression code:

`GET_RTX_LENGTH (CODE)'
     Number of operands of an RTX of code CODE.

`GET_RTX_FORMAT (CODE)'
     The format of an RTX of code CODE, as a C string.

   Some classes of RTX codes always have the same format.  For example,
it is safe to assume that all comparison operations have format `ee'.

`1'
     All codes of this class have format `e'.

`<'
`c'
`2'
     All codes of these classes have format `ee'.

`b'
`3'
     All codes of these classes have format `eee'.

`i'
     All codes of this class have formats that begin with `iuueiee'.
     *Note Insns::.  Note that not all RTL objects linked onto an insn
     chain are of class `i'.

`o'
`m'
`x'
     You can make no assumptions about the format of these codes.


File: gcc.info,  Node: Accessors,  Next: Flags,  Prev: RTL Classes,  Up: RTL

Access to Operands
==================

   Operands of expressions are accessed using the macros `XEXP',
`XINT', `XWINT' and `XSTR'.  Each of these macros takes two arguments:
an expression-pointer (RTX) and an operand number (counting from zero).
Thus,

     XEXP (X, 2)

accesses operand 2 of expression X, as an expression.

     XINT (X, 2)

accesses the same operand as an integer.  `XSTR', used in the same
fashion, would access it as a string.

   Any operand can be accessed as an integer, as an expression or as a
string.  You must choose the correct method of access for the kind of
value actually stored in the operand.  You would do this based on the
expression code of the containing expression.  That is also how you
would know how many operands there are.

   For example, if X is a `subreg' expression, you know that it has two
operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
1)'.  If you did `XINT (X, 0)', you would get the address of the
expression operand but cast as an integer; that might occasionally be
useful, but it would be cleaner to write `(int) XEXP (X, 0)'.  `XEXP
(X, 1)' would also compile without error, and would return the second,
integer operand cast as an expression pointer, which would probably
result in a crash when accessed.  Nothing stops you from writing `XEXP
(X, 28)' either, but this will access memory past the end of the
expression with unpredictable results.

   Access to operands which are vectors is more complicated.  You can
use the macro `XVEC' to get the vector-pointer itself, or the macros
`XVECEXP' and `XVECLEN' to access the elements and length of a vector.

`XVEC (EXP, IDX)'
     Access the vector-pointer which is operand number IDX in EXP.

`XVECLEN (EXP, IDX)'
     Access the length (number of elements) in the vector which is in
     operand number IDX in EXP.  This value is an `int'.

`XVECEXP (EXP, IDX, ELTNUM)'
     Access element number ELTNUM in the vector which is in operand
     number IDX in EXP.  This value is an RTX.

     It is up to you to make sure that ELTNUM is not negative and is
     less than `XVECLEN (EXP, IDX)'.

   All the macros defined in this section expand into lvalues and
therefore can be used to assign the operands, lengths and vector
elements as well as to access them.


File: gcc.info,  Node: Flags,  Next: Machine Modes,  Prev: Accessors,  Up: RTL

Flags in an RTL Expression
==========================

   RTL expressions contain several flags (one-bit bit-fields) and other
values that are used in certain types of expression.  Most often they
are accessed with the following macros:

`MEM_VOLATILE_P (X)'
     In `mem' expressions, nonzero for volatile memory references.
     Stored in the `volatil' field and printed as `/v'.

`MEM_IN_STRUCT_P (X)'
     In `mem' expressions, nonzero for reference to an entire structure,
     union or array, or to a component of one.  Zero for references to a
     scalar variable or through a pointer to a scalar.  Stored in the
     `in_struct' field and printed as `/s'.  If both this flag and
     MEM_SCALAR_P are clear, then we don't know whether this MEM is in a
     structure or not.  Both flags should never be simultaneously set.

`MEM_SCALAR_P (X)'
     In `mem' expressions, nonzero for reference to a scalar known not
     to be a member of a structure, union, or array.  Zero for such
     references and for indirections through pointers, even pointers
     pointing to scalar types.  If both this flag and MEM_STRUCT_P are
     clear, then we don't know whether this MEM is in a structure or
     not.  Both flags should never be simultaneously set.

`MEM_ALIAS_SET (X)'
     In `mem' expressions, the alias set to which X belongs.  If zero,
     X is not in any alias set, and may alias anything.  If nonzero, X
     may only alias objects in the same alias set.  This value is set
     (in a language-specific manner) by the front end.  This field is
     not a bit-field; it is in an integer, found as the second argument
     to the `mem'.

`REG_LOOP_TEST_P'
     In `reg' expressions, nonzero if this register's entire life is
     contained in the exit test code for some loop.  Stored in the
     `in_struct' field and printed as `/s'.

`REG_USERVAR_P (X)'
     In a `reg', nonzero if it corresponds to a variable present in the
     user's source code.  Zero for temporaries generated internally by
     the compiler.  Stored in the `volatil' field and printed as `/v'.

`REG_FUNCTION_VALUE_P (X)'
     Nonzero in a `reg' if it is the place in which this function's
     value is going to be returned.  (This happens only in a hard
     register.)  Stored in the `integrated' field and printed as `/i'.

     The same hard register may be used also for collecting the values
     of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
     in this kind of use.

`SUBREG_PROMOTED_VAR_P'
     Nonzero in a `subreg' if it was made when accessing an object that
     was promoted to a wider mode in accord with the `PROMOTED_MODE'
     machine description macro (*note Storage Layout::).  In this case,
     the mode of the `subreg' is the declared mode of the object and
     the mode of `SUBREG_REG' is the mode of the register that holds
     the object.  Promoted variables are always either sign- or
     zero-extended to the wider mode on every assignment.  Stored in
     the `in_struct' field and printed as `/s'.

`SUBREG_PROMOTED_UNSIGNED_P'
     Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if
     the object being referenced is kept zero-extended and zero if it
     is kept sign-extended.  Stored in the `unchanging' field and
     printed as `/u'.

`RTX_UNCHANGING_P (X)'
     Nonzero in a `reg' or `mem' if the value is not changed.  (This
     flag is not set for memory references via pointers to constants.
     Such pointers only guarantee that the object will not be changed
     explicitly by the current function.  The object might be changed by
     other functions or by aliasing.)  Stored in the `unchanging' field
     and printed as `/u'.

`RTX_INTEGRATED_P (INSN)'
     Nonzero in an insn if it resulted from an in-line function call.
     Stored in the `integrated' field and printed as `/i'.

`RTX_FRAME_RELATED_P (X)'
     Nonzero in an insn or expression which is part of a function
     prologue and sets the stack pointer, sets the frame pointer, or
     saves a register.  This flag should also be set on an instruction
     that sets up a temporary register to use in place of the frame
     pointer.

     In particular, on RISC targets where there are limits on the sizes
     of immediate constants, it is sometimes impossible to reach the
     register save area directly from the stack pointer.  In that case,
     a temporary register is used that is near enough to the register
     save area, and the Canonical Frame Address, i.e., DWARF2's logical
     frame pointer, register must (temporarily) be changed to be this
     temporary register.  So, the instruction that sets this temporary
     register must be marked as `RTX_FRAME_RELATED_P'.

     If the marked instruction is overly complex (defined in terms of
     what `dwarf2out_frame_debug_expr' can handle), you will also have
     to create a `REG_FRAME_RELATED_EXPR' note and attach it to the
     instruction.  This note should contain a simple expression of the
     computation performed by this instruction, i.e., one that
     `dwarf2out_frame_debug_expr' can handle.

     This flag is required for exception handling support on targets
     with RTL prologues.

`SYMBOL_REF_USED (X)'
     In a `symbol_ref', indicates that X has been used.  This is
     normally only used to ensure that X is only declared external
     once.  Stored in the `used' field.

`SYMBOL_REF_FLAG (X)'
     In a `symbol_ref', this is used as a flag for machine-specific
     purposes.  Stored in the `volatil' field and printed as `/v'.

`SYMBOL_REF_WEAK (X)'
     In a `symbol_ref', indicates that X has been declared weak.
     Stored in the `integrated' field and printed as `/i'.

`LABEL_OUTSIDE_LOOP_P'
     In `label_ref' expressions, nonzero if this is a reference to a
     label that is outside the innermost loop containing the reference
     to the label.  Stored in the `in_struct' field and printed as `/s'.

`INSN_DELETED_P (INSN)'
     In an insn, nonzero if the insn has been deleted.  Stored in the
     `volatil' field and printed as `/v'.

`INSN_ANNULLED_BRANCH_P (INSN)'
     In an `insn' in the delay slot of a branch insn, indicates that an
     annulling branch should be used.  See the discussion under
     `sequence' below.  Stored in the `unchanging' field and printed as
     `/u'.

`INSN_FROM_TARGET_P (INSN)'
     In an `insn' in a delay slot of a branch, indicates that the insn
     is from the target of the branch.  If the branch insn has
     `INSN_ANNULLED_BRANCH_P' set, this insn will only be executed if
     the branch is taken.  For annulled branches with
     `INSN_FROM_TARGET_P' clear, the insn will be executed only if the
     branch is not taken.  When `INSN_ANNULLED_BRANCH_P' is not set,
     this insn will always be executed.  Stored in the `in_struct'
     field and printed as `/s'.

`CONSTANT_POOL_ADDRESS_P (X)'
     Nonzero in a `symbol_ref' if it refers to part of the current
     function's "constants pool".  These are addresses close to the
     beginning of the function, and GCC assumes they can be addressed
     directly (perhaps with the help of base registers).  Stored in the
     `unchanging' field and printed as `/u'.

`CONST_CALL_P (X)'
     In a `call_insn', indicates that the insn represents a call to a
     const function.  Stored in the `unchanging' field and printed as
     `/u'.

`LABEL_PRESERVE_P (X)'
     In a `code_label', indicates that the label can never be deleted.
     Labels referenced by a non-local goto will have this bit set.
     Stored in the `in_struct' field and printed as `/s'.

`SCHED_GROUP_P (INSN)'
     During instruction scheduling, in an insn, indicates that the
     previous insn must be scheduled together with this insn.  This is
     used to ensure that certain groups of instructions will not be
     split up by the instruction scheduling pass, for example, `use'
     insns before a `call_insn' may not be separated from the
     `call_insn'.  Stored in the `in_struct' field and printed as `/s'.

   These are the fields which the above macros refer to:

`used'
     Normally, this flag is used only momentarily, at the end of RTL
     generation for a function, to count the number of times an
     expression appears in insns.  Expressions that appear more than
     once are copied, according to the rules for shared structure
     (*note Sharing::).

     In a `symbol_ref', it indicates that an external declaration for
     the symbol has already been written.

     In a `reg', it is used by the leaf register renumbering code to
     ensure that each register is only renumbered once.

`volatil'
     This flag is used in `mem', `symbol_ref' and `reg' expressions and
     in insns.  In RTL dump files, it is printed as `/v'.

     In a `mem' expression, it is 1 if the memory reference is volatile.
     Volatile memory references may not be deleted, reordered or
     combined.

     In a `symbol_ref' expression, it is used for machine-specific
     purposes.

     In a `reg' expression, it is 1 if the value is a user-level
     variable.  0 indicates an internal compiler temporary.

     In an insn, 1 means the insn has been deleted.

`in_struct'
     In `mem' expressions, it is 1 if the memory datum referred to is
     all or part of a structure or array; 0 if it is (or might be) a
     scalar variable.  A reference through a C pointer has 0 because
     the pointer might point to a scalar variable.  This information
     allows the compiler to determine something about possible cases of
     aliasing.

     In an insn in the delay slot of a branch, 1 means that this insn
     is from the target of the branch.

     During instruction scheduling, in an insn, 1 means that this insn
     must be scheduled as part of a group together with the previous
     insn.

     In `reg' expressions, it is 1 if the register has its entire life
     contained within the test expression of some loop.

     In `subreg' expressions, 1 means that the `subreg' is accessing an
     object that has had its mode promoted from a wider mode.

     In `label_ref' expressions, 1 means that the referenced label is
     outside the innermost loop containing the insn in which the
     `label_ref' was found.

     In `code_label' expressions, it is 1 if the label may never be
     deleted.  This is used for labels which are the target of
     non-local gotos.

     In an RTL dump, this flag is represented as `/s'.

`unchanging'
     In `reg' and `mem' expressions, 1 means that the value of the
     expression never changes.

     In `subreg' expressions, it is 1 if the `subreg' references an
     unsigned object whose mode has been promoted to a wider mode.

     In an insn, 1 means that this is an annulling branch.

     In a `symbol_ref' expression, 1 means that this symbol addresses
     something in the per-function constants pool.

     In a `call_insn', 1 means that this instruction is a call to a
     const function.

     In an RTL dump, this flag is represented as `/u'.

`integrated'
     In some kinds of expressions, including insns, this flag means the
     rtl was produced by procedure integration.

     In a `reg' expression, this flag indicates the register containing
     the value to be returned by the current function.  On machines
     that pass parameters in registers, the same register number may be
     used for parameters as well, but this flag is not set on such uses.

