This is ../../gcc-3.4/gcc/doc/gccint.info, produced by makeinfo version
4.2 from ../../gcc-3.4/gcc/doc/gccint.texi.

Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 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.2 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.
INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gccint: (gccint).            Internals of the GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the internals of the GNU compilers.

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

File: gccint.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.

`VECTOR_CST'
     These nodes are used to represent vector constants, whose parts are
     constant nodes.  Each individual constant node is either an
     integer or a double constant node.  The first operand is a
     `TREE_LIST' of the constant nodes and is accessed through
     `TREE_VECTOR_CST_ELTS'.

`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.

     The behavior of this operation on signed arithmetic overflow is
     controlled by the `flag_wrapv' and `flag_trapv' variables.

`ABS_EXPR'
     These nodes represent the absolute value of the single operand, for
     both integer and floating-point types.  This is typically used to
     implement the `abs', `labs' and `llabs' builtins for integer
     types, and the `fabs', `fabsf' and `fabsl' builtins for floating
     point types.  The type of abs operation can be determined by
     looking at the type of the expression.

     This node is not used for complex types.  To represent the modulus
     or complex abs of a complex value, use the `BUILT_IN_CABS',
     `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to
     implement the C99 `cabs', `cabsf' and `cabsl' built-in functions.

`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.  Note that the result is undefined if
     the second operand is larger than the first operand's type size.

`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)*b' where the division is as if computed by a
     `TRUNC_DIV_EXPR'.

     The behavior of these operations on signed arithmetic overflow is
     controlled by the `flag_wrapv' and `flag_trapv' variables.

`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.  The type of these expressions must be the
     type of a component of the array.

`ARRAY_RANGE_REF'
     These nodes represent access to a range (or "slice") of an array.
     The operands are the same as that for `ARRAY_REF' and have the same
     meanings.  The type of these expressions must be an array whose
     component type is the same as that of the first operand.  The
     range of that array type determines the amount of data these
     expressions access.

`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.

     The second operand must have the same type as the entire
     expression, unless it unconditionally throws an exception or calls
     a noreturn function, in which case it should have void type.  The
     same constraints apply to the third operand.  This allows array
     bounds checks to be represented conveniently as `(i >= 0 && i <
     10) ? i : abort()'.

     As a GNU extension, the C language front-ends allow the second
     operand of the `?:' operator may be omitted in the source.  For
     example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x'
     is an expression without side-effects.  In the tree
     representation, however, the second operand is always present,
     possibly protected by `SAVE_EXPR' if the first argument does cause
     side-effects.

`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.

`COMPOUND_LITERAL_EXPR'
     These nodes represent ISO C99 compound literals.  The
     `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an
     anonymous `VAR_DECL' for the unnamed object represented by the
     compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a
     `CONSTRUCTOR' representing the brace-enclosed list of initializers
     in the compound literal.  That anonymous `VAR_DECL' can also be
     accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro.

`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.

`VTABLE_REF'
     A `VTABLE_REF' indicates that the interior expression computes a
     value that is a vtable entry.  It is used with `-fvtable-gc' to
     track the reference through to front end to the middle end, at
     which point we transform this to a `REG_VTABLE_REF' note, which
     survives the balance of code generation.

     The first operand is the expression that computes the vtable
     reference.  The second operand is the `VAR_DECL' of the vtable.
     The third operand is an `INTEGER_CST' of the byte offset into the
     vtable.

`VA_ARG_EXPR'
     This node is used to implement support for the C/C++ variable
     argument-list mechanism.  It represents expressions like `va_arg
     (ap, type)'.  Its `TREE_TYPE' yields the tree representation for
     `type' and its sole argument yields the representation for `ap'.


File: gccint.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.
* Special Accessors:: Macros to access specific annotations on RTL.
* 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: gccint.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'; 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.

   In a machine description, strings are normally written with double
quotes, as you would in C.  However, strings in machine descriptions may
extend over many lines, which is invalid C, and adjacent string
constants are not concatenated as they are in C.  Any string constant
may be surrounded with a single set of parentheses.  Sometimes this
makes the machine description easier to read.

   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.

   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 uppercase) 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 lowercase, but
when they appear in C code they are written in uppercase.  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: gccint.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 code, `rtl.def' specifies the number of
contained objects and their kinds using a sequence of characters called
the "format" of the expression code.  For example, the format of
`subreg' is `ei'.

   These are the most commonly used format characters:

`e'
     An expression (actually a pointer to an expression).

`i'
     An integer.

`w'
     A wide integer.

`s'
     A string.

`E'
     A vector of expressions.

   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.

`B'
     `B' indicates a pointer to basic block structure.

`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: gccint.info,  Node: Accessors,  Next: Special Accessors,  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: gccint.info,  Node: Special Accessors,  Next: Flags,  Prev: Accessors,  Up: RTL

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

   Some RTL nodes have special annotations associated with them.

`MEM'

    `MEM_ALIAS_SET (X)'
          If 0, X is not in any alias set, and may alias anything.
          Otherwise, X can only alias `MEM's in a conflicting alias
          set.  This value is set in a language-dependent manner in the
          front-end, and should not be altered in the back-end.  In
          some front-ends, these numbers may correspond in some way to
          types, or other language-level entities, but they need not,
          and the back-end makes no such assumptions.  These set
          numbers are tested with `alias_sets_conflict_p'.

    `MEM_EXPR (X)'
          If this register is known to hold the value of some user-level
          declaration, this is that tree node.  It may also be a
          `COMPONENT_REF', in which case this is some field reference,
          and `TREE_OPERAND (X, 0)' contains the declaration, or
          another `COMPONENT_REF', or null if there is no compile-time
          object associated with the reference.

    `MEM_OFFSET (X)'
          The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.

    `MEM_SIZE (X)'
          The size in bytes of the memory reference as a `CONST_INT'
          rtx.  This is mostly relevant for `BLKmode' references as
          otherwise the size is implied by the mode.

    `MEM_ALIGN (X)'
          The known alignment in bits of the memory reference.

`REG'

    `ORIGINAL_REGNO (X)'
          This field holds the number the register "originally" had;
          for a pseudo register turned into a hard reg this will hold
          the old pseudo register number.

    `REG_EXPR (X)'
          If this register is known to hold the value of some user-level
          declaration, this is that tree node.

    `REG_OFFSET (X)'
          If this register is known to hold the value of some user-level
          declaration, this is the offset into that logical storage.

`SYMBOL_REF'

    `SYMBOL_REF_DECL (X)'
          If the `symbol_ref' X was created for a `VAR_DECL' or a
          `FUNCTION_DECL', that tree is recorded here.  If this value is
          null, then X was created by back end code generation routines,
          and there is no associated front end symbol table entry.

          `SYMBOL_REF_DECL' may also point to a tree of class `'c'',
          that is, some sort of constant.  In this case, the
          `symbol_ref' is an entry in the per-file constant pool;
          again, there is no associated front end symbol table entry.

    `SYMBOL_REF_FLAGS (X)'
          In a `symbol_ref', this is used to communicate various
          predicates about the symbol.  Some of these are common enough
          to be computed by common code, some are specific to the
          target.  The common bits are:

         `SYMBOL_FLAG_FUNCTION'
               Set if the symbol refers to a function.

         `SYMBOL_FLAG_LOCAL'
               Set if the symbol is local to this "module".  See
               `TARGET_BINDS_LOCAL_P'.

         `SYMBOL_FLAG_EXTERNAL'
               Set if this symbol is not defined in this translation
               unit.  Note that this is not the inverse of
               `SYMBOL_FLAG_LOCAL'.

         `SYMBOL_FLAG_SMALL'
               Set if the symbol is located in the small data section.
               See `TARGET_IN_SMALL_DATA_P'.

         `SYMBOL_REF_TLS_MODEL (X)'
               This is a multi-bit field accessor that returns the
               `tls_model' to be used for a thread-local storage
               symbol.  It returns zero for non-thread-local symbols.

          Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for
          the target's use.

