3713 lines
175 KiB
HTML
3713 lines
175 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): RTL</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): RTL">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): RTL">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC149"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_14.html#SEC148" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_14.html#SEC148"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC150" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC150"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_2.html#SEC2" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 15. RTL Representation </H1>
|
|
<!--docid::SEC149::-->
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC150" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC150">15.1 RTL Object Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions vs vectors vs strings vs integers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151">15.2 RTL Classes and Formats</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Categories of RTL expresion objects, and their structure.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC152" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC152">15.3 Access to Operands</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Macros to access expression operands or vector elts.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC153" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC153">15.4 Flags in an RTL Expression</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Other flags in an RTL expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC154" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC154">15.5 Machine Modes</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Describing the size and format of a datum.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC155" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC155">15.6 Constant Expression Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions with constant values.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC156" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC156">15.7 Registers and Memory</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions representing register contents or memory.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC157" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC157">15.8 RTL Expressions for Arithmetic</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions representing arithmetic on other expressions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC158" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC158">15.9 Comparison Operations</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions representing comparison of expressions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC159" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC159">15.10 Bit Fields</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions representing bitfields in memory or reg.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC160" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC160">15.11 Conversions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Extending, truncating, floating or fixing.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC161" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC161">15.12 Declarations</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Declaring volatility, constancy, etc.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC162" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC162">15.13 Side Effect Expressions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expressions for storing in registers, etc.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC163" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC163">15.14 Embedded Side-Effects on Addresses</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Embedded side-effects for autoincrement addressing.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC164" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC164">15.15 Assembler Instructions as Expressions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Representing <CODE>asm</CODE> with operands.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC165" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC165">15.16 Insns</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Expression types for entire insns.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC166" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC166">15.17 RTL Representation of Function-Call Insns</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">RTL representation of function call insns.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC167" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC167">15.18 Structure Sharing Assumptions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Some expressions are unique; others *must* be copied.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_15.html#SEC168" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC168">15.19 Reading RTL</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Reading textual RTL from a file.</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="RTL Objects"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC150"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.1 RTL Object Types </H2>
|
|
<!--docid::SEC150::-->
|
|
<P>
|
|
|
|
<A NAME="IDX494"></A>
|
|
<A NAME="IDX495"></A>
|
|
<A NAME="IDX496"></A>
|
|
<A NAME="IDX497"></A>
|
|
<A NAME="IDX498"></A>
|
|
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
|
|
<CODE>rtx</CODE>.
|
|
</P><P>
|
|
|
|
An integer is simply an <CODE>int</CODE>; their written form uses decimal digits.
|
|
A wide integer is an integral object whose type is <CODE>HOST_WIDE_INT</CODE>
|
|
(see section <A HREF="gcc_18.html#SEC251" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_18.html#SEC251">18. The Configuration File</A>); their written form uses decimal digits.
|
|
</P><P>
|
|
|
|
A string is a sequence of characters. In core it is represented as a
|
|
<CODE>char *</CODE> 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 <CODE>symbol_ref</CODE> expressions, but they appear in
|
|
other contexts in the RTL expressions that make up machine descriptions.
|
|
</P><P>
|
|
|
|
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
|
|
(<SAMP>`[<small>...</small>]'</SAMP>) surrounding the elements, in sequence and with
|
|
whitespace separating them. Vectors of length zero are not created;
|
|
null pointers are used instead.
|
|
</P><P>
|
|
|
|
<A NAME="IDX499"></A>
|
|
<A NAME="IDX500"></A>
|
|
<A NAME="IDX501"></A>
|
|
<A NAME="IDX502"></A>
|
|
Expressions are classified by <EM>expression codes</EM> (also called RTX
|
|
codes). The expression code is a name defined in <TT>`rtl.def'</TT>, 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 <CODE>GET_CODE (<VAR>x</VAR>)</CODE> and altered with
|
|
<CODE>PUT_CODE (<VAR>x</VAR>, <VAR>newcode</VAR>)</CODE>.
|
|
</P><P>
|
|
|
|
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 <CODE>subreg</CODE>, the first operand is
|
|
to be regarded as an expression and the second operand as an integer. In
|
|
an expression of code <CODE>plus</CODE>, there are two operands, both of which
|
|
are to be regarded as expressions. In a <CODE>symbol_ref</CODE> expression,
|
|
there is one operand, which is to be regarded as a string.
|
|
</P><P>
|
|
|
|
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).
|
|
</P><P>
|
|
|
|
Expression code names in the <SAMP>`md'</SAMP> 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: <CODE>const_int</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX503"></A>
|
|
<A NAME="IDX504"></A>
|
|
In a few contexts a null pointer is valid where an expression is normally
|
|
wanted. The written form of this is <CODE>(nil)</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="RTL Classes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC151"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC150" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC150"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC152" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC152"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.2 RTL Classes and Formats </H2>
|
|
<!--docid::SEC151::-->
|
|
<P>
|
|
|
|
The various expression codes are divided into several <EM>classes</EM>,
|
|
which are represented by single characters. You can determine the class
|
|
of an RTX code with the macro <CODE>GET_RTX_CLASS (<VAR>code</VAR>)</CODE>.
|
|
Currently, <TT>`rtx.def'</TT> defines these classes:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>o</CODE>
|
|
<DD>An RTX code that represents an actual object, such as a register
|
|
(<CODE>REG</CODE>) or a memory location (<CODE>MEM</CODE>, <CODE>SYMBOL_REF</CODE>).
|
|
Constants and basic transforms on objects (<CODE>ADDRESSOF</CODE>,
|
|
<CODE>HIGH</CODE>, <CODE>LO_SUM</CODE>) are also included. Note that <CODE>SUBREG</CODE>
|
|
and <CODE>STRICT_LOW_PART</CODE> are not in this class, but in class <CODE>x</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE><</CODE>
|
|
<DD>An RTX code for a comparison, such as <CODE>NE</CODE> or <CODE>LT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>1</CODE>
|
|
<DD>An RTX code for a unary arithmetic operation, such as <CODE>NEG</CODE>,
|
|
<CODE>NOT</CODE>, or <CODE>ABS</CODE>. This category also includes value extension
|
|
(sign or zero) and conversions between integer and floating point.
|
|
<P>
|
|
|
|
<DT><CODE>c</CODE>
|
|
<DD>An RTX code for a commutative binary operation, such as <CODE>PLUS</CODE> or
|
|
<CODE>AND</CODE>. <CODE>NE</CODE> and <CODE>EQ</CODE> are comparisons, so they have class
|
|
<CODE><</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>2</CODE>
|
|
<DD>An RTX code for a non-commutative binary operation, such as <CODE>MINUS</CODE>,
|
|
<CODE>DIV</CODE>, or <CODE>ASHIFTRT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>b</CODE>
|
|
<DD>An RTX code for a bitfield operation. Currently only
|
|
<CODE>ZERO_EXTRACT</CODE> and <CODE>SIGN_EXTRACT</CODE>. These have three inputs
|
|
and are lvalues (so they can be used for insertion as well). See section <A HREF="gcc_15.html#SEC159" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC159">15.10 Bit Fields</A>.
|
|
<P>
|
|
|
|
<DT><CODE>3</CODE>
|
|
<DD>An RTX code for other three input operations. Currently only
|
|
<CODE>IF_THEN_ELSE</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>i</CODE>
|
|
<DD>An RTX code for an entire instruction: <CODE>INSN</CODE>, <CODE>JUMP_INSN</CODE>, and
|
|
<CODE>CALL_INSN</CODE>. See section <A HREF="gcc_15.html#SEC165" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC165">15.16 Insns</A>.
|
|
<P>
|
|
|
|
<DT><CODE>m</CODE>
|
|
<DD>An RTX code for something that matches in insns, such as
|
|
<CODE>MATCH_DUP</CODE>. These only occur in machine descriptions.
|
|
<P>
|
|
|
|
<DT><CODE>x</CODE>
|
|
<DD>All other RTX codes. This category includes the remaining codes used
|
|
only in machine descriptions (<CODE>DEFINE_*</CODE>, etc.). It also includes
|
|
all the codes describing side effects (<CODE>SET</CODE>, <CODE>USE</CODE>,
|
|
<CODE>CLOBBER</CODE>, etc.) and the non-insns that may appear on an insn
|
|
chain, such as <CODE>NOTE</CODE>, <CODE>BARRIER</CODE>, and <CODE>CODE_LABEL</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX505"></A>
|
|
For each expression type <TT>`rtl.def'</TT> specifies the number of
|
|
contained objects and their kinds, with four possibilities: <SAMP>`e'</SAMP> for
|
|
expression (actually a pointer to an expression), <SAMP>`i'</SAMP> for integer,
|
|
<SAMP>`w'</SAMP> for wide integer, <SAMP>`s'</SAMP> for string, and <SAMP>`E'</SAMP> for vector
|
|
of expressions. The sequence of letters for an expression code is
|
|
called its <EM>format</EM>. For example, the format of <CODE>subreg</CODE> is
|
|
<SAMP>`ei'</SAMP>.</P><P>
|
|
|
|
<A NAME="IDX506"></A>
|
|
A few other format characters are used occasionally:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>u</CODE>
|
|
<DD><SAMP>`u'</SAMP> is equivalent to <SAMP>`e'</SAMP> except that it is printed differently
|
|
in debugging dumps. It is used for pointers to insns.
|
|
<P>
|
|
|
|
<DT><CODE>n</CODE>
|
|
<DD><SAMP>`n'</SAMP> is equivalent to <SAMP>`i'</SAMP> except that it is printed differently
|
|
in debugging dumps. It is used for the line number or code number of a
|
|
<CODE>note</CODE> insn.
|
|
<P>
|
|
|
|
<DT><CODE>S</CODE>
|
|
<DD><SAMP>`S'</SAMP> indicates a string which is optional. In the RTL objects in
|
|
core, <SAMP>`S'</SAMP> is equivalent to <SAMP>`s'</SAMP>, but when the object is read,
|
|
from an <SAMP>`md'</SAMP> file, the string value of this operand may be omitted.
|
|
An omitted string is taken to be the null string.
|
|
<P>
|
|
|
|
<DT><CODE>V</CODE>
|
|
<DD><SAMP>`V'</SAMP> indicates a vector which is optional. In the RTL objects in
|
|
core, <SAMP>`V'</SAMP> is equivalent to <SAMP>`E'</SAMP>, but when the object is read
|
|
from an <SAMP>`md'</SAMP> file, the vector value of this operand may be omitted.
|
|
An omitted vector is effectively the same as a vector of no elements.
|
|
<P>
|
|
|
|
<DT><CODE>0</CODE>
|
|
<DD><SAMP>`0'</SAMP> means a slot whose contents do not fit any normal category.
|
|
<SAMP>`0'</SAMP> slots are not printed at all in dumps, and are often used in
|
|
special ways by small parts of the compiler.
|
|
</DL>
|
|
<P>
|
|
|
|
There are macros to get the number of operands and the format
|
|
of an expression code:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX507"></A>
|
|
<DT><CODE>GET_RTX_LENGTH (<VAR>code</VAR>)</CODE>
|
|
<DD>Number of operands of an RTX of code <VAR>code</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX508"></A>
|
|
<DT><CODE>GET_RTX_FORMAT (<VAR>code</VAR>)</CODE>
|
|
<DD>The format of an RTX of code <VAR>code</VAR>, as a C string.
|
|
</DL>
|
|
<P>
|
|
|
|
Some classes of RTX codes always have the same format. For example, it
|
|
is safe to assume that all comparison operations have format <CODE>ee</CODE>.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>1</CODE>
|
|
<DD>All codes of this class have format <CODE>e</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE><</CODE>
|
|
<DD><DT><CODE>c</CODE>
|
|
<DD><DT><CODE>2</CODE>
|
|
<DD>All codes of these classes have format <CODE>ee</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>b</CODE>
|
|
<DD><DT><CODE>3</CODE>
|
|
<DD>All codes of these classes have format <CODE>eee</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>i</CODE>
|
|
<DD>All codes of this class have formats that begin with <CODE>iuueiee</CODE>.
|
|
See section <A HREF="gcc_15.html#SEC165" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC165">15.16 Insns</A>. Note that not all RTL objects linked onto an insn chain
|
|
are of class <CODE>i</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>o</CODE>
|
|
<DD><DT><CODE>m</CODE>
|
|
<DD><DT><CODE>x</CODE>
|
|
<DD>You can make no assumptions about the format of these codes.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Accessors"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC152"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC153" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC153"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.3 Access to Operands </H2>
|
|
<!--docid::SEC152::-->
|
|
<P>
|
|
|
|
<A NAME="IDX509"></A>
|
|
<A NAME="IDX510"></A>
|
|
<A NAME="IDX511"></A>
|
|
<A NAME="IDX512"></A>
|
|
Operands of expressions are accessed using the macros <CODE>XEXP</CODE>,
|
|
<CODE>XINT</CODE>, <CODE>XWINT</CODE> and <CODE>XSTR</CODE>. Each of these macros takes
|
|
two arguments: an expression-pointer (RTX) and an operand number
|
|
(counting from zero). Thus,</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>XEXP (<VAR>x</VAR>, 2)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
accesses operand 2 of expression <VAR>x</VAR>, as an expression.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>XINT (<VAR>x</VAR>, 2)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
accesses the same operand as an integer. <CODE>XSTR</CODE>, used in the same
|
|
fashion, would access it as a string.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
For example, if <VAR>x</VAR> is a <CODE>subreg</CODE> expression, you know that it has
|
|
two operands which can be correctly accessed as <CODE>XEXP (<VAR>x</VAR>, 0)</CODE>
|
|
and <CODE>XINT (<VAR>x</VAR>, 1)</CODE>. If you did <CODE>XINT (<VAR>x</VAR>, 0)</CODE>, 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
|
|
<CODE>(int) XEXP (<VAR>x</VAR>, 0)</CODE>. <CODE>XEXP (<VAR>x</VAR>, 1)</CODE> 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 <CODE>XEXP (<VAR>x</VAR>, 28)</CODE> either,
|
|
but this will access memory past the end of the expression with
|
|
unpredictable results.</P><P>
|
|
|
|
Access to operands which are vectors is more complicated. You can use the
|
|
macro <CODE>XVEC</CODE> to get the vector-pointer itself, or the macros
|
|
<CODE>XVECEXP</CODE> and <CODE>XVECLEN</CODE> to access the elements and length of a
|
|
vector.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX513"></A>
|
|
<DT><CODE>XVEC (<VAR>exp</VAR>, <VAR>idx</VAR>)</CODE>
|
|
<DD>Access the vector-pointer which is operand number <VAR>idx</VAR> in <VAR>exp</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX514"></A>
|
|
<DT><CODE>XVECLEN (<VAR>exp</VAR>, <VAR>idx</VAR>)</CODE>
|
|
<DD>Access the length (number of elements) in the vector which is
|
|
in operand number <VAR>idx</VAR> in <VAR>exp</VAR>. This value is an <CODE>int</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX515"></A>
|
|
<DT><CODE>XVECEXP (<VAR>exp</VAR>, <VAR>idx</VAR>, <VAR>eltnum</VAR>)</CODE>
|
|
<DD>Access element number <VAR>eltnum</VAR> in the vector which is
|
|
in operand number <VAR>idx</VAR> in <VAR>exp</VAR>. This value is an RTX.
|
|
<P>
|
|
|
|
It is up to you to make sure that <VAR>eltnum</VAR> is not negative
|
|
and is less than <CODE>XVECLEN (<VAR>exp</VAR>, <VAR>idx</VAR>)</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<A NAME="Flags"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC153"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC152" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC152"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC154" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC154"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.4 Flags in an RTL Expression </H2>
|
|
<!--docid::SEC153::-->
|
|
<P>
|
|
|
|
RTL expressions contain several flags (one-bit bitfields) and other
|
|
values that are used in certain types of expression. Most often they
|
|
are accessed with the following macros:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX516"></A>
|
|
<A NAME="IDX517"></A>
|
|
<A NAME="IDX518"></A>
|
|
<A NAME="IDX519"></A>
|
|
<DT><CODE>MEM_VOLATILE_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In <CODE>mem</CODE> expressions, nonzero for volatile memory references.
|
|
Stored in the <CODE>volatil</CODE> field and printed as <SAMP>`/v'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX520"></A>
|
|
<A NAME="IDX521"></A>
|
|
<A NAME="IDX522"></A>
|
|
<A NAME="IDX523"></A>
|
|
<DT><CODE>MEM_IN_STRUCT_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In <CODE>mem</CODE> 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
|
|
<CODE>in_struct</CODE> field and printed as <SAMP>`/s'</SAMP>. 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.
|
|
<P>
|
|
|
|
<A NAME="IDX524"></A>
|
|
<A NAME="IDX525"></A>
|
|
<A NAME="IDX526"></A>
|
|
<A NAME="IDX527"></A>
|
|
<DT><CODE>MEM_SCALAR_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In <CODE>mem</CODE> 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.
|
|
<P>
|
|
|
|
<A NAME="IDX528"></A>
|
|
<DT><CODE>MEM_ALIAS_SET (<VAR>x</VAR>)</CODE>
|
|
<DD>In <CODE>mem</CODE> expressions, the alias set to which <VAR>x</VAR> belongs. If
|
|
zero, <VAR>x</VAR> is not in any alias set, and may alias anything. If
|
|
nonzero, <VAR>x</VAR> 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 <CODE>mem</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX529"></A>
|
|
<A NAME="IDX530"></A>
|
|
<A NAME="IDX531"></A>
|
|
<DT><CODE>REG_LOOP_TEST_P</CODE>
|
|
<DD>In <CODE>reg</CODE> expressions, nonzero if this register's entire life is
|
|
contained in the exit test code for some loop. Stored in the
|
|
<CODE>in_struct</CODE> field and printed as <SAMP>`/s'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX532"></A>
|
|
<A NAME="IDX533"></A>
|
|
<A NAME="IDX534"></A>
|
|
<DT><CODE>REG_USERVAR_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In a <CODE>reg</CODE>, 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 <CODE>volatil</CODE> field and printed as
|
|
<SAMP>`/v'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX535"></A>
|
|
<A NAME="IDX536"></A>
|
|
<A NAME="IDX537"></A>
|
|
<A NAME="IDX538"></A>
|
|
<DT><CODE>REG_FUNCTION_VALUE_P (<VAR>x</VAR>)</CODE>
|
|
<DD>Nonzero in a <CODE>reg</CODE> 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 <CODE>integrated</CODE> field and printed as
|
|
<SAMP>`/i'</SAMP>.
|
|
<P>
|
|
|
|
The same hard register may be used also for collecting the values of
|
|
functions called by this one, but <CODE>REG_FUNCTION_VALUE_P</CODE> is zero
|
|
in this kind of use.
|
|
</P><P>
|
|
|
|
<A NAME="IDX539"></A>
|
|
<A NAME="IDX540"></A>
|
|
<A NAME="IDX541"></A>
|
|
<DT><CODE>SUBREG_PROMOTED_VAR_P</CODE>
|
|
<DD>Nonzero in a <CODE>subreg</CODE> if it was made when accessing an object that
|
|
was promoted to a wider mode in accord with the <CODE>PROMOTED_MODE</CODE> machine
|
|
description macro (see section <A HREF="gcc_17.html#SEC202" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC202">17.3 Storage Layout</A>). In this case, the mode of
|
|
the <CODE>subreg</CODE> is the declared mode of the object and the mode of
|
|
<CODE>SUBREG_REG</CODE> 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 <CODE>in_struct</CODE> field and
|
|
printed as <SAMP>`/s'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX542"></A>
|
|
<A NAME="IDX543"></A>
|
|
<A NAME="IDX544"></A>
|
|
<DT><CODE>SUBREG_PROMOTED_UNSIGNED_P</CODE>
|
|
<DD>Nonzero in a <CODE>subreg</CODE> that has <CODE>SUBREG_PROMOTED_VAR_P</CODE> nonzero
|
|
if the object being referenced is kept zero-extended and zero if it
|
|
is kept sign-extended. Stored in the <CODE>unchanging</CODE> field and
|
|
printed as <SAMP>`/u'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX545"></A>
|
|
<A NAME="IDX546"></A>
|
|
<A NAME="IDX547"></A>
|
|
<A NAME="IDX548"></A>
|
|
<A NAME="IDX549"></A>
|
|
<DT><CODE>RTX_UNCHANGING_P (<VAR>x</VAR>)</CODE>
|
|
<DD>Nonzero in a <CODE>reg</CODE> or <CODE>mem</CODE> 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
|
|
<CODE>unchanging</CODE> field and printed as <SAMP>`/u'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX550"></A>
|
|
<A NAME="IDX551"></A>
|
|
<DT><CODE>RTX_INTEGRATED_P (<VAR>insn</VAR>)</CODE>
|
|
<DD>Nonzero in an insn if it resulted from an in-line function call.
|
|
Stored in the <CODE>integrated</CODE> field and printed as <SAMP>`/i'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX552"></A>
|
|
<DT><CODE>RTX_FRAME_RELATED_P (<VAR>x</VAR>)</CODE>
|
|
<DD>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 is required for exception handling support
|
|
on targets with RTL prologues.
|
|
<P>
|
|
|
|
<A NAME="IDX553"></A>
|
|
<A NAME="IDX554"></A>
|
|
<DT><CODE>SYMBOL_REF_USED (<VAR>x</VAR>)</CODE>
|
|
<DD>In a <CODE>symbol_ref</CODE>, indicates that <VAR>x</VAR> has been used. This is
|
|
normally only used to ensure that <VAR>x</VAR> is only declared external
|
|
once. Stored in the <CODE>used</CODE> field.
|
|
<P>
|
|
|
|
<A NAME="IDX555"></A>
|
|
<A NAME="IDX556"></A>
|
|
<A NAME="IDX557"></A>
|
|
<DT><CODE>SYMBOL_REF_FLAG (<VAR>x</VAR>)</CODE>
|
|
<DD>In a <CODE>symbol_ref</CODE>, this is used as a flag for machine-specific purposes.
|
|
Stored in the <CODE>volatil</CODE> field and printed as <SAMP>`/v'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX558"></A>
|
|
<A NAME="IDX559"></A>
|
|
<A NAME="IDX560"></A>
|
|
<DT><CODE>LABEL_OUTSIDE_LOOP_P</CODE>
|
|
<DD>In <CODE>label_ref</CODE> 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 <CODE>in_struct</CODE> field and printed as <SAMP>`/s'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX561"></A>
|
|
<A NAME="IDX562"></A>
|
|
<DT><CODE>INSN_DELETED_P (<VAR>insn</VAR>)</CODE>
|
|
<DD>In an insn, nonzero if the insn has been deleted. Stored in the
|
|
<CODE>volatil</CODE> field and printed as <SAMP>`/v'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX563"></A>
|
|
<A NAME="IDX564"></A>
|
|
<A NAME="IDX565"></A>
|
|
<DT><CODE>INSN_ANNULLED_BRANCH_P (<VAR>insn</VAR>)</CODE>
|
|
<DD>In an <CODE>insn</CODE> in the delay slot of a branch insn, indicates that an
|
|
annulling branch should be used. See the discussion under
|
|
<CODE>sequence</CODE> below. Stored in the <CODE>unchanging</CODE> field and printed
|
|
as <SAMP>`/u'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX566"></A>
|
|
<A NAME="IDX567"></A>
|
|
<A NAME="IDX568"></A>
|
|
<A NAME="IDX569"></A>
|
|
<DT><CODE>INSN_FROM_TARGET_P (<VAR>insn</VAR>)</CODE>
|
|
<DD>In an <CODE>insn</CODE> in a delay slot of a branch, indicates that the insn
|
|
is from the target of the branch. If the branch insn has
|
|
<CODE>INSN_ANNULLED_BRANCH_P</CODE> set, this insn will only be executed if
|
|
the branch is taken. For annulled branches with
|
|
<CODE>INSN_FROM_TARGET_P</CODE> clear, the insn will be executed only if the
|
|
branch is not taken. When <CODE>INSN_ANNULLED_BRANCH_P</CODE> is not set,
|
|
this insn will always be executed. Stored in the <CODE>in_struct</CODE>
|
|
field and printed as <SAMP>`/s'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX570"></A>
|
|
<A NAME="IDX571"></A>
|
|
<A NAME="IDX572"></A>
|
|
<DT><CODE>CONSTANT_POOL_ADDRESS_P (<VAR>x</VAR>)</CODE>
|
|
<DD>Nonzero in a <CODE>symbol_ref</CODE> if it refers to part of the current
|
|
function's "constants pool". These are addresses close to the
|
|
beginning of the function, and GNU CC assumes they can be addressed
|
|
directly (perhaps with the help of base registers). Stored in the
|
|
<CODE>unchanging</CODE> field and printed as <SAMP>`/u'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX573"></A>
|
|
<A NAME="IDX574"></A>
|
|
<A NAME="IDX575"></A>
|
|
<DT><CODE>CONST_CALL_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In a <CODE>call_insn</CODE>, indicates that the insn represents a call to a const
|
|
function. Stored in the <CODE>unchanging</CODE> field and printed as <SAMP>`/u'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX576"></A>
|
|
<A NAME="IDX577"></A>
|
|
<A NAME="IDX578"></A>
|
|
<DT><CODE>LABEL_PRESERVE_P (<VAR>x</VAR>)</CODE>
|
|
<DD>In a <CODE>code_label</CODE>, indicates that the label can never be deleted.
|
|
Labels referenced by a non-local goto will have this bit set. Stored
|
|
in the <CODE>in_struct</CODE> field and printed as <SAMP>`/s'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX579"></A>
|
|
<A NAME="IDX580"></A>
|
|
<A NAME="IDX581"></A>
|
|
<DT><CODE>SCHED_GROUP_P (<VAR>insn</VAR>)</CODE>
|
|
<DD>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, <CODE>use</CODE> insns before a <CODE>call_insn</CODE> may
|
|
not be separated from the <CODE>call_insn</CODE>. Stored in the <CODE>in_struct</CODE>
|
|
field and printed as <SAMP>`/s'</SAMP>.
|
|
</DL>
|
|
<P>
|
|
|
|
These are the fields which the above macros refer to:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX582"></A>
|
|
<DT><CODE>used</CODE>
|
|
<DD>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 (see section <A HREF="gcc_15.html#SEC167" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC167">15.18 Structure Sharing Assumptions</A>).
|
|
<P>
|
|
|
|
In a <CODE>symbol_ref</CODE>, it indicates that an external declaration for
|
|
the symbol has already been written.
|
|
</P><P>
|
|
|
|
In a <CODE>reg</CODE>, it is used by the leaf register renumbering code to ensure
|
|
that each register is only renumbered once.
|
|
</P><P>
|
|
|
|
<A NAME="IDX583"></A>
|
|
<DT><CODE>volatil</CODE>
|
|
<DD>This flag is used in <CODE>mem</CODE>, <CODE>symbol_ref</CODE> and <CODE>reg</CODE>
|
|
expressions and in insns. In RTL dump files, it is printed as
|
|
<SAMP>`/v'</SAMP>.
|
|
<P>
|
|
|
|
<A NAME="IDX584"></A>
|
|
In a <CODE>mem</CODE> expression, it is 1 if the memory reference is volatile.
|
|
Volatile memory references may not be deleted, reordered or combined.
|
|
</P><P>
|
|
|
|
In a <CODE>symbol_ref</CODE> expression, it is used for machine-specific
|
|
purposes.
|
|
</P><P>
|
|
|
|
In a <CODE>reg</CODE> expression, it is 1 if the value is a user-level variable.
|
|
0 indicates an internal compiler temporary.
|
|
</P><P>
|
|
|
|
In an insn, 1 means the insn has been deleted.
|
|
</P><P>
|
|
|
|
<A NAME="IDX585"></A>
|
|
<DT><CODE>in_struct</CODE>
|
|
<DD>In <CODE>mem</CODE> 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.
|
|
<P>
|
|
|
|
In an insn in the delay slot of a branch, 1 means that this insn is from
|
|
the target of the branch.
|
|
</P><P>
|
|
|
|
During instruction scheduling, in an insn, 1 means that this insn must be
|
|
scheduled as part of a group together with the previous insn.
|
|
</P><P>
|
|
|
|
In <CODE>reg</CODE> expressions, it is 1 if the register has its entire life
|
|
contained within the test expression of some loop.
|
|
</P><P>
|
|
|
|
In <CODE>subreg</CODE> expressions, 1 means that the <CODE>subreg</CODE> is accessing
|
|
an object that has had its mode promoted from a wider mode.
|
|
</P><P>
|
|
|
|
In <CODE>label_ref</CODE> expressions, 1 means that the referenced label is
|
|
outside the innermost loop containing the insn in which the <CODE>label_ref</CODE>
|
|
was found.
|
|
</P><P>
|
|
|
|
In <CODE>code_label</CODE> expressions, it is 1 if the label may never be deleted.
|
|
This is used for labels which are the target of non-local gotos.
|
|
</P><P>
|
|
|
|
In an RTL dump, this flag is represented as <SAMP>`/s'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX586"></A>
|
|
<DT><CODE>unchanging</CODE>
|
|
<DD>In <CODE>reg</CODE> and <CODE>mem</CODE> expressions, 1 means
|
|
that the value of the expression never changes.
|
|
<P>
|
|
|
|
In <CODE>subreg</CODE> expressions, it is 1 if the <CODE>subreg</CODE> references an
|
|
unsigned object whose mode has been promoted to a wider mode.
|
|
</P><P>
|
|
|
|
In an insn, 1 means that this is an annulling branch.
|
|
</P><P>
|
|
|
|
In a <CODE>symbol_ref</CODE> expression, 1 means that this symbol addresses
|
|
something in the per-function constants pool.
|
|
</P><P>
|
|
|
|
In a <CODE>call_insn</CODE>, 1 means that this instruction is a call to a
|
|
const function.
|
|
</P><P>
|
|
|
|
In an RTL dump, this flag is represented as <SAMP>`/u'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX587"></A>
|
|
<DT><CODE>integrated</CODE>
|
|
<DD>In some kinds of expressions, including insns, this flag means the
|
|
rtl was produced by procedure integration.
|
|
<P>
|
|
|
|
In a <CODE>reg</CODE> 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.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Machine Modes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC154"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC153" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC153"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC155" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC155"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.5 Machine Modes </H2>
|
|
<!--docid::SEC154::-->
|
|
<P>
|
|
|
|
<A NAME="IDX588"></A>
|
|
A machine mode describes a size of data object and the representation used
|
|
for it. In the C code, machine modes are represented by an enumeration
|
|
type, <CODE>enum machine_mode</CODE>, defined in <TT>`machmode.def'</TT>. Each RTL
|
|
expression has room for a machine mode and so do certain kinds of tree
|
|
expressions (declarations and types, to be precise).
|
|
</P><P>
|
|
|
|
In debugging dumps and machine descriptions, the machine mode of an RTL
|
|
expression is written after the expression code with a colon to separate
|
|
them. The letters <SAMP>`mode'</SAMP> which appear at the end of each machine mode
|
|
name are omitted. For example, <CODE>(reg:SI 38)</CODE> is a <CODE>reg</CODE>
|
|
expression with machine mode <CODE>SImode</CODE>. If the mode is
|
|
<CODE>VOIDmode</CODE>, it is not written at all.
|
|
</P><P>
|
|
|
|
Here is a table of machine modes. The term "byte" below refers to an
|
|
object of <CODE>BITS_PER_UNIT</CODE> bits (see section <A HREF="gcc_17.html#SEC202" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC202">17.3 Storage Layout</A>).
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX589"></A>
|
|
<DT><CODE>QImode</CODE>
|
|
<DD>"Quarter-Integer" mode represents a single byte treated as an integer.
|
|
<P>
|
|
|
|
<A NAME="IDX590"></A>
|
|
<DT><CODE>HImode</CODE>
|
|
<DD>"Half-Integer" mode represents a two-byte integer.
|
|
<P>
|
|
|
|
<A NAME="IDX591"></A>
|
|
<DT><CODE>PSImode</CODE>
|
|
<DD>"Partial Single Integer" mode represents an integer which occupies
|
|
four bytes but which doesn't really use all four. On some machines,
|
|
this is the right mode to use for pointers.
|
|
<P>
|
|
|
|
<A NAME="IDX592"></A>
|
|
<DT><CODE>SImode</CODE>
|
|
<DD>"Single Integer" mode represents a four-byte integer.
|
|
<P>
|
|
|
|
<A NAME="IDX593"></A>
|
|
<DT><CODE>PDImode</CODE>
|
|
<DD>"Partial Double Integer" mode represents an integer which occupies
|
|
eight bytes but which doesn't really use all eight. On some machines,
|
|
this is the right mode to use for certain pointers.
|
|
<P>
|
|
|
|
<A NAME="IDX594"></A>
|
|
<DT><CODE>DImode</CODE>
|
|
<DD>"Double Integer" mode represents an eight-byte integer.
|
|
<P>
|
|
|
|
<A NAME="IDX595"></A>
|
|
<DT><CODE>TImode</CODE>
|
|
<DD>"Tetra Integer" (?) mode represents a sixteen-byte integer.
|
|
<P>
|
|
|
|
<A NAME="IDX596"></A>
|
|
<DT><CODE>SFmode</CODE>
|
|
<DD>"Single Floating" mode represents a single-precision (four byte) floating
|
|
point number.
|
|
<P>
|
|
|
|
<A NAME="IDX597"></A>
|
|
<DT><CODE>DFmode</CODE>
|
|
<DD>"Double Floating" mode represents a double-precision (eight byte) floating
|
|
point number.
|
|
<P>
|
|
|
|
<A NAME="IDX598"></A>
|
|
<DT><CODE>XFmode</CODE>
|
|
<DD>"Extended Floating" mode represents a triple-precision (twelve byte)
|
|
floating point number. This mode is used for IEEE extended floating
|
|
point. On some systems not all bits within these bytes will actually
|
|
be used.
|
|
<P>
|
|
|
|
<A NAME="IDX599"></A>
|
|
<DT><CODE>TFmode</CODE>
|
|
<DD>"Tetra Floating" mode represents a quadruple-precision (sixteen byte)
|
|
floating point number.
|
|
<P>
|
|
|
|
<A NAME="IDX600"></A>
|
|
<DT><CODE>CCmode</CODE>
|
|
<DD>"Condition Code" mode represents the value of a condition code, which
|
|
is a machine-specific set of bits used to represent the result of a
|
|
comparison operation. Other machine-specific modes may also be used for
|
|
the condition code. These modes are not used on machines that use
|
|
<CODE>cc0</CODE> (see see section <A HREF="gcc_17.html#SEC228" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC228">17.12 Condition Code Status</A>).
|
|
<P>
|
|
|
|
<A NAME="IDX601"></A>
|
|
<DT><CODE>BLKmode</CODE>
|
|
<DD>"Block" mode represents values that are aggregates to which none of
|
|
the other modes apply. In RTL, only memory references can have this mode,
|
|
and only if they appear in string-move or vector instructions. On machines
|
|
which have no such instructions, <CODE>BLKmode</CODE> will not appear in RTL.
|
|
<P>
|
|
|
|
<A NAME="IDX602"></A>
|
|
<DT><CODE>VOIDmode</CODE>
|
|
<DD>Void mode means the absence of a mode or an unspecified mode.
|
|
For example, RTL expressions of code <CODE>const_int</CODE> have mode
|
|
<CODE>VOIDmode</CODE> because they can be taken to have whatever mode the context
|
|
requires. In debugging dumps of RTL, <CODE>VOIDmode</CODE> is expressed by
|
|
the absence of any mode.
|
|
<P>
|
|
|
|
<A NAME="IDX603"></A>
|
|
<A NAME="IDX604"></A>
|
|
<A NAME="IDX605"></A>
|
|
<A NAME="IDX606"></A>
|
|
<DT><CODE>SCmode, DCmode, XCmode, TCmode</CODE>
|
|
<DD>These modes stand for a complex number represented as a pair of floating
|
|
point values. The floating point values are in <CODE>SFmode</CODE>,
|
|
<CODE>DFmode</CODE>, <CODE>XFmode</CODE>, and <CODE>TFmode</CODE>, respectively.
|
|
<P>
|
|
|
|
<A NAME="IDX607"></A>
|
|
<A NAME="IDX608"></A>
|
|
<A NAME="IDX609"></A>
|
|
<A NAME="IDX610"></A>
|
|
<A NAME="IDX611"></A>
|
|
<A NAME="IDX612"></A>
|
|
<DT><CODE>CQImode, CHImode, CSImode, CDImode, CTImode, COImode</CODE>
|
|
<DD>These modes stand for a complex number represented as a pair of integer
|
|
values. The integer values are in <CODE>QImode</CODE>, <CODE>HImode</CODE>,
|
|
<CODE>SImode</CODE>, <CODE>DImode</CODE>, <CODE>TImode</CODE>, and <CODE>OImode</CODE>,
|
|
respectively.
|
|
</DL>
|
|
<P>
|
|
|
|
The machine description defines <CODE>Pmode</CODE> as a C macro which expands
|
|
into the machine mode used for addresses. Normally this is the mode
|
|
whose size is <CODE>BITS_PER_WORD</CODE>, <CODE>SImode</CODE> on 32-bit machines.
|
|
</P><P>
|
|
|
|
The only modes which a machine description <I>must</I> support are
|
|
<CODE>QImode</CODE>, and the modes corresponding to <CODE>BITS_PER_WORD</CODE>,
|
|
<CODE>FLOAT_TYPE_SIZE</CODE> and <CODE>DOUBLE_TYPE_SIZE</CODE>.
|
|
The compiler will attempt to use <CODE>DImode</CODE> for 8-byte structures and
|
|
unions, but this can be prevented by overriding the definition of
|
|
<CODE>MAX_FIXED_MODE_SIZE</CODE>. Alternatively, you can have the compiler
|
|
use <CODE>TImode</CODE> for 16-byte structures and unions. Likewise, you can
|
|
arrange for the C type <CODE>short int</CODE> to avoid using <CODE>HImode</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX613"></A>
|
|
Very few explicit references to machine modes remain in the compiler and
|
|
these few references will soon be removed. Instead, the machine modes
|
|
are divided into mode classes. These are represented by the enumeration
|
|
type <CODE>enum mode_class</CODE> defined in <TT>`machmode.h'</TT>. The possible
|
|
mode classes are:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX614"></A>
|
|
<DT><CODE>MODE_INT</CODE>
|
|
<DD>Integer modes. By default these are <CODE>QImode</CODE>, <CODE>HImode</CODE>,
|
|
<CODE>SImode</CODE>, <CODE>DImode</CODE>, and <CODE>TImode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX615"></A>
|
|
<DT><CODE>MODE_PARTIAL_INT</CODE>
|
|
<DD>The "partial integer" modes, <CODE>PSImode</CODE> and <CODE>PDImode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX616"></A>
|
|
<DT><CODE>MODE_FLOAT</CODE>
|
|
<DD>floating point modes. By default these are <CODE>SFmode</CODE>, <CODE>DFmode</CODE>,
|
|
<CODE>XFmode</CODE> and <CODE>TFmode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX617"></A>
|
|
<DT><CODE>MODE_COMPLEX_INT</CODE>
|
|
<DD>Complex integer modes. (These are not currently implemented).
|
|
<P>
|
|
|
|
<A NAME="IDX618"></A>
|
|
<DT><CODE>MODE_COMPLEX_FLOAT</CODE>
|
|
<DD>Complex floating point modes. By default these are <CODE>SCmode</CODE>,
|
|
<CODE>DCmode</CODE>, <CODE>XCmode</CODE>, and <CODE>TCmode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX619"></A>
|
|
<DT><CODE>MODE_FUNCTION</CODE>
|
|
<DD>Algol or Pascal function variables including a static chain.
|
|
(These are not currently implemented).
|
|
<P>
|
|
|
|
<A NAME="IDX620"></A>
|
|
<DT><CODE>MODE_CC</CODE>
|
|
<DD>Modes representing condition code values. These are <CODE>CCmode</CODE> plus
|
|
any modes listed in the <CODE>EXTRA_CC_MODES</CODE> macro. See section <A HREF="gcc_16.html#SEC185" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC185">16.10 Defining Jump Instruction Patterns</A>,
|
|
also see <A HREF="gcc_17.html#SEC228" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC228">17.12 Condition Code Status</A>.
|
|
<P>
|
|
|
|
<A NAME="IDX621"></A>
|
|
<DT><CODE>MODE_RANDOM</CODE>
|
|
<DD>This is a catchall mode class for modes which don't fit into the above
|
|
classes. Currently <CODE>VOIDmode</CODE> and <CODE>BLKmode</CODE> are in
|
|
<CODE>MODE_RANDOM</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
Here are some C macros that relate to machine modes:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX622"></A>
|
|
<DT><CODE>GET_MODE (<VAR>x</VAR>)</CODE>
|
|
<DD>Returns the machine mode of the RTX <VAR>x</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX623"></A>
|
|
<DT><CODE>PUT_MODE (<VAR>x</VAR>, <VAR>newmode</VAR>)</CODE>
|
|
<DD>Alters the machine mode of the RTX <VAR>x</VAR> to be <VAR>newmode</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX624"></A>
|
|
<DT><CODE>NUM_MACHINE_MODES</CODE>
|
|
<DD>Stands for the number of machine modes available on the target
|
|
machine. This is one greater than the largest numeric value of any
|
|
machine mode.
|
|
<P>
|
|
|
|
<A NAME="IDX625"></A>
|
|
<DT><CODE>GET_MODE_NAME (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the name of mode <VAR>m</VAR> as a string.
|
|
<P>
|
|
|
|
<A NAME="IDX626"></A>
|
|
<DT><CODE>GET_MODE_CLASS (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the mode class of mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX627"></A>
|
|
<DT><CODE>GET_MODE_WIDER_MODE (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the next wider natural mode. For example, the expression
|
|
<CODE>GET_MODE_WIDER_MODE (QImode)</CODE> returns <CODE>HImode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX628"></A>
|
|
<DT><CODE>GET_MODE_SIZE (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the size in bytes of a datum of mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX629"></A>
|
|
<DT><CODE>GET_MODE_BITSIZE (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the size in bits of a datum of mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX630"></A>
|
|
<DT><CODE>GET_MODE_MASK (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns a bitmask containing 1 for all bits in a word that fit within
|
|
mode <VAR>m</VAR>. This macro can only be used for modes whose bitsize is
|
|
less than or equal to <CODE>HOST_BITS_PER_INT</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX631"></A>
|
|
<DT><CODE>GET_MODE_ALIGNMENT (<VAR>m)</VAR>)</CODE>
|
|
<DD>Return the required alignment, in bits, for an object of mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX632"></A>
|
|
<DT><CODE>GET_MODE_UNIT_SIZE (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the size in bytes of the subunits of a datum of mode <VAR>m</VAR>.
|
|
This is the same as <CODE>GET_MODE_SIZE</CODE> except in the case of complex
|
|
modes. For them, the unit size is the size of the real or imaginary
|
|
part.
|
|
<P>
|
|
|
|
<A NAME="IDX633"></A>
|
|
<DT><CODE>GET_MODE_NUNITS (<VAR>m</VAR>)</CODE>
|
|
<DD>Returns the number of units contained in a mode, i.e.,
|
|
<CODE>GET_MODE_SIZE</CODE> divided by <CODE>GET_MODE_UNIT_SIZE</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX634"></A>
|
|
<DT><CODE>GET_CLASS_NARROWEST_MODE (<VAR>c</VAR>)</CODE>
|
|
<DD>Returns the narrowest mode in mode class <VAR>c</VAR>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX635"></A>
|
|
<A NAME="IDX636"></A>
|
|
The global variables <CODE>byte_mode</CODE> and <CODE>word_mode</CODE> contain modes
|
|
whose classes are <CODE>MODE_INT</CODE> and whose bitsizes are either
|
|
<CODE>BITS_PER_UNIT</CODE> or <CODE>BITS_PER_WORD</CODE>, respectively. On 32-bit
|
|
machines, these are <CODE>QImode</CODE> and <CODE>SImode</CODE>, respectively.
|
|
</P><P>
|
|
|
|
<A NAME="Constants"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC155"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC154" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC154"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC156" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC156"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.6 Constant Expression Types </H2>
|
|
<!--docid::SEC155::-->
|
|
<P>
|
|
|
|
The simplest RTL expressions are those that represent constant values.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX637"></A>
|
|
<DT><CODE>(const_int <VAR>i</VAR>)</CODE>
|
|
<DD>This type of expression represents the integer value <VAR>i</VAR>. <VAR>i</VAR>
|
|
is customarily accessed with the macro <CODE>INTVAL</CODE> as in
|
|
<CODE>INTVAL (<VAR>exp</VAR>)</CODE>, which is equivalent to <CODE>XWINT (<VAR>exp</VAR>, 0)</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX638"></A>
|
|
<A NAME="IDX639"></A>
|
|
<A NAME="IDX640"></A>
|
|
<A NAME="IDX641"></A>
|
|
There is only one expression object for the integer value zero; it is
|
|
the value of the variable <CODE>const0_rtx</CODE>. Likewise, the only
|
|
expression for integer value one is found in <CODE>const1_rtx</CODE>, the only
|
|
expression for integer value two is found in <CODE>const2_rtx</CODE>, and the
|
|
only expression for integer value negative one is found in
|
|
<CODE>constm1_rtx</CODE>. Any attempt to create an expression of code
|
|
<CODE>const_int</CODE> and value zero, one, two or negative one will return
|
|
<CODE>const0_rtx</CODE>, <CODE>const1_rtx</CODE>, <CODE>const2_rtx</CODE> or
|
|
<CODE>constm1_rtx</CODE> as appropriate.</P><P>
|
|
|
|
<A NAME="IDX642"></A>
|
|
Similarly, there is only one object for the integer whose value is
|
|
<CODE>STORE_FLAG_VALUE</CODE>. It is found in <CODE>const_true_rtx</CODE>. If
|
|
<CODE>STORE_FLAG_VALUE</CODE> is one, <CODE>const_true_rtx</CODE> and
|
|
<CODE>const1_rtx</CODE> will point to the same object. If
|
|
<CODE>STORE_FLAG_VALUE</CODE> is -1, <CODE>const_true_rtx</CODE> and
|
|
<CODE>constm1_rtx</CODE> will point to the same object.</P><P>
|
|
|
|
<A NAME="IDX643"></A>
|
|
<DT><CODE>(const_double:<VAR>m</VAR> <VAR>addr</VAR> <VAR>i0</VAR> <VAR>i1</VAR> <small>...</small>)</CODE>
|
|
<DD>Represents either a floating-point constant of mode <VAR>m</VAR> or an
|
|
integer constant too large to fit into <CODE>HOST_BITS_PER_WIDE_INT</CODE>
|
|
bits but small enough to fit within twice that number of bits (GNU CC
|
|
does not provide a mechanism to represent even larger constants). In
|
|
the latter case, <VAR>m</VAR> will be <CODE>VOIDmode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX644"></A>
|
|
<A NAME="IDX645"></A>
|
|
<VAR>addr</VAR> is used to contain the <CODE>mem</CODE> expression that corresponds
|
|
to the location in memory that at which the constant can be found. If
|
|
it has not been allocated a memory location, but is on the chain of all
|
|
<CODE>const_double</CODE> expressions in this compilation (maintained using an
|
|
undisplayed field), <VAR>addr</VAR> contains <CODE>const0_rtx</CODE>. If it is not
|
|
on the chain, <VAR>addr</VAR> contains <CODE>cc0_rtx</CODE>. <VAR>addr</VAR> is
|
|
customarily accessed with the macro <CODE>CONST_DOUBLE_MEM</CODE> and the
|
|
chain field via <CODE>CONST_DOUBLE_CHAIN</CODE>.</P><P>
|
|
|
|
<A NAME="IDX646"></A>
|
|
If <VAR>m</VAR> is <CODE>VOIDmode</CODE>, the bits of the value are stored in
|
|
<VAR>i0</VAR> and <VAR>i1</VAR>. <VAR>i0</VAR> is customarily accessed with the macro
|
|
<CODE>CONST_DOUBLE_LOW</CODE> and <VAR>i1</VAR> with <CODE>CONST_DOUBLE_HIGH</CODE>.
|
|
</P><P>
|
|
|
|
If the constant is floating point (regardless of its precision), then
|
|
the number of integers used to store the value depends on the size of
|
|
<CODE>REAL_VALUE_TYPE</CODE> (see section <A HREF="gcc_17.html#SEC249" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC249">17.18 Cross Compilation and Floating Point</A>). The integers
|
|
represent a floating point number, but not precisely in the target
|
|
machine's or host machine's floating point format. To convert them to
|
|
the precise bit pattern used by the target machine, use the macro
|
|
<CODE>REAL_VALUE_TO_TARGET_DOUBLE</CODE> and friends (see section <A HREF="gcc_17.html#SEC234" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC234">17.16.2 Output of Data</A>).
|
|
</P><P>
|
|
|
|
<A NAME="IDX647"></A>
|
|
<A NAME="IDX648"></A>
|
|
<A NAME="IDX649"></A>
|
|
The macro <CODE>CONST0_RTX (<VAR>mode</VAR>)</CODE> refers to an expression with
|
|
value 0 in mode <VAR>mode</VAR>. If mode <VAR>mode</VAR> is of mode class
|
|
<CODE>MODE_INT</CODE>, it returns <CODE>const0_rtx</CODE>. Otherwise, it returns a
|
|
<CODE>CONST_DOUBLE</CODE> expression in mode <VAR>mode</VAR>. Similarly, the macro
|
|
<CODE>CONST1_RTX (<VAR>mode</VAR>)</CODE> refers to an expression with value 1 in
|
|
mode <VAR>mode</VAR> and similarly for <CODE>CONST2_RTX</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX650"></A>
|
|
<DT><CODE>(const_string <VAR>str</VAR>)</CODE>
|
|
<DD>Represents a constant string with value <VAR>str</VAR>. Currently this is
|
|
used only for insn attributes (see section <A HREF="gcc_16.html#SEC190" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC190">16.15 Instruction Attributes</A>) since constant
|
|
strings in C are placed in memory.
|
|
<P>
|
|
|
|
<A NAME="IDX651"></A>
|
|
<DT><CODE>(symbol_ref:<VAR>mode</VAR> <VAR>symbol</VAR>)</CODE>
|
|
<DD>Represents the value of an assembler label for data. <VAR>symbol</VAR> is
|
|
a string that describes the name of the assembler label. If it starts
|
|
with a <SAMP>`*'</SAMP>, the label is the rest of <VAR>symbol</VAR> not including
|
|
the <SAMP>`*'</SAMP>. Otherwise, the label is <VAR>symbol</VAR>, usually prefixed
|
|
with <SAMP>`_'</SAMP>.
|
|
<P>
|
|
|
|
The <CODE>symbol_ref</CODE> contains a mode, which is usually <CODE>Pmode</CODE>.
|
|
Usually that is the only mode for which a symbol is directly valid.
|
|
</P><P>
|
|
|
|
<A NAME="IDX652"></A>
|
|
<DT><CODE>(label_ref <VAR>label</VAR>)</CODE>
|
|
<DD>Represents the value of an assembler label for code. It contains one
|
|
operand, an expression, which must be a <CODE>code_label</CODE> that appears
|
|
in the instruction sequence to identify the place where the label
|
|
should go.
|
|
<P>
|
|
|
|
The reason for using a distinct expression type for code label
|
|
references is so that jump optimization can distinguish them.
|
|
</P><P>
|
|
|
|
<DT><CODE>(const:<VAR>m</VAR> <VAR>exp</VAR>)</CODE>
|
|
<DD>Represents a constant that is the result of an assembly-time
|
|
arithmetic computation. The operand, <VAR>exp</VAR>, is an expression that
|
|
contains only constants (<CODE>const_int</CODE>, <CODE>symbol_ref</CODE> and
|
|
<CODE>label_ref</CODE> expressions) combined with <CODE>plus</CODE> and
|
|
<CODE>minus</CODE>. However, not all combinations are valid, since the
|
|
assembler cannot do arbitrary arithmetic on relocatable symbols.
|
|
<P>
|
|
|
|
<VAR>m</VAR> should be <CODE>Pmode</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX653"></A>
|
|
<DT><CODE>(high:<VAR>m</VAR> <VAR>exp</VAR>)</CODE>
|
|
<DD>Represents the high-order bits of <VAR>exp</VAR>, usually a
|
|
<CODE>symbol_ref</CODE>. The number of bits is machine-dependent and is
|
|
normally the number of bits specified in an instruction that initializes
|
|
the high order bits of a register. It is used with <CODE>lo_sum</CODE> to
|
|
represent the typical two-instruction sequence used in RISC machines to
|
|
reference a global memory location.
|
|
<P>
|
|
|
|
<VAR>m</VAR> should be <CODE>Pmode</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Regs and Memory"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC156"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC155" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC155"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC157" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC157"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.7 Registers and Memory </H2>
|
|
<!--docid::SEC156::-->
|
|
<P>
|
|
|
|
Here are the RTL expression types for describing access to machine
|
|
registers and to main memory.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX654"></A>
|
|
<A NAME="IDX655"></A>
|
|
<A NAME="IDX656"></A>
|
|
<DT><CODE>(reg:<VAR>m</VAR> <VAR>n</VAR>)</CODE>
|
|
<DD>For small values of the integer <VAR>n</VAR> (those that are less than
|
|
<CODE>FIRST_PSEUDO_REGISTER</CODE>), this stands for a reference to machine
|
|
register number <VAR>n</VAR>: a <EM>hard register</EM>. For larger values of
|
|
<VAR>n</VAR>, it stands for a temporary value or <EM>pseudo register</EM>.
|
|
The compiler's strategy is to generate code assuming an unlimited
|
|
number of such pseudo registers, and later convert them into hard
|
|
registers or into memory references.
|
|
<P>
|
|
|
|
<VAR>m</VAR> is the machine mode of the reference. It is necessary because
|
|
machines can generally refer to each register in more than one mode.
|
|
For example, a register may contain a full word but there may be
|
|
instructions to refer to it as a half word or as a single byte, as
|
|
well as instructions to refer to it as a floating point number of
|
|
various precisions.
|
|
</P><P>
|
|
|
|
Even for a register that the machine can access in only one mode,
|
|
the mode must always be specified.
|
|
</P><P>
|
|
|
|
The symbol <CODE>FIRST_PSEUDO_REGISTER</CODE> is defined by the machine
|
|
description, since the number of hard registers on the machine is an
|
|
invariant characteristic of the machine. Note, however, that not
|
|
all of the machine registers must be general registers. All the
|
|
machine registers that can be used for storage of data are given
|
|
hard register numbers, even those that can be used only in certain
|
|
instructions or can hold only certain types of data.
|
|
</P><P>
|
|
|
|
A hard register may be accessed in various modes throughout one
|
|
function, but each pseudo register is given a natural mode
|
|
and is accessed only in that mode. When it is necessary to describe
|
|
an access to a pseudo register using a nonnatural mode, a <CODE>subreg</CODE>
|
|
expression is used.
|
|
</P><P>
|
|
|
|
A <CODE>reg</CODE> expression with a machine mode that specifies more than
|
|
one word of data may actually stand for several consecutive registers.
|
|
If in addition the register number specifies a hardware register, then
|
|
it actually represents several consecutive hardware registers starting
|
|
with the specified one.
|
|
</P><P>
|
|
|
|
Each pseudo register number used in a function's RTL code is
|
|
represented by a unique <CODE>reg</CODE> expression.
|
|
</P><P>
|
|
|
|
<A NAME="IDX657"></A>
|
|
<A NAME="IDX658"></A>
|
|
Some pseudo register numbers, those within the range of
|
|
<CODE>FIRST_VIRTUAL_REGISTER</CODE> to <CODE>LAST_VIRTUAL_REGISTER</CODE> only
|
|
appear during the RTL generation phase and are eliminated before the
|
|
optimization phases. These represent locations in the stack frame that
|
|
cannot be determined until RTL generation for the function has been
|
|
completed. The following virtual register numbers are defined:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX659"></A>
|
|
<DT><CODE>VIRTUAL_INCOMING_ARGS_REGNUM</CODE>
|
|
<DD>This points to the first word of the incoming arguments passed on the
|
|
stack. Normally these arguments are placed there by the caller, but the
|
|
callee may have pushed some arguments that were previously passed in
|
|
registers.
|
|
<P>
|
|
|
|
<A NAME="IDX660"></A>
|
|
<A NAME="IDX661"></A>
|
|
When RTL generation is complete, this virtual register is replaced
|
|
by the sum of the register given by <CODE>ARG_POINTER_REGNUM</CODE> and the
|
|
value of <CODE>FIRST_PARM_OFFSET</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX662"></A>
|
|
<A NAME="IDX663"></A>
|
|
<DT><CODE>VIRTUAL_STACK_VARS_REGNUM</CODE>
|
|
<DD>If <CODE>FRAME_GROWS_DOWNWARD</CODE> is defined, this points to immediately
|
|
above the first variable on the stack. Otherwise, it points to the
|
|
first variable on the stack.
|
|
<P>
|
|
|
|
<A NAME="IDX664"></A>
|
|
<A NAME="IDX665"></A>
|
|
<CODE>VIRTUAL_STACK_VARS_REGNUM</CODE> is replaced with the sum of the
|
|
register given by <CODE>FRAME_POINTER_REGNUM</CODE> and the value
|
|
<CODE>STARTING_FRAME_OFFSET</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX666"></A>
|
|
<DT><CODE>VIRTUAL_STACK_DYNAMIC_REGNUM</CODE>
|
|
<DD>This points to the location of dynamically allocated memory on the stack
|
|
immediately after the stack pointer has been adjusted by the amount of
|
|
memory desired.
|
|
<P>
|
|
|
|
<A NAME="IDX667"></A>
|
|
<A NAME="IDX668"></A>
|
|
This virtual register is replaced by the sum of the register given by
|
|
<CODE>STACK_POINTER_REGNUM</CODE> and the value <CODE>STACK_DYNAMIC_OFFSET</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX669"></A>
|
|
<DT><CODE>VIRTUAL_OUTGOING_ARGS_REGNUM</CODE>
|
|
<DD>This points to the location in the stack at which outgoing arguments
|
|
should be written when the stack is pre-pushed (arguments pushed using
|
|
push insns should always use <CODE>STACK_POINTER_REGNUM</CODE>).
|
|
<P>
|
|
|
|
<A NAME="IDX670"></A>
|
|
This virtual register is replaced by the sum of the register given by
|
|
<CODE>STACK_POINTER_REGNUM</CODE> and the value <CODE>STACK_POINTER_OFFSET</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX671"></A>
|
|
<DT><CODE>(subreg:<VAR>m</VAR> <VAR>reg</VAR> <VAR>wordnum</VAR>)</CODE>
|
|
<DD><CODE>subreg</CODE> expressions are used to refer to a register in a machine
|
|
mode other than its natural one, or to refer to one register of
|
|
a multi-word <CODE>reg</CODE> that actually refers to several registers.
|
|
<P>
|
|
|
|
Each pseudo-register has a natural mode. If it is necessary to
|
|
operate on it in a different mode--for example, to perform a fullword
|
|
move instruction on a pseudo-register that contains a single
|
|
byte--the pseudo-register must be enclosed in a <CODE>subreg</CODE>. In
|
|
such a case, <VAR>wordnum</VAR> is zero.
|
|
</P><P>
|
|
|
|
Usually <VAR>m</VAR> is at least as narrow as the mode of <VAR>reg</VAR>, in which
|
|
case it is restricting consideration to only the bits of <VAR>reg</VAR> that
|
|
are in <VAR>m</VAR>.
|
|
</P><P>
|
|
|
|
Sometimes <VAR>m</VAR> is wider than the mode of <VAR>reg</VAR>. These
|
|
<CODE>subreg</CODE> expressions are often called <EM>paradoxical</EM>. They are
|
|
used in cases where we want to refer to an object in a wider mode but do
|
|
not care what value the additional bits have. The reload pass ensures
|
|
that paradoxical references are only made to hard registers.
|
|
</P><P>
|
|
|
|
The other use of <CODE>subreg</CODE> is to extract the individual registers of
|
|
a multi-register value. Machine modes such as <CODE>DImode</CODE> and
|
|
<CODE>TImode</CODE> can indicate values longer than a word, values which
|
|
usually require two or more consecutive registers. To access one of the
|
|
registers, use a <CODE>subreg</CODE> with mode <CODE>SImode</CODE> and a
|
|
<VAR>wordnum</VAR> that says which register.
|
|
</P><P>
|
|
|
|
Storing in a non-paradoxical <CODE>subreg</CODE> has undefined results for
|
|
bits belonging to the same word as the <CODE>subreg</CODE>. This laxity makes
|
|
it easier to generate efficient code for such instructions. To
|
|
represent an instruction that preserves all the bits outside of those in
|
|
the <CODE>subreg</CODE>, use <CODE>strict_low_part</CODE> around the <CODE>subreg</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX672"></A>
|
|
The compilation parameter <CODE>WORDS_BIG_ENDIAN</CODE>, if set to 1, says
|
|
that word number zero is the most significant part; otherwise, it is
|
|
the least significant part.
|
|
</P><P>
|
|
|
|
<A NAME="IDX673"></A>
|
|
On a few targets, <CODE>FLOAT_WORDS_BIG_ENDIAN</CODE> disagrees with
|
|
<CODE>WORDS_BIG_ENDIAN</CODE>.
|
|
However, most parts of the compiler treat floating point values as if
|
|
they had the same endianness as integer values. This works because
|
|
they handle them solely as a collection of integer values, with no
|
|
particular numerical value. Only real.c and the runtime libraries
|
|
care about <CODE>FLOAT_WORDS_BIG_ENDIAN</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX674"></A>
|
|
<A NAME="IDX675"></A>
|
|
<A NAME="IDX676"></A>
|
|
Between the combiner pass and the reload pass, it is possible to have a
|
|
paradoxical <CODE>subreg</CODE> which contains a <CODE>mem</CODE> instead of a
|
|
<CODE>reg</CODE> as its first operand. After the reload pass, it is also
|
|
possible to have a non-paradoxical <CODE>subreg</CODE> which contains a
|
|
<CODE>mem</CODE>; this usually occurs when the <CODE>mem</CODE> is a stack slot
|
|
which replaced a pseudo register.
|
|
</P><P>
|
|
|
|
Note that it is not valid to access a <CODE>DFmode</CODE> value in <CODE>SFmode</CODE>
|
|
using a <CODE>subreg</CODE>. On some machines the most significant part of a
|
|
<CODE>DFmode</CODE> value does not have the same format as a single-precision
|
|
floating value.
|
|
</P><P>
|
|
|
|
It is also not valid to access a single word of a multi-word value in a
|
|
hard register when less registers can hold the value than would be
|
|
expected from its size. For example, some 32-bit machines have
|
|
floating-point registers that can hold an entire <CODE>DFmode</CODE> value.
|
|
If register 10 were such a register <CODE>(subreg:SI (reg:DF 10) 1)</CODE>
|
|
would be invalid because there is no way to convert that reference to
|
|
a single machine register. The reload pass prevents <CODE>subreg</CODE>
|
|
expressions such as these from being formed.
|
|
</P><P>
|
|
|
|
<A NAME="IDX677"></A>
|
|
<A NAME="IDX678"></A>
|
|
The first operand of a <CODE>subreg</CODE> expression is customarily accessed
|
|
with the <CODE>SUBREG_REG</CODE> macro and the second operand is customarily
|
|
accessed with the <CODE>SUBREG_WORD</CODE> macro.
|
|
</P><P>
|
|
|
|
<A NAME="IDX679"></A>
|
|
<A NAME="IDX680"></A>
|
|
<DT><CODE>(scratch:<VAR>m</VAR>)</CODE>
|
|
<DD>This represents a scratch register that will be required for the
|
|
execution of a single instruction and not used subsequently. It is
|
|
converted into a <CODE>reg</CODE> by either the local register allocator or
|
|
the reload pass.
|
|
<P>
|
|
|
|
<CODE>scratch</CODE> is usually present inside a <CODE>clobber</CODE> operation
|
|
(see section <A HREF="gcc_15.html#SEC162" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC162">15.13 Side Effect Expressions</A>).
|
|
</P><P>
|
|
|
|
<A NAME="IDX681"></A>
|
|
<A NAME="IDX682"></A>
|
|
<DT><CODE>(cc0)</CODE>
|
|
<DD>This refers to the machine's condition code register. It has no
|
|
operands and may not have a machine mode. There are two ways to use it:
|
|
<P>
|
|
|
|
<UL>
|
|
<LI>
|
|
To stand for a complete set of condition code flags. This is best on
|
|
most machines, where each comparison sets the entire series of flags.
|
|
<P>
|
|
|
|
With this technique, <CODE>(cc0)</CODE> may be validly used in only two
|
|
contexts: as the destination of an assignment (in test and compare
|
|
instructions) and in comparison operators comparing against zero
|
|
(<CODE>const_int</CODE> with value zero; that is to say, <CODE>const0_rtx</CODE>).
|
|
</P><P>
|
|
|
|
<LI>
|
|
To stand for a single flag that is the result of a single condition.
|
|
This is useful on machines that have only a single flag bit, and in
|
|
which comparison instructions must specify the condition to test.
|
|
<P>
|
|
|
|
With this technique, <CODE>(cc0)</CODE> may be validly used in only two
|
|
contexts: as the destination of an assignment (in test and compare
|
|
instructions) where the source is a comparison operator, and as the
|
|
first operand of <CODE>if_then_else</CODE> (in a conditional branch).
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="IDX683"></A>
|
|
There is only one expression object of code <CODE>cc0</CODE>; it is the
|
|
value of the variable <CODE>cc0_rtx</CODE>. Any attempt to create an
|
|
expression of code <CODE>cc0</CODE> will return <CODE>cc0_rtx</CODE>.
|
|
</P><P>
|
|
|
|
Instructions can set the condition code implicitly. On many machines,
|
|
nearly all instructions set the condition code based on the value that
|
|
they compute or store. It is not necessary to record these actions
|
|
explicitly in the RTL because the machine description includes a
|
|
prescription for recognizing the instructions that do so (by means of
|
|
the macro <CODE>NOTICE_UPDATE_CC</CODE>). See section <A HREF="gcc_17.html#SEC228" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC228">17.12 Condition Code Status</A>. Only
|
|
instructions whose sole purpose is to set the condition code, and
|
|
instructions that use the condition code, need mention <CODE>(cc0)</CODE>.
|
|
</P><P>
|
|
|
|
On some machines, the condition code register is given a register number
|
|
and a <CODE>reg</CODE> is used instead of <CODE>(cc0)</CODE>. This is usually the
|
|
preferable approach if only a small subset of instructions modify the
|
|
condition code. Other machines store condition codes in general
|
|
registers; in such cases a pseudo register should be used.
|
|
</P><P>
|
|
|
|
Some machines, such as the Sparc and RS/6000, have two sets of
|
|
arithmetic instructions, one that sets and one that does not set the
|
|
condition code. This is best handled by normally generating the
|
|
instruction that does not set the condition code, and making a pattern
|
|
that both performs the arithmetic and sets the condition code register
|
|
(which would not be <CODE>(cc0)</CODE> in this case). For examples, search
|
|
for <SAMP>`addcc'</SAMP> and <SAMP>`andcc'</SAMP> in <TT>`sparc.md'</TT>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX684"></A>
|
|
<DT><CODE>(pc)</CODE>
|
|
<DD><A NAME="IDX685"></A>
|
|
This represents the machine's program counter. It has no operands and
|
|
may not have a machine mode. <CODE>(pc)</CODE> may be validly used only in
|
|
certain specific contexts in jump instructions.
|
|
<P>
|
|
|
|
<A NAME="IDX686"></A>
|
|
There is only one expression object of code <CODE>pc</CODE>; it is the value
|
|
of the variable <CODE>pc_rtx</CODE>. Any attempt to create an expression of
|
|
code <CODE>pc</CODE> will return <CODE>pc_rtx</CODE>.
|
|
</P><P>
|
|
|
|
All instructions that do not jump alter the program counter implicitly
|
|
by incrementing it, but there is no need to mention this in the RTL.
|
|
</P><P>
|
|
|
|
<A NAME="IDX687"></A>
|
|
<DT><CODE>(mem:<VAR>m</VAR> <VAR>addr</VAR>)</CODE>
|
|
<DD>This RTX represents a reference to main memory at an address
|
|
represented by the expression <VAR>addr</VAR>. <VAR>m</VAR> specifies how large
|
|
a unit of memory is accessed.
|
|
<P>
|
|
|
|
<A NAME="IDX688"></A>
|
|
<DT><CODE>(addressof:<VAR>m</VAR> <VAR>reg</VAR>)</CODE>
|
|
<DD>This RTX represents a request for the address of register <VAR>reg</VAR>. Its mode
|
|
is always <CODE>Pmode</CODE>. If there are any <CODE>addressof</CODE>
|
|
expressions left in the function after CSE, <VAR>reg</VAR> is forced into the
|
|
stack and the <CODE>addressof</CODE> expression is replaced with a <CODE>plus</CODE>
|
|
expression for the address of its stack slot.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Arithmetic"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC157"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC156" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC156"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC158" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC158"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.8 RTL Expressions for Arithmetic </H2>
|
|
<!--docid::SEC157::-->
|
|
<P>
|
|
|
|
Unless otherwise specified, all the operands of arithmetic expressions
|
|
must be valid for mode <VAR>m</VAR>. An operand is valid for mode <VAR>m</VAR>
|
|
if it has mode <VAR>m</VAR>, or if it is a <CODE>const_int</CODE> or
|
|
<CODE>const_double</CODE> and <VAR>m</VAR> is a mode of class <CODE>MODE_INT</CODE>.
|
|
</P><P>
|
|
|
|
For commutative binary operations, constants should be placed in the
|
|
second operand.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX689"></A>
|
|
<A NAME="IDX690"></A>
|
|
<A NAME="IDX691"></A>
|
|
<DT><CODE>(plus:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the sum of the values represented by <VAR>x</VAR> and <VAR>y</VAR>
|
|
carried out in machine mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX692"></A>
|
|
<DT><CODE>(lo_sum:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>plus</CODE>, except that it represents that sum of <VAR>x</VAR> and the
|
|
low-order bits of <VAR>y</VAR>. The number of low order bits is
|
|
machine-dependent but is normally the number of bits in a <CODE>Pmode</CODE>
|
|
item minus the number of bits set by the <CODE>high</CODE> code
|
|
(see section <A HREF="gcc_15.html#SEC155" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC155">15.6 Constant Expression Types</A>).
|
|
<P>
|
|
|
|
<VAR>m</VAR> should be <CODE>Pmode</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX693"></A>
|
|
<A NAME="IDX694"></A>
|
|
<A NAME="IDX695"></A>
|
|
<DT><CODE>(minus:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>plus</CODE> but represents subtraction.
|
|
<P>
|
|
|
|
<A NAME="IDX696"></A>
|
|
<A NAME="IDX697"></A>
|
|
<DT><CODE>(compare:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the result of subtracting <VAR>y</VAR> from <VAR>x</VAR> for purposes
|
|
of comparison. The result is computed without overflow, as if with
|
|
infinite precision.
|
|
<P>
|
|
|
|
Of course, machines can't really subtract with infinite precision.
|
|
However, they can pretend to do so when only the sign of the
|
|
result will be used, which is the case when the result is stored
|
|
in the condition code. And that is the only way this kind of expression
|
|
may validly be used: as a value to be stored in the condition codes.
|
|
</P><P>
|
|
|
|
The mode <VAR>m</VAR> is not related to the modes of <VAR>x</VAR> and <VAR>y</VAR>,
|
|
but instead is the mode of the condition code value. If <CODE>(cc0)</CODE>
|
|
is used, it is <CODE>VOIDmode</CODE>. Otherwise it is some mode in class
|
|
<CODE>MODE_CC</CODE>, often <CODE>CCmode</CODE>. See section <A HREF="gcc_17.html#SEC228" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC228">17.12 Condition Code Status</A>.
|
|
</P><P>
|
|
|
|
Normally, <VAR>x</VAR> and <VAR>y</VAR> must have the same mode. Otherwise,
|
|
<CODE>compare</CODE> is valid only if the mode of <VAR>x</VAR> is in class
|
|
<CODE>MODE_INT</CODE> and <VAR>y</VAR> is a <CODE>const_int</CODE> or
|
|
<CODE>const_double</CODE> with mode <CODE>VOIDmode</CODE>. The mode of <VAR>x</VAR>
|
|
determines what mode the comparison is to be done in; thus it must not
|
|
be <CODE>VOIDmode</CODE>.
|
|
</P><P>
|
|
|
|
If one of the operands is a constant, it should be placed in the
|
|
second operand and the comparison code adjusted as appropriate.
|
|
</P><P>
|
|
|
|
A <CODE>compare</CODE> specifying two <CODE>VOIDmode</CODE> constants is not valid
|
|
since there is no way to know in what mode the comparison is to be
|
|
performed; the comparison must either be folded during the compilation
|
|
or the first operand must be loaded into a register while its mode is
|
|
still known.
|
|
</P><P>
|
|
|
|
<A NAME="IDX698"></A>
|
|
<DT><CODE>(neg:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the negation (subtraction from zero) of the value represented
|
|
by <VAR>x</VAR>, carried out in mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX699"></A>
|
|
<A NAME="IDX700"></A>
|
|
<A NAME="IDX701"></A>
|
|
<DT><CODE>(mult:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the signed product of the values represented by <VAR>x</VAR> and
|
|
<VAR>y</VAR> carried out in machine mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
Some machines support a multiplication that generates a product wider
|
|
than the operands. Write the pattern for this as
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(mult:<VAR>m</VAR> (sign_extend:<VAR>m</VAR> <VAR>x</VAR>) (sign_extend:<VAR>m</VAR> <VAR>y</VAR>))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
where <VAR>m</VAR> is wider than the modes of <VAR>x</VAR> and <VAR>y</VAR>, which need
|
|
not be the same.
|
|
</P><P>
|
|
|
|
Write patterns for unsigned widening multiplication similarly using
|
|
<CODE>zero_extend</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX702"></A>
|
|
<A NAME="IDX703"></A>
|
|
<A NAME="IDX704"></A>
|
|
<A NAME="IDX705"></A>
|
|
<DT><CODE>(div:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the quotient in signed division of <VAR>x</VAR> by <VAR>y</VAR>,
|
|
carried out in machine mode <VAR>m</VAR>. If <VAR>m</VAR> is a floating point
|
|
mode, it represents the exact quotient; otherwise, the integerized
|
|
quotient.
|
|
<P>
|
|
|
|
Some machines have division instructions in which the operands and
|
|
quotient widths are not all the same; you should represent
|
|
such instructions using <CODE>truncate</CODE> and <CODE>sign_extend</CODE> as in,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(truncate:<VAR>m1</VAR> (div:<VAR>m2</VAR> <VAR>x</VAR> (sign_extend:<VAR>m2</VAR> <VAR>y</VAR>)))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX706"></A>
|
|
<A NAME="IDX707"></A>
|
|
<A NAME="IDX708"></A>
|
|
<DT><CODE>(udiv:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>div</CODE> but represents unsigned division.
|
|
<P>
|
|
|
|
<A NAME="IDX709"></A>
|
|
<A NAME="IDX710"></A>
|
|
<A NAME="IDX711"></A>
|
|
<A NAME="IDX712"></A>
|
|
<DT><CODE>(mod:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(umod:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>div</CODE> and <CODE>udiv</CODE> but represent the remainder instead of
|
|
the quotient.
|
|
<P>
|
|
|
|
<A NAME="IDX713"></A>
|
|
<A NAME="IDX714"></A>
|
|
<A NAME="IDX715"></A>
|
|
<A NAME="IDX716"></A>
|
|
<DT><CODE>(smin:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(smax:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the smaller (for <CODE>smin</CODE>) or larger (for <CODE>smax</CODE>) of
|
|
<VAR>x</VAR> and <VAR>y</VAR>, interpreted as signed integers in mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX717"></A>
|
|
<A NAME="IDX718"></A>
|
|
<A NAME="IDX719"></A>
|
|
<DT><CODE>(umin:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(umax:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>smin</CODE> and <CODE>smax</CODE>, but the values are interpreted as unsigned
|
|
integers.
|
|
<P>
|
|
|
|
<A NAME="IDX720"></A>
|
|
<A NAME="IDX721"></A>
|
|
<A NAME="IDX722"></A>
|
|
<DT><CODE>(not:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the bitwise complement of the value represented by <VAR>x</VAR>,
|
|
carried out in mode <VAR>m</VAR>, which must be a fixed-point machine mode.
|
|
<P>
|
|
|
|
<A NAME="IDX723"></A>
|
|
<A NAME="IDX724"></A>
|
|
<A NAME="IDX725"></A>
|
|
<DT><CODE>(and:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the bitwise logical-and of the values represented by
|
|
<VAR>x</VAR> and <VAR>y</VAR>, carried out in machine mode <VAR>m</VAR>, which must be
|
|
a fixed-point machine mode.
|
|
<P>
|
|
|
|
<A NAME="IDX726"></A>
|
|
<A NAME="IDX727"></A>
|
|
<A NAME="IDX728"></A>
|
|
<DT><CODE>(ior:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the bitwise inclusive-or of the values represented by <VAR>x</VAR>
|
|
and <VAR>y</VAR>, carried out in machine mode <VAR>m</VAR>, which must be a
|
|
fixed-point mode.
|
|
<P>
|
|
|
|
<A NAME="IDX729"></A>
|
|
<A NAME="IDX730"></A>
|
|
<A NAME="IDX731"></A>
|
|
<DT><CODE>(xor:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Represents the bitwise exclusive-or of the values represented by <VAR>x</VAR>
|
|
and <VAR>y</VAR>, carried out in machine mode <VAR>m</VAR>, which must be a
|
|
fixed-point mode.
|
|
<P>
|
|
|
|
<A NAME="IDX732"></A>
|
|
<A NAME="IDX733"></A>
|
|
<A NAME="IDX734"></A>
|
|
<A NAME="IDX735"></A>
|
|
<DT><CODE>(ashift:<VAR>m</VAR> <VAR>x</VAR> <VAR>c</VAR>)</CODE>
|
|
<DD>Represents the result of arithmetically shifting <VAR>x</VAR> left by <VAR>c</VAR>
|
|
places. <VAR>x</VAR> have mode <VAR>m</VAR>, a fixed-point machine mode. <VAR>c</VAR>
|
|
be a fixed-point mode or be a constant with mode <CODE>VOIDmode</CODE>; which
|
|
mode is determined by the mode called for in the machine description
|
|
entry for the left-shift instruction. For example, on the Vax, the mode
|
|
of <VAR>c</VAR> is <CODE>QImode</CODE> regardless of <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX736"></A>
|
|
<A NAME="IDX737"></A>
|
|
<A NAME="IDX738"></A>
|
|
<DT><CODE>(lshiftrt:<VAR>m</VAR> <VAR>x</VAR> <VAR>c</VAR>)</CODE>
|
|
<DD><DT><CODE>(ashiftrt:<VAR>m</VAR> <VAR>x</VAR> <VAR>c</VAR>)</CODE>
|
|
<DD>Like <CODE>ashift</CODE> but for right shift. Unlike the case for left shift,
|
|
these two operations are distinct.
|
|
<P>
|
|
|
|
<A NAME="IDX739"></A>
|
|
<A NAME="IDX740"></A>
|
|
<A NAME="IDX741"></A>
|
|
<A NAME="IDX742"></A>
|
|
<A NAME="IDX743"></A>
|
|
<DT><CODE>(rotate:<VAR>m</VAR> <VAR>x</VAR> <VAR>c</VAR>)</CODE>
|
|
<DD><DT><CODE>(rotatert:<VAR>m</VAR> <VAR>x</VAR> <VAR>c</VAR>)</CODE>
|
|
<DD>Similar but represent left and right rotate. If <VAR>c</VAR> is a constant,
|
|
use <CODE>rotate</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX744"></A>
|
|
<A NAME="IDX745"></A>
|
|
<DT><CODE>(abs:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the absolute value of <VAR>x</VAR>, computed in mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX746"></A>
|
|
<A NAME="IDX747"></A>
|
|
<DT><CODE>(sqrt:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the square root of <VAR>x</VAR>, computed in mode <VAR>m</VAR>.
|
|
Most often <VAR>m</VAR> will be a floating point mode.
|
|
<P>
|
|
|
|
<A NAME="IDX748"></A>
|
|
<DT><CODE>(ffs:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents one plus the index of the least significant 1-bit in
|
|
<VAR>x</VAR>, represented as an integer of mode <VAR>m</VAR>. (The value is
|
|
zero if <VAR>x</VAR> is zero.) The mode of <VAR>x</VAR> need not be <VAR>m</VAR>;
|
|
depending on the target machine, various mode combinations may be
|
|
valid.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Comparisons"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC158"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC157" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC157"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC159" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC159"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.9 Comparison Operations </H2>
|
|
<!--docid::SEC158::-->
|
|
<P>
|
|
|
|
Comparison operators test a relation on two operands and are considered
|
|
to represent a machine-dependent nonzero value described by, but not
|
|
necessarily equal to, <CODE>STORE_FLAG_VALUE</CODE> (see section <A HREF="gcc_17.html#SEC250" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC250">17.19 Miscellaneous Parameters</A>)
|
|
if the relation holds, or zero if it does not. The mode of the
|
|
comparison operation is independent of the mode of the data being
|
|
compared. If the comparison operation is being tested (e.g., the first
|
|
operand of an <CODE>if_then_else</CODE>), the mode must be <CODE>VOIDmode</CODE>.
|
|
If the comparison operation is producing data to be stored in some
|
|
variable, the mode must be in class <CODE>MODE_INT</CODE>. All comparison
|
|
operations producing data must use the same mode, which is
|
|
machine-specific.
|
|
</P><P>
|
|
|
|
<A NAME="IDX749"></A>
|
|
There are two ways that comparison operations may be used. The
|
|
comparison operators may be used to compare the condition codes
|
|
<CODE>(cc0)</CODE> against zero, as in <CODE>(eq (cc0) (const_int 0))</CODE>. Such
|
|
a construct actually refers to the result of the preceding instruction
|
|
in which the condition codes were set. The instructing setting the
|
|
condition code must be adjacent to the instruction using the condition
|
|
code; only <CODE>note</CODE> insns may separate them.
|
|
</P><P>
|
|
|
|
Alternatively, a comparison operation may directly compare two data
|
|
objects. The mode of the comparison is determined by the operands; they
|
|
must both be valid for a common machine mode. A comparison with both
|
|
operands constant would be invalid as the machine mode could not be
|
|
deduced from it, but such a comparison should never exist in RTL due to
|
|
constant folding.
|
|
</P><P>
|
|
|
|
In the example above, if <CODE>(cc0)</CODE> were last set to
|
|
<CODE>(compare <VAR>x</VAR> <VAR>y</VAR>)</CODE>, the comparison operation is
|
|
identical to <CODE>(eq <VAR>x</VAR> <VAR>y</VAR>)</CODE>. Usually only one style
|
|
of comparisons is supported on a particular machine, but the combine
|
|
pass will try to merge the operations to produce the <CODE>eq</CODE> shown
|
|
in case it exists in the context of the particular insn involved.
|
|
</P><P>
|
|
|
|
Inequality comparisons come in two flavors, signed and unsigned. Thus,
|
|
there are distinct expression codes <CODE>gt</CODE> and <CODE>gtu</CODE> for signed and
|
|
unsigned greater-than. These can produce different results for the same
|
|
pair of integer values: for example, 1 is signed greater-than -1 but not
|
|
unsigned greater-than, because -1 when regarded as unsigned is actually
|
|
<CODE>0xffffffff</CODE> which is greater than 1.
|
|
</P><P>
|
|
|
|
The signed comparisons are also used for floating point values. Floating
|
|
point comparisons are distinguished by the machine modes of the operands.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX750"></A>
|
|
<A NAME="IDX751"></A>
|
|
<DT><CODE>(eq:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>1 if the values represented by <VAR>x</VAR> and <VAR>y</VAR> are equal,
|
|
otherwise 0.
|
|
<P>
|
|
|
|
<A NAME="IDX752"></A>
|
|
<A NAME="IDX753"></A>
|
|
<DT><CODE>(ne:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>1 if the values represented by <VAR>x</VAR> and <VAR>y</VAR> are not equal,
|
|
otherwise 0.
|
|
<P>
|
|
|
|
<A NAME="IDX754"></A>
|
|
<A NAME="IDX755"></A>
|
|
<DT><CODE>(gt:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>1 if the <VAR>x</VAR> is greater than <VAR>y</VAR>. If they are fixed-point,
|
|
the comparison is done in a signed sense.
|
|
<P>
|
|
|
|
<A NAME="IDX756"></A>
|
|
<A NAME="IDX757"></A>
|
|
<A NAME="IDX758"></A>
|
|
<DT><CODE>(gtu:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>gt</CODE> but does unsigned comparison, on fixed-point numbers only.
|
|
<P>
|
|
|
|
<A NAME="IDX759"></A>
|
|
<A NAME="IDX760"></A>
|
|
<A NAME="IDX761"></A>
|
|
<A NAME="IDX762"></A>
|
|
<DT><CODE>(lt:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(ltu:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>gt</CODE> and <CODE>gtu</CODE> but test for "less than".
|
|
<P>
|
|
|
|
<A NAME="IDX763"></A>
|
|
<A NAME="IDX764"></A>
|
|
<A NAME="IDX765"></A>
|
|
<A NAME="IDX766"></A>
|
|
<DT><CODE>(ge:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(geu:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>gt</CODE> and <CODE>gtu</CODE> but test for "greater than or equal".
|
|
<P>
|
|
|
|
<A NAME="IDX767"></A>
|
|
<A NAME="IDX768"></A>
|
|
<A NAME="IDX769"></A>
|
|
<A NAME="IDX770"></A>
|
|
<DT><CODE>(le:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><DT><CODE>(leu:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD>Like <CODE>gt</CODE> and <CODE>gtu</CODE> but test for "less than or equal".
|
|
<P>
|
|
|
|
<A NAME="IDX771"></A>
|
|
<DT><CODE>(if_then_else <VAR>cond</VAR> <VAR>then</VAR> <VAR>else</VAR>)</CODE>
|
|
<DD>This is not a comparison operation but is listed here because it is
|
|
always used in conjunction with a comparison operation. To be
|
|
precise, <VAR>cond</VAR> is a comparison expression. This expression
|
|
represents a choice, according to <VAR>cond</VAR>, between the value
|
|
represented by <VAR>then</VAR> and the one represented by <VAR>else</VAR>.
|
|
<P>
|
|
|
|
On most machines, <CODE>if_then_else</CODE> expressions are valid only
|
|
to express conditional jumps.
|
|
</P><P>
|
|
|
|
<A NAME="IDX772"></A>
|
|
<DT><CODE>(cond [<VAR>test1</VAR> <VAR>value1</VAR> <VAR>test2</VAR> <VAR>value2</VAR> <small>...</small>] <VAR>default</VAR>)</CODE>
|
|
<DD>Similar to <CODE>if_then_else</CODE>, but more general. Each of <VAR>test1</VAR>,
|
|
<VAR>test2</VAR>, <small>...</small> is performed in turn. The result of this expression is
|
|
the <VAR>value</VAR> corresponding to the first non-zero test, or <VAR>default</VAR> if
|
|
none of the tests are non-zero expressions.
|
|
<P>
|
|
|
|
This is currently not valid for instruction patterns and is supported only
|
|
for insn attributes. See section <A HREF="gcc_16.html#SEC190" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC190">16.15 Instruction Attributes</A>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Bit Fields"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC159"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC158" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC158"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC160" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC160"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.10 Bit Fields </H2>
|
|
<!--docid::SEC159::-->
|
|
<P>
|
|
|
|
Special expression codes exist to represent bitfield instructions.
|
|
These types of expressions are lvalues in RTL; they may appear
|
|
on the left side of an assignment, indicating insertion of a value
|
|
into the specified bit field.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX773"></A>
|
|
<A NAME="IDX774"></A>
|
|
<DT><CODE>(sign_extract:<VAR>m</VAR> <VAR>loc</VAR> <VAR>size</VAR> <VAR>pos</VAR>)</CODE>
|
|
<DD>This represents a reference to a sign-extended bit field contained or
|
|
starting in <VAR>loc</VAR> (a memory or register reference). The bit field
|
|
is <VAR>size</VAR> bits wide and starts at bit <VAR>pos</VAR>. The compilation
|
|
option <CODE>BITS_BIG_ENDIAN</CODE> says which end of the memory unit
|
|
<VAR>pos</VAR> counts from.
|
|
<P>
|
|
|
|
If <VAR>loc</VAR> is in memory, its mode must be a single-byte integer mode.
|
|
If <VAR>loc</VAR> is in a register, the mode to use is specified by the
|
|
operand of the <CODE>insv</CODE> or <CODE>extv</CODE> pattern
|
|
(see section <A HREF="gcc_16.html#SEC182" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC182">16.7 Standard Pattern Names For Generation</A>) and is usually a full-word integer mode,
|
|
which is the default if none is specified.
|
|
</P><P>
|
|
|
|
The mode of <VAR>pos</VAR> is machine-specific and is also specified
|
|
in the <CODE>insv</CODE> or <CODE>extv</CODE> pattern.
|
|
</P><P>
|
|
|
|
The mode <VAR>m</VAR> is the same as the mode that would be used for
|
|
<VAR>loc</VAR> if it were a register.
|
|
</P><P>
|
|
|
|
<A NAME="IDX775"></A>
|
|
<DT><CODE>(zero_extract:<VAR>m</VAR> <VAR>loc</VAR> <VAR>size</VAR> <VAR>pos</VAR>)</CODE>
|
|
<DD>Like <CODE>sign_extract</CODE> but refers to an unsigned or zero-extended
|
|
bit field. The same sequence of bits are extracted, but they
|
|
are filled to an entire word with zeros instead of by sign-extension.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Conversions"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC160"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC159" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC159"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC161" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC161"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.11 Conversions </H2>
|
|
<!--docid::SEC160::-->
|
|
<P>
|
|
|
|
All conversions between machine modes must be represented by
|
|
explicit conversion operations. For example, an expression
|
|
which is the sum of a byte and a full word cannot be written as
|
|
<CODE>(plus:SI (reg:QI 34) (reg:SI 80))</CODE> because the <CODE>plus</CODE>
|
|
operation requires two operands of the same machine mode.
|
|
Therefore, the byte-sized operand is enclosed in a conversion
|
|
operation, as in
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The conversion operation is not a mere placeholder, because there
|
|
may be more than one way of converting from a given starting mode
|
|
to the desired final mode. The conversion operation code says how
|
|
to do it.
|
|
</P><P>
|
|
|
|
For all conversion operations, <VAR>x</VAR> must not be <CODE>VOIDmode</CODE>
|
|
because the mode in which to do the conversion would not be known.
|
|
The conversion must either be done at compile-time or <VAR>x</VAR>
|
|
must be placed into a register.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX776"></A>
|
|
<DT><CODE>(sign_extend:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of sign-extending the value <VAR>x</VAR>
|
|
to machine mode <VAR>m</VAR>. <VAR>m</VAR> must be a fixed-point mode
|
|
and <VAR>x</VAR> a fixed-point value of a mode narrower than <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX777"></A>
|
|
<DT><CODE>(zero_extend:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of zero-extending the value <VAR>x</VAR>
|
|
to machine mode <VAR>m</VAR>. <VAR>m</VAR> must be a fixed-point mode
|
|
and <VAR>x</VAR> a fixed-point value of a mode narrower than <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX778"></A>
|
|
<DT><CODE>(float_extend:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of extending the value <VAR>x</VAR>
|
|
to machine mode <VAR>m</VAR>. <VAR>m</VAR> must be a floating point mode
|
|
and <VAR>x</VAR> a floating point value of a mode narrower than <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX779"></A>
|
|
<DT><CODE>(truncate:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of truncating the value <VAR>x</VAR>
|
|
to machine mode <VAR>m</VAR>. <VAR>m</VAR> must be a fixed-point mode
|
|
and <VAR>x</VAR> a fixed-point value of a mode wider than <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX780"></A>
|
|
<DT><CODE>(float_truncate:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of truncating the value <VAR>x</VAR>
|
|
to machine mode <VAR>m</VAR>. <VAR>m</VAR> must be a floating point mode
|
|
and <VAR>x</VAR> a floating point value of a mode wider than <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX781"></A>
|
|
<DT><CODE>(float:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of converting fixed point value <VAR>x</VAR>,
|
|
regarded as signed, to floating point mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX782"></A>
|
|
<DT><CODE>(unsigned_float:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of converting fixed point value <VAR>x</VAR>,
|
|
regarded as unsigned, to floating point mode <VAR>m</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX783"></A>
|
|
<DT><CODE>(fix:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>When <VAR>m</VAR> is a fixed point mode, represents the result of
|
|
converting floating point value <VAR>x</VAR> to mode <VAR>m</VAR>, regarded as
|
|
signed. How rounding is done is not specified, so this operation may
|
|
be used validly in compiling C code only for integer-valued operands.
|
|
<P>
|
|
|
|
<A NAME="IDX784"></A>
|
|
<DT><CODE>(unsigned_fix:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the result of converting floating point value <VAR>x</VAR> to
|
|
fixed point mode <VAR>m</VAR>, regarded as unsigned. How rounding is done
|
|
is not specified.
|
|
<P>
|
|
|
|
<A NAME="IDX785"></A>
|
|
<DT><CODE>(fix:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>When <VAR>m</VAR> is a floating point mode, represents the result of
|
|
converting floating point value <VAR>x</VAR> (valid for mode <VAR>m</VAR>) to an
|
|
integer, still represented in floating point mode <VAR>m</VAR>, by rounding
|
|
towards zero.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="RTL Declarations"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC161"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC160" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC160"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC162" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC162"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.12 Declarations </H2>
|
|
<!--docid::SEC161::-->
|
|
<P>
|
|
|
|
Declaration expression codes do not represent arithmetic operations
|
|
but rather state assertions about their operands.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX786"></A>
|
|
<A NAME="IDX787"></A>
|
|
<DT><CODE>(strict_low_part (subreg:<VAR>m</VAR> (reg:<VAR>n</VAR> <VAR>r</VAR>) 0))</CODE>
|
|
<DD>This expression code is used in only one context: as the destination operand of a
|
|
<CODE>set</CODE> expression. In addition, the operand of this expression
|
|
must be a non-paradoxical <CODE>subreg</CODE> expression.
|
|
<P>
|
|
|
|
The presence of <CODE>strict_low_part</CODE> says that the part of the
|
|
register which is meaningful in mode <VAR>n</VAR>, but is not part of
|
|
mode <VAR>m</VAR>, is not to be altered. Normally, an assignment to such
|
|
a subreg is allowed to have undefined effects on the rest of the
|
|
register when <VAR>m</VAR> is less than a word.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Side Effects"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC162"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC161" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC161"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC163" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC163"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.13 Side Effect Expressions </H2>
|
|
<!--docid::SEC162::-->
|
|
<P>
|
|
|
|
The expression codes described so far represent values, not actions.
|
|
But machine instructions never produce values; they are meaningful
|
|
only for their side effects on the state of the machine. Special
|
|
expression codes are used to represent side effects.
|
|
</P><P>
|
|
|
|
The body of an instruction is always one of these side effect codes;
|
|
the codes described above, which represent values, appear only as
|
|
the operands of these.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX788"></A>
|
|
<DT><CODE>(set <VAR>lval</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the action of storing the value of <VAR>x</VAR> into the place
|
|
represented by <VAR>lval</VAR>. <VAR>lval</VAR> must be an expression
|
|
representing a place that can be stored in: <CODE>reg</CODE> (or
|
|
<CODE>subreg</CODE> or <CODE>strict_low_part</CODE>), <CODE>mem</CODE>, <CODE>pc</CODE> or
|
|
<CODE>cc0</CODE>.<P>
|
|
|
|
If <VAR>lval</VAR> is a <CODE>reg</CODE>, <CODE>subreg</CODE> or <CODE>mem</CODE>, it has a
|
|
machine mode; then <VAR>x</VAR> must be valid for that mode.</P><P>
|
|
|
|
If <VAR>lval</VAR> is a <CODE>reg</CODE> whose machine mode is less than the full
|
|
width of the register, then it means that the part of the register
|
|
specified by the machine mode is given the specified value and the
|
|
rest of the register receives an undefined value. Likewise, if
|
|
<VAR>lval</VAR> is a <CODE>subreg</CODE> whose machine mode is narrower than
|
|
the mode of the register, the rest of the register can be changed in
|
|
an undefined way.
|
|
</P><P>
|
|
|
|
If <VAR>lval</VAR> is a <CODE>strict_low_part</CODE> of a <CODE>subreg</CODE>, then the
|
|
part of the register specified by the machine mode of the
|
|
<CODE>subreg</CODE> is given the value <VAR>x</VAR> and the rest of the register
|
|
is not changed.</P><P>
|
|
|
|
If <VAR>lval</VAR> is <CODE>(cc0)</CODE>, it has no machine mode, and <VAR>x</VAR> may
|
|
be either a <CODE>compare</CODE> expression or a value that may have any mode.
|
|
The latter case represents a "test" instruction. The expression
|
|
<CODE>(set (cc0) (reg:<VAR>m</VAR> <VAR>n</VAR>))</CODE> is equivalent to
|
|
<CODE>(set (cc0) (compare (reg:<VAR>m</VAR> <VAR>n</VAR>) (const_int 0)))</CODE>.
|
|
Use the former expression to save space during the compilation.
|
|
</P><P>
|
|
|
|
<A NAME="IDX789"></A>
|
|
<A NAME="IDX790"></A>
|
|
If <VAR>lval</VAR> is <CODE>(pc)</CODE>, we have a jump instruction, and the
|
|
possibilities for <VAR>x</VAR> are very limited. It may be a
|
|
<CODE>label_ref</CODE> expression (unconditional jump). It may be an
|
|
<CODE>if_then_else</CODE> (conditional jump), in which case either the
|
|
second or the third operand must be <CODE>(pc)</CODE> (for the case which
|
|
does not jump) and the other of the two must be a <CODE>label_ref</CODE>
|
|
(for the case which does jump). <VAR>x</VAR> may also be a <CODE>mem</CODE> or
|
|
<CODE>(plus:SI (pc) <VAR>y</VAR>)</CODE>, where <VAR>y</VAR> may be a <CODE>reg</CODE> or a
|
|
<CODE>mem</CODE>; these unusual patterns are used to represent jumps through
|
|
branch tables.</P><P>
|
|
|
|
If <VAR>lval</VAR> is neither <CODE>(cc0)</CODE> nor <CODE>(pc)</CODE>, the mode of
|
|
<VAR>lval</VAR> must not be <CODE>VOIDmode</CODE> and the mode of <VAR>x</VAR> must be
|
|
valid for the mode of <VAR>lval</VAR>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX791"></A>
|
|
<A NAME="IDX792"></A>
|
|
<VAR>lval</VAR> is customarily accessed with the <CODE>SET_DEST</CODE> macro and
|
|
<VAR>x</VAR> with the <CODE>SET_SRC</CODE> macro.
|
|
</P><P>
|
|
|
|
<A NAME="IDX793"></A>
|
|
<DT><CODE>(return)</CODE>
|
|
<DD>As the sole expression in a pattern, represents a return from the
|
|
current function, on machines where this can be done with one
|
|
instruction, such as Vaxes. On machines where a multi-instruction
|
|
"epilogue" must be executed in order to return from the function,
|
|
returning is done by jumping to a label which precedes the epilogue, and
|
|
the <CODE>return</CODE> expression code is never used.
|
|
<P>
|
|
|
|
Inside an <CODE>if_then_else</CODE> expression, represents the value to be
|
|
placed in <CODE>pc</CODE> to return to the caller.
|
|
</P><P>
|
|
|
|
Note that an insn pattern of <CODE>(return)</CODE> is logically equivalent to
|
|
<CODE>(set (pc) (return))</CODE>, but the latter form is never used.
|
|
</P><P>
|
|
|
|
<A NAME="IDX794"></A>
|
|
<DT><CODE>(call <VAR>function</VAR> <VAR>nargs</VAR>)</CODE>
|
|
<DD>Represents a function call. <VAR>function</VAR> is a <CODE>mem</CODE> expression
|
|
whose address is the address of the function to be called.
|
|
<VAR>nargs</VAR> is an expression which can be used for two purposes: on
|
|
some machines it represents the number of bytes of stack argument; on
|
|
others, it represents the number of argument registers.
|
|
<P>
|
|
|
|
Each machine has a standard machine mode which <VAR>function</VAR> must
|
|
have. The machine description defines macro <CODE>FUNCTION_MODE</CODE> to
|
|
expand into the requisite mode name. The purpose of this mode is to
|
|
specify what kind of addressing is allowed, on machines where the
|
|
allowed kinds of addressing depend on the machine mode being
|
|
addressed.
|
|
</P><P>
|
|
|
|
<A NAME="IDX795"></A>
|
|
<DT><CODE>(clobber <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the storing or possible storing of an unpredictable,
|
|
undescribed value into <VAR>x</VAR>, which must be a <CODE>reg</CODE>,
|
|
<CODE>scratch</CODE> or <CODE>mem</CODE> expression.
|
|
<P>
|
|
|
|
One place this is used is in string instructions that store standard
|
|
values into particular hard registers. It may not be worth the
|
|
trouble to describe the values that are stored, but it is essential to
|
|
inform the compiler that the registers will be altered, lest it
|
|
attempt to keep data in them across the string instruction.
|
|
</P><P>
|
|
|
|
If <VAR>x</VAR> is <CODE>(mem:BLK (const_int 0))</CODE>, it means that all memory
|
|
locations must be presumed clobbered.
|
|
</P><P>
|
|
|
|
Note that the machine description classifies certain hard registers as
|
|
"call-clobbered". All function call instructions are assumed by
|
|
default to clobber these registers, so there is no need to use
|
|
<CODE>clobber</CODE> expressions to indicate this fact. Also, each function
|
|
call is assumed to have the potential to alter any memory location,
|
|
unless the function is declared <CODE>const</CODE>.
|
|
</P><P>
|
|
|
|
If the last group of expressions in a <CODE>parallel</CODE> are each a
|
|
<CODE>clobber</CODE> expression whose arguments are <CODE>reg</CODE> or
|
|
<CODE>match_scratch</CODE> (see section <A HREF="gcc_16.html#SEC172" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC172">16.3 RTL Template</A>) expressions, the combiner
|
|
phase can add the appropriate <CODE>clobber</CODE> expressions to an insn it
|
|
has constructed when doing so will cause a pattern to be matched.
|
|
</P><P>
|
|
|
|
This feature can be used, for example, on a machine that whose multiply
|
|
and add instructions don't use an MQ register but which has an
|
|
add-accumulate instruction that does clobber the MQ register. Similarly,
|
|
a combined instruction might require a temporary register while the
|
|
constituent instructions might not.
|
|
</P><P>
|
|
|
|
When a <CODE>clobber</CODE> expression for a register appears inside a
|
|
<CODE>parallel</CODE> with other side effects, the register allocator
|
|
guarantees that the register is unoccupied both before and after that
|
|
insn. However, the reload phase may allocate a register used for one of
|
|
the inputs unless the <SAMP>`&'</SAMP> constraint is specified for the selected
|
|
alternative (see section <A HREF="gcc_16.html#SEC179" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC179">16.6.4 Constraint Modifier Characters</A>). You can clobber either a specific hard
|
|
register, a pseudo register, or a <CODE>scratch</CODE> expression; in the
|
|
latter two cases, GNU CC will allocate a hard register that is available
|
|
there for use as a temporary.
|
|
</P><P>
|
|
|
|
For instructions that require a temporary register, you should use
|
|
<CODE>scratch</CODE> instead of a pseudo-register because this will allow the
|
|
combiner phase to add the <CODE>clobber</CODE> when required. You do this by
|
|
coding (<CODE>clobber</CODE> (<CODE>match_scratch</CODE> <small>...</small>)). If you do
|
|
clobber a pseudo register, use one which appears nowhere else--generate
|
|
a new one each time. Otherwise, you may confuse CSE.
|
|
</P><P>
|
|
|
|
There is one other known use for clobbering a pseudo register in a
|
|
<CODE>parallel</CODE>: when one of the input operands of the insn is also
|
|
clobbered by the insn. In this case, using the same pseudo register in
|
|
the clobber and elsewhere in the insn produces the expected results.
|
|
</P><P>
|
|
|
|
<A NAME="IDX796"></A>
|
|
<DT><CODE>(use <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the use of the value of <VAR>x</VAR>. It indicates that the
|
|
value in <VAR>x</VAR> at this point in the program is needed, even though
|
|
it may not be apparent why this is so. Therefore, the compiler will
|
|
not attempt to delete previous instructions whose only effect is to
|
|
store a value in <VAR>x</VAR>. <VAR>x</VAR> must be a <CODE>reg</CODE> expression.
|
|
<P>
|
|
|
|
During the reload phase, an insn that has a <CODE>use</CODE> as pattern
|
|
can carry a reg_equal note. These <CODE>use</CODE> insns will be deleted
|
|
before the reload phase exits.
|
|
</P><P>
|
|
|
|
During the delayed branch scheduling phase, <VAR>x</VAR> may be an insn.
|
|
This indicates that <VAR>x</VAR> previously was located at this place in the
|
|
code and its data dependencies need to be taken into account. These
|
|
<CODE>use</CODE> insns will be deleted before the delayed branch scheduling
|
|
phase exits.
|
|
</P><P>
|
|
|
|
<A NAME="IDX797"></A>
|
|
<DT><CODE>(parallel [<VAR>x0</VAR> <VAR>x1</VAR> <small>...</small>])</CODE>
|
|
<DD>Represents several side effects performed in parallel. The square
|
|
brackets stand for a vector; the operand of <CODE>parallel</CODE> is a
|
|
vector of expressions. <VAR>x0</VAR>, <VAR>x1</VAR> and so on are individual
|
|
side effect expressions--expressions of code <CODE>set</CODE>, <CODE>call</CODE>,
|
|
<CODE>return</CODE>, <CODE>clobber</CODE> or <CODE>use</CODE>.<P>
|
|
|
|
"In parallel" means that first all the values used in the individual
|
|
side-effects are computed, and second all the actual side-effects are
|
|
performed. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
|
|
(set (mem:SI (reg:SI 1)) (reg:SI 1))])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
says unambiguously that the values of hard register 1 and the memory
|
|
location addressed by it are interchanged. In both places where
|
|
<CODE>(reg:SI 1)</CODE> appears as a memory address it refers to the value
|
|
in register 1 <EM>before</EM> the execution of the insn.
|
|
</P><P>
|
|
|
|
It follows that it is <EM>incorrect</EM> to use <CODE>parallel</CODE> and
|
|
expect the result of one <CODE>set</CODE> to be available for the next one.
|
|
For example, people sometimes attempt to represent a jump-if-zero
|
|
instruction this way:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(parallel [(set (cc0) (reg:SI 34))
|
|
(set (pc) (if_then_else
|
|
(eq (cc0) (const_int 0))
|
|
(label_ref <small>...</small>)
|
|
(pc)))])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
But this is incorrect, because it says that the jump condition depends
|
|
on the condition code value <EM>before</EM> this instruction, not on the
|
|
new value that is set by this instruction.
|
|
</P><P>
|
|
|
|
<A NAME="IDX798"></A>
|
|
Peephole optimization, which takes place together with final assembly
|
|
code output, can produce insns whose patterns consist of a <CODE>parallel</CODE>
|
|
whose elements are the operands needed to output the resulting
|
|
assembler code--often <CODE>reg</CODE>, <CODE>mem</CODE> or constant expressions.
|
|
This would not be well-formed RTL at any other stage in compilation,
|
|
but it is ok then because no further optimization remains to be done.
|
|
However, the definition of the macro <CODE>NOTICE_UPDATE_CC</CODE>, if
|
|
any, must deal with such insns if you define any peephole optimizations.
|
|
</P><P>
|
|
|
|
<A NAME="IDX799"></A>
|
|
<DT><CODE>(sequence [<VAR>insns</VAR> <small>...</small>])</CODE>
|
|
<DD>Represents a sequence of insns. Each of the <VAR>insns</VAR> that appears
|
|
in the vector is suitable for appearing in the chain of insns, so it
|
|
must be an <CODE>insn</CODE>, <CODE>jump_insn</CODE>, <CODE>call_insn</CODE>,
|
|
<CODE>code_label</CODE>, <CODE>barrier</CODE> or <CODE>note</CODE>.
|
|
<P>
|
|
|
|
A <CODE>sequence</CODE> RTX is never placed in an actual insn during RTL
|
|
generation. It represents the sequence of insns that result from a
|
|
<CODE>define_expand</CODE> <EM>before</EM> those insns are passed to
|
|
<CODE>emit_insn</CODE> to insert them in the chain of insns. When actually
|
|
inserted, the individual sub-insns are separated out and the
|
|
<CODE>sequence</CODE> is forgotten.
|
|
</P><P>
|
|
|
|
After delay-slot scheduling is completed, an insn and all the insns that
|
|
reside in its delay slots are grouped together into a <CODE>sequence</CODE>.
|
|
The insn requiring the delay slot is the first insn in the vector;
|
|
subsequent insns are to be placed in the delay slot.
|
|
</P><P>
|
|
|
|
<CODE>INSN_ANNULLED_BRANCH_P</CODE> is set on an insn in a delay slot to
|
|
indicate that a branch insn should be used that will conditionally annul
|
|
the effect of the insns in the delay slots. In such a case,
|
|
<CODE>INSN_FROM_TARGET_P</CODE> indicates that the insn is from the target of
|
|
the branch and should be executed only if the branch is taken; otherwise
|
|
the insn should be executed only if the branch is not taken.
|
|
See section <A HREF="gcc_16.html#SEC197" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC197">16.15.7 Delay Slot Scheduling</A>.
|
|
</DL>
|
|
<P>
|
|
|
|
These expression codes appear in place of a side effect, as the body of
|
|
an insn, though strictly speaking they do not always describe side
|
|
effects as such:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX800"></A>
|
|
<DT><CODE>(asm_input <VAR>s</VAR>)</CODE>
|
|
<DD>Represents literal assembler code as described by the string <VAR>s</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX801"></A>
|
|
<A NAME="IDX802"></A>
|
|
<DT><CODE>(unspec [<VAR>operands</VAR> <small>...</small>] <VAR>index</VAR>)</CODE>
|
|
<DD><DT><CODE>(unspec_volatile [<VAR>operands</VAR> <small>...</small>] <VAR>index</VAR>)</CODE>
|
|
<DD>Represents a machine-specific operation on <VAR>operands</VAR>. <VAR>index</VAR>
|
|
selects between multiple machine-specific operations.
|
|
<CODE>unspec_volatile</CODE> is used for volatile operations and operations
|
|
that may trap; <CODE>unspec</CODE> is used for other operations.
|
|
<P>
|
|
|
|
These codes may appear inside a <CODE>pattern</CODE> of an
|
|
insn, inside a <CODE>parallel</CODE>, or inside an expression.
|
|
</P><P>
|
|
|
|
<A NAME="IDX803"></A>
|
|
<DT><CODE>(addr_vec:<VAR>m</VAR> [<VAR>lr0</VAR> <VAR>lr1</VAR> <small>...</small>])</CODE>
|
|
<DD>Represents a table of jump addresses. The vector elements <VAR>lr0</VAR>,
|
|
etc., are <CODE>label_ref</CODE> expressions. The mode <VAR>m</VAR> specifies
|
|
how much space is given to each address; normally <VAR>m</VAR> would be
|
|
<CODE>Pmode</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX804"></A>
|
|
<DT><CODE>(addr_diff_vec:<VAR>m</VAR> <VAR>base</VAR> [<VAR>lr0</VAR> <VAR>lr1</VAR> <small>...</small>] <VAR>min</VAR> <VAR>max</VAR> <VAR>flags</VAR>)</CODE>
|
|
<DD>Represents a table of jump addresses expressed as offsets from
|
|
<VAR>base</VAR>. The vector elements <VAR>lr0</VAR>, etc., are <CODE>label_ref</CODE>
|
|
expressions and so is <VAR>base</VAR>. The mode <VAR>m</VAR> specifies how much
|
|
space is given to each address-difference. <VAR>min</VAR> and <VAR>max</VAR>
|
|
are set up by branch shortening and hold a label with a minimum and a
|
|
maximum address, respectively. <VAR>flags</VAR> indicates the relative
|
|
position of <VAR>base</VAR>, <VAR>min</VAR> and <VAR>max</VAR> to the cointaining insn
|
|
and of <VAR>min</VAR> and <VAR>max</VAR> to <VAR>base</VAR>. See rtl.def for details.</DL>
|
|
<P>
|
|
|
|
<A NAME="Incdec"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC163"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC162" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC162"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC164" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC164"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.14 Embedded Side-Effects on Addresses </H2>
|
|
<!--docid::SEC163::-->
|
|
<P>
|
|
|
|
Six special side-effect expression codes appear as memory addresses.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX805"></A>
|
|
<DT><CODE>(pre_dec:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the side effect of decrementing <VAR>x</VAR> by a standard
|
|
amount and represents also the value that <VAR>x</VAR> has after being
|
|
decremented. <VAR>x</VAR> must be a <CODE>reg</CODE> or <CODE>mem</CODE>, but most
|
|
machines allow only a <CODE>reg</CODE>. <VAR>m</VAR> must be the machine mode
|
|
for pointers on the machine in use. The amount <VAR>x</VAR> is decremented
|
|
by is the length in bytes of the machine mode of the containing memory
|
|
reference of which this expression serves as the address. Here is an
|
|
example of its use:<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(mem:DF (pre_dec:SI (reg:SI 39)))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This says to decrement pseudo register 39 by the length of a <CODE>DFmode</CODE>
|
|
value and use the result to address a <CODE>DFmode</CODE> value.
|
|
</P><P>
|
|
|
|
<A NAME="IDX806"></A>
|
|
<DT><CODE>(pre_inc:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Similar, but specifies incrementing <VAR>x</VAR> instead of decrementing it.
|
|
<P>
|
|
|
|
<A NAME="IDX807"></A>
|
|
<DT><CODE>(post_dec:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Represents the same side effect as <CODE>pre_dec</CODE> but a different
|
|
value. The value represented here is the value <VAR>x</VAR> has <I>before</I>
|
|
being decremented.
|
|
<P>
|
|
|
|
<A NAME="IDX808"></A>
|
|
<DT><CODE>(post_inc:<VAR>m</VAR> <VAR>x</VAR>)</CODE>
|
|
<DD>Similar, but specifies incrementing <VAR>x</VAR> instead of decrementing it.
|
|
<P>
|
|
|
|
<A NAME="IDX809"></A>
|
|
<DT><CODE>(post_modify:<VAR>m</VAR> <VAR>x</VAR> <VAR>y</VAR>)</CODE>
|
|
<DD><P>
|
|
|
|
Represents the side effect of setting <VAR>x</VAR> to <VAR>y</VAR> and
|
|
represents <VAR>x</VAR> before <VAR>x</VAR> is modified. <VAR>x</VAR> must be a
|
|
<CODE>reg</CODE> or <CODE>mem</CODE>, but most machines allow only a <CODE>reg</CODE>.
|
|
<VAR>m</VAR> must be the machine mode for pointers on the machine in use.
|
|
The amount <VAR>x</VAR> is decremented by is the length in bytes of the
|
|
machine mode of the containing memory reference of which this expression
|
|
serves as the address. Note that this is not currently implemented.
|
|
</P><P>
|
|
|
|
The expression <VAR>y</VAR> must be one of three forms:
|
|
<DL COMPACT>
|
|
<CODE>(plus:<VAR>m</VAR> <VAR>x</VAR> <VAR>z</VAR>)</CODE>,
|
|
<CODE>(minus:<VAR>m</VAR> <VAR>x</VAR> <VAR>z</VAR>)</CODE>, or
|
|
<CODE>(plus:<VAR>m</VAR> <VAR>x</VAR> <VAR>i</VAR>)</CODE>,
|
|
</DL>
|
|
where <VAR>z</VAR> is an index register and <VAR>i</VAR> is a constant.
|
|
<P>
|
|
|
|
Here is an example of its use:</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) (reg:SI 48))))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This says to modify pseudo register 42 by adding the contents of pseudo
|
|
register 48 to it, after the use of what ever 42 points to.
|
|
</P><P>
|
|
|
|
<A NAME="IDX810"></A>
|
|
<DT><CODE>(pre_modify:<VAR>m</VAR> <VAR>x</VAR> <VAR>expr</VAR>)</CODE>
|
|
<DD>Similar except side effects happen before the use.
|
|
</DL>
|
|
<P>
|
|
|
|
These embedded side effect expressions must be used with care. Instruction
|
|
patterns may not use them. Until the <SAMP>`flow'</SAMP> pass of the compiler,
|
|
they may occur only to represent pushes onto the stack. The <SAMP>`flow'</SAMP>
|
|
pass finds cases where registers are incremented or decremented in one
|
|
instruction and used as an address shortly before or after; these cases are
|
|
then transformed to use pre- or post-increment or -decrement.
|
|
</P><P>
|
|
|
|
If a register used as the operand of these expressions is used in
|
|
another address in an insn, the original value of the register is used.
|
|
Uses of the register outside of an address are not permitted within the
|
|
same insn as a use in an embedded side effect expression because such
|
|
insns behave differently on different machines and hence must be treated
|
|
as ambiguous and disallowed.
|
|
</P><P>
|
|
|
|
An instruction that can be represented with an embedded side effect
|
|
could also be represented using <CODE>parallel</CODE> containing an additional
|
|
<CODE>set</CODE> to describe how the address register is altered. This is not
|
|
done because machines that allow these operations at all typically
|
|
allow them wherever a memory address is called for. Describing them as
|
|
additional parallel stores would require doubling the number of entries
|
|
in the machine description.
|
|
</P><P>
|
|
|
|
<A NAME="Assembler"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC164"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC163" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC163"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC165" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC165"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.15 Assembler Instructions as Expressions </H2>
|
|
<!--docid::SEC164::-->
|
|
<P>
|
|
|
|
<A NAME="IDX811"></A>
|
|
The RTX code <CODE>asm_operands</CODE> represents a value produced by a
|
|
user-specified assembler instruction. It is used to represent
|
|
an <CODE>asm</CODE> statement with arguments. An <CODE>asm</CODE> statement with
|
|
a single output operand, like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
is represented using a single <CODE>asm_operands</CODE> RTX which represents
|
|
the value that is stored in <CODE>outputvar</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>(set <VAR>rtx-for-outputvar</VAR>
|
|
(asm_operands "foo %1,%2,%0" "a" 0
|
|
[<VAR>rtx-for-addition-result</VAR> <VAR>rtx-for-*z</VAR>]
|
|
[(asm_input:<VAR>m1</VAR> "g")
|
|
(asm_input:<VAR>m2</VAR> "di")]))
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
Here the operands of the <CODE>asm_operands</CODE> RTX are the assembler
|
|
template string, the output-operand's constraint, the index-number of the
|
|
output operand among the output operands specified, a vector of input
|
|
operand RTX's, and a vector of input-operand modes and constraints. The
|
|
mode <VAR>m1</VAR> is the mode of the sum <CODE>x+y</CODE>; <VAR>m2</VAR> is that of
|
|
<CODE>*z</CODE>.
|
|
</P><P>
|
|
|
|
When an <CODE>asm</CODE> statement has multiple output values, its insn has
|
|
several such <CODE>set</CODE> RTX's inside of a <CODE>parallel</CODE>. Each <CODE>set</CODE>
|
|
contains a <CODE>asm_operands</CODE>; all of these share the same assembler
|
|
template and vectors, but each contains the constraint for the respective
|
|
output operand. They are also distinguished by the output-operand index
|
|
number, which is 0, 1, <small>...</small> for successive output operands.
|
|
</P><P>
|
|
|
|
<A NAME="Insns"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC165"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC164" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC164"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC166" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC166"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.16 Insns </H2>
|
|
<!--docid::SEC165::-->
|
|
<P>
|
|
|
|
The RTL representation of the code for a function is a doubly-linked
|
|
chain of objects called <EM>insns</EM>. Insns are expressions with
|
|
special codes that are used for no other purpose. Some insns are
|
|
actual instructions; others represent dispatch tables for <CODE>switch</CODE>
|
|
statements; others represent labels to jump to or various sorts of
|
|
declarative information.
|
|
</P><P>
|
|
|
|
In addition to its own specific data, each insn must have a unique
|
|
id-number that distinguishes it from all other insns in the current
|
|
function (after delayed branch scheduling, copies of an insn with the
|
|
same id-number may be present in multiple places in a function, but
|
|
these copies will always be identical and will only appear inside a
|
|
<CODE>sequence</CODE>), and chain pointers to the preceding and following
|
|
insns. These three fields occupy the same position in every insn,
|
|
independent of the expression code of the insn. They could be accessed
|
|
with <CODE>XEXP</CODE> and <CODE>XINT</CODE>, but instead three special macros are
|
|
always used:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX812"></A>
|
|
<DT><CODE>INSN_UID (<VAR>i</VAR>)</CODE>
|
|
<DD>Accesses the unique id of insn <VAR>i</VAR>.
|
|
<P>
|
|
|
|
<A NAME="IDX813"></A>
|
|
<DT><CODE>PREV_INSN (<VAR>i</VAR>)</CODE>
|
|
<DD>Accesses the chain pointer to the insn preceding <VAR>i</VAR>.
|
|
If <VAR>i</VAR> is the first insn, this is a null pointer.
|
|
<P>
|
|
|
|
<A NAME="IDX814"></A>
|
|
<DT><CODE>NEXT_INSN (<VAR>i</VAR>)</CODE>
|
|
<DD>Accesses the chain pointer to the insn following <VAR>i</VAR>.
|
|
If <VAR>i</VAR> is the last insn, this is a null pointer.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX815"></A>
|
|
<A NAME="IDX816"></A>
|
|
The first insn in the chain is obtained by calling <CODE>get_insns</CODE>; the
|
|
last insn is the result of calling <CODE>get_last_insn</CODE>. Within the
|
|
chain delimited by these insns, the <CODE>NEXT_INSN</CODE> and
|
|
<CODE>PREV_INSN</CODE> pointers must always correspond: if <VAR>insn</VAR> is not
|
|
the first insn,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>NEXT_INSN (PREV_INSN (<VAR>insn</VAR>)) == <VAR>insn</VAR>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is always true and if <VAR>insn</VAR> is not the last insn,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>PREV_INSN (NEXT_INSN (<VAR>insn</VAR>)) == <VAR>insn</VAR>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is always true.
|
|
</P><P>
|
|
|
|
After delay slot scheduling, some of the insns in the chain might be
|
|
<CODE>sequence</CODE> expressions, which contain a vector of insns. The value
|
|
of <CODE>NEXT_INSN</CODE> in all but the last of these insns is the next insn
|
|
in the vector; the value of <CODE>NEXT_INSN</CODE> of the last insn in the vector
|
|
is the same as the value of <CODE>NEXT_INSN</CODE> for the <CODE>sequence</CODE> in
|
|
which it is contained. Similar rules apply for <CODE>PREV_INSN</CODE>.
|
|
</P><P>
|
|
|
|
This means that the above invariants are not necessarily true for insns
|
|
inside <CODE>sequence</CODE> expressions. Specifically, if <VAR>insn</VAR> is the
|
|
first insn in a <CODE>sequence</CODE>, <CODE>NEXT_INSN (PREV_INSN (<VAR>insn</VAR>))</CODE>
|
|
is the insn containing the <CODE>sequence</CODE> expression, as is the value
|
|
of <CODE>PREV_INSN (NEXT_INSN (<VAR>insn</VAR>))</CODE> is <VAR>insn</VAR> is the last
|
|
insn in the <CODE>sequence</CODE> expression. You can use these expressions
|
|
to find the containing <CODE>sequence</CODE> expression.</P><P>
|
|
|
|
Every insn has one of the following six expression codes:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX817"></A>
|
|
<DT><CODE>insn</CODE>
|
|
<DD>The expression code <CODE>insn</CODE> is used for instructions that do not jump
|
|
and do not do function calls. <CODE>sequence</CODE> expressions are always
|
|
contained in insns with code <CODE>insn</CODE> even if one of those insns
|
|
should jump or do function calls.
|
|
<P>
|
|
|
|
Insns with code <CODE>insn</CODE> have four additional fields beyond the three
|
|
mandatory ones listed above. These four are described in a table below.
|
|
</P><P>
|
|
|
|
<A NAME="IDX818"></A>
|
|
<DT><CODE>jump_insn</CODE>
|
|
<DD>The expression code <CODE>jump_insn</CODE> is used for instructions that may
|
|
jump (or, more generally, may contain <CODE>label_ref</CODE> expressions). If
|
|
there is an instruction to return from the current function, it is
|
|
recorded as a <CODE>jump_insn</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX819"></A>
|
|
<CODE>jump_insn</CODE> insns have the same extra fields as <CODE>insn</CODE> insns,
|
|
accessed in the same way and in addition contain a field
|
|
<CODE>JUMP_LABEL</CODE> which is defined once jump optimization has completed.
|
|
</P><P>
|
|
|
|
For simple conditional and unconditional jumps, this field contains the
|
|
<CODE>code_label</CODE> to which this insn will (possibly conditionally)
|
|
branch. In a more complex jump, <CODE>JUMP_LABEL</CODE> records one of the
|
|
labels that the insn refers to; the only way to find the others
|
|
is to scan the entire body of the insn.
|
|
</P><P>
|
|
|
|
Return insns count as jumps, but since they do not refer to any labels,
|
|
they have zero in the <CODE>JUMP_LABEL</CODE> field.
|
|
</P><P>
|
|
|
|
<A NAME="IDX820"></A>
|
|
<DT><CODE>call_insn</CODE>
|
|
<DD>The expression code <CODE>call_insn</CODE> is used for instructions that may do
|
|
function calls. It is important to distinguish these instructions because
|
|
they imply that certain registers and memory locations may be altered
|
|
unpredictably.
|
|
<P>
|
|
|
|
<A NAME="IDX821"></A>
|
|
<CODE>call_insn</CODE> insns have the same extra fields as <CODE>insn</CODE> insns,
|
|
accessed in the same way and in addition contain a field
|
|
<CODE>CALL_INSN_FUNCTION_USAGE</CODE>, which contains a list (chain of
|
|
<CODE>expr_list</CODE> expressions) containing <CODE>use</CODE> and <CODE>clobber</CODE>
|
|
expressions that denote hard registers used or clobbered by the called
|
|
function. A register specified in a <CODE>clobber</CODE> in this list is
|
|
modified <EM>after</EM> the execution of the <CODE>call_insn</CODE>, while a
|
|
register in a <CODE>clobber</CODE> in the body of the <CODE>call_insn</CODE> is
|
|
clobbered before the insn completes execution. <CODE>clobber</CODE>
|
|
expressions in this list augment registers specified in
|
|
<CODE>CALL_USED_REGISTERS</CODE> (see section <A HREF="gcc_17.html#SEC205" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC205">17.5.1 Basic Characteristics of Registers</A>).
|
|
</P><P>
|
|
|
|
<A NAME="IDX822"></A>
|
|
<A NAME="IDX823"></A>
|
|
<DT><CODE>code_label</CODE>
|
|
<DD>A <CODE>code_label</CODE> insn represents a label that a jump insn can jump
|
|
to. It contains two special fields of data in addition to the three
|
|
standard ones. <CODE>CODE_LABEL_NUMBER</CODE> is used to hold the <EM>label
|
|
number</EM>, a number that identifies this label uniquely among all the
|
|
labels in the compilation (not just in the current function).
|
|
Ultimately, the label is represented in the assembler output as an
|
|
assembler label, usually of the form <SAMP>`L<VAR>n</VAR>'</SAMP> where <VAR>n</VAR> is
|
|
the label number.
|
|
<P>
|
|
|
|
When a <CODE>code_label</CODE> appears in an RTL expression, it normally
|
|
appears within a <CODE>label_ref</CODE> which represents the address of
|
|
the label, as a number.
|
|
</P><P>
|
|
|
|
<A NAME="IDX824"></A>
|
|
The field <CODE>LABEL_NUSES</CODE> is only defined once the jump optimization
|
|
phase is completed and contains the number of times this label is
|
|
referenced in the current function.
|
|
</P><P>
|
|
|
|
<A NAME="IDX825"></A>
|
|
<DT><CODE>barrier</CODE>
|
|
<DD>Barriers are placed in the instruction stream when control cannot flow
|
|
past them. They are placed after unconditional jump instructions to
|
|
indicate that the jumps are unconditional and after calls to
|
|
<CODE>volatile</CODE> functions, which do not return (e.g., <CODE>exit</CODE>).
|
|
They contain no information beyond the three standard fields.
|
|
<P>
|
|
|
|
<A NAME="IDX826"></A>
|
|
<A NAME="IDX827"></A>
|
|
<A NAME="IDX828"></A>
|
|
<DT><CODE>note</CODE>
|
|
<DD><CODE>note</CODE> insns are used to represent additional debugging and
|
|
declarative information. They contain two nonstandard fields, an
|
|
integer which is accessed with the macro <CODE>NOTE_LINE_NUMBER</CODE> and a
|
|
string accessed with <CODE>NOTE_SOURCE_FILE</CODE>.
|
|
<P>
|
|
|
|
If <CODE>NOTE_LINE_NUMBER</CODE> is positive, the note represents the
|
|
position of a source line and <CODE>NOTE_SOURCE_FILE</CODE> is the source file name
|
|
that the line came from. These notes control generation of line
|
|
number data in the assembler output.
|
|
</P><P>
|
|
|
|
Otherwise, <CODE>NOTE_LINE_NUMBER</CODE> is not really a line number but a
|
|
code with one of the following values (and <CODE>NOTE_SOURCE_FILE</CODE>
|
|
must contain a null pointer):
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX829"></A>
|
|
<DT><CODE>NOTE_INSN_DELETED</CODE>
|
|
<DD>Such a note is completely ignorable. Some passes of the compiler
|
|
delete insns by altering them into notes of this kind.
|
|
<P>
|
|
|
|
<A NAME="IDX830"></A>
|
|
<A NAME="IDX831"></A>
|
|
<DT><CODE>NOTE_INSN_BLOCK_BEG</CODE>
|
|
<DD><DT><CODE>NOTE_INSN_BLOCK_END</CODE>
|
|
<DD>These types of notes indicate the position of the beginning and end
|
|
of a level of scoping of variable names. They control the output
|
|
of debugging information.
|
|
<P>
|
|
|
|
<A NAME="IDX832"></A>
|
|
<A NAME="IDX833"></A>
|
|
<DT><CODE>NOTE_INSN_EH_REGION_BEG</CODE>
|
|
<DD><DT><CODE>NOTE_INSN_EH_REGION_END</CODE>
|
|
<DD>These types of notes indicate the position of the beginning and end of a
|
|
level of scoping for exception handling. <CODE>NOTE_BLOCK_NUMBER</CODE>
|
|
identifies which <CODE>CODE_LABEL</CODE> is associated with the given region.
|
|
<P>
|
|
|
|
<A NAME="IDX834"></A>
|
|
<A NAME="IDX835"></A>
|
|
<DT><CODE>NOTE_INSN_LOOP_BEG</CODE>
|
|
<DD><DT><CODE>NOTE_INSN_LOOP_END</CODE>
|
|
<DD>These types of notes indicate the position of the beginning and end
|
|
of a <CODE>while</CODE> or <CODE>for</CODE> loop. They enable the loop optimizer
|
|
to find loops quickly.
|
|
<P>
|
|
|
|
<A NAME="IDX836"></A>
|
|
<DT><CODE>NOTE_INSN_LOOP_CONT</CODE>
|
|
<DD>Appears at the place in a loop that <CODE>continue</CODE> statements jump to.
|
|
<P>
|
|
|
|
<A NAME="IDX837"></A>
|
|
<DT><CODE>NOTE_INSN_LOOP_VTOP</CODE>
|
|
<DD>This note indicates the place in a loop where the exit test begins for
|
|
those loops in which the exit test has been duplicated. This position
|
|
becomes another virtual start of the loop when considering loop
|
|
invariants.
|
|
<P>
|
|
|
|
<A NAME="IDX838"></A>
|
|
<DT><CODE>NOTE_INSN_FUNCTION_END</CODE>
|
|
<DD>Appears near the end of the function body, just before the label that
|
|
<CODE>return</CODE> statements jump to (on machine where a single instruction
|
|
does not suffice for returning). This note may be deleted by jump
|
|
optimization.
|
|
<P>
|
|
|
|
<A NAME="IDX839"></A>
|
|
<DT><CODE>NOTE_INSN_SETJMP</CODE>
|
|
<DD>Appears following each call to <CODE>setjmp</CODE> or a related function.
|
|
</DL>
|
|
<P>
|
|
|
|
These codes are printed symbolically when they appear in debugging dumps.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX840"></A>
|
|
<A NAME="IDX841"></A>
|
|
<A NAME="IDX842"></A>
|
|
The machine mode of an insn is normally <CODE>VOIDmode</CODE>, but some
|
|
phases use the mode for various purposes.
|
|
</P><P>
|
|
|
|
The common subexpression elimination pass sets the mode of an insn to
|
|
<CODE>QImode</CODE> when it is the first insn in a block that has already
|
|
been processed.
|
|
</P><P>
|
|
|
|
The second Haifa scheduling pass, for targets that can multiple issue,
|
|
sets the mode of an insn to <CODE>TImode</CODE> when it is believed that the
|
|
instruction begins an issue group. That is, when the instruction
|
|
cannot issue simultaneously with the previous. This may be relied on
|
|
by later passes, in particular machine-dependant reorg.
|
|
</P><P>
|
|
|
|
Here is a table of the extra fields of <CODE>insn</CODE>, <CODE>jump_insn</CODE>
|
|
and <CODE>call_insn</CODE> insns:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX843"></A>
|
|
<DT><CODE>PATTERN (<VAR>i</VAR>)</CODE>
|
|
<DD>An expression for the side effect performed by this insn. This must be
|
|
one of the following codes: <CODE>set</CODE>, <CODE>call</CODE>, <CODE>use</CODE>,
|
|
<CODE>clobber</CODE>, <CODE>return</CODE>, <CODE>asm_input</CODE>, <CODE>asm_output</CODE>,
|
|
<CODE>addr_vec</CODE>, <CODE>addr_diff_vec</CODE>, <CODE>trap_if</CODE>, <CODE>unspec</CODE>,
|
|
<CODE>unspec_volatile</CODE>, <CODE>parallel</CODE>, or <CODE>sequence</CODE>. If it is a <CODE>parallel</CODE>,
|
|
each element of the <CODE>parallel</CODE> must be one these codes, except that
|
|
<CODE>parallel</CODE> expressions cannot be nested and <CODE>addr_vec</CODE> and
|
|
<CODE>addr_diff_vec</CODE> are not permitted inside a <CODE>parallel</CODE> expression.
|
|
<P>
|
|
|
|
<A NAME="IDX844"></A>
|
|
<DT><CODE>INSN_CODE (<VAR>i</VAR>)</CODE>
|
|
<DD>An integer that says which pattern in the machine description matches
|
|
this insn, or -1 if the matching has not yet been attempted.
|
|
<P>
|
|
|
|
Such matching is never attempted and this field remains -1 on an insn
|
|
whose pattern consists of a single <CODE>use</CODE>, <CODE>clobber</CODE>,
|
|
<CODE>asm_input</CODE>, <CODE>addr_vec</CODE> or <CODE>addr_diff_vec</CODE> expression.
|
|
</P><P>
|
|
|
|
<A NAME="IDX845"></A>
|
|
Matching is also never attempted on insns that result from an <CODE>asm</CODE>
|
|
statement. These contain at least one <CODE>asm_operands</CODE> expression.
|
|
The function <CODE>asm_noperands</CODE> returns a non-negative value for
|
|
such insns.
|
|
</P><P>
|
|
|
|
In the debugging output, this field is printed as a number followed by
|
|
a symbolic representation that locates the pattern in the <TT>`md'</TT>
|
|
file as some small positive or negative offset from a named pattern.
|
|
</P><P>
|
|
|
|
<A NAME="IDX846"></A>
|
|
<DT><CODE>LOG_LINKS (<VAR>i</VAR>)</CODE>
|
|
<DD>A list (chain of <CODE>insn_list</CODE> expressions) giving information about
|
|
dependencies between instructions within a basic block. Neither a jump
|
|
nor a label may come between the related insns.
|
|
<P>
|
|
|
|
<A NAME="IDX847"></A>
|
|
<DT><CODE>REG_NOTES (<VAR>i</VAR>)</CODE>
|
|
<DD>A list (chain of <CODE>expr_list</CODE> and <CODE>insn_list</CODE> expressions)
|
|
giving miscellaneous information about the insn. It is often
|
|
information pertaining to the registers used in this insn.
|
|
</DL>
|
|
<P>
|
|
|
|
The <CODE>LOG_LINKS</CODE> field of an insn is a chain of <CODE>insn_list</CODE>
|
|
expressions. Each of these has two operands: the first is an insn,
|
|
and the second is another <CODE>insn_list</CODE> expression (the next one in
|
|
the chain). The last <CODE>insn_list</CODE> in the chain has a null pointer
|
|
as second operand. The significant thing about the chain is which
|
|
insns appear in it (as first operands of <CODE>insn_list</CODE>
|
|
expressions). Their order is not significant.
|
|
</P><P>
|
|
|
|
This list is originally set up by the flow analysis pass; it is a null
|
|
pointer until then. Flow only adds links for those data dependencies
|
|
which can be used for instruction combination. For each insn, the flow
|
|
analysis pass adds a link to insns which store into registers values
|
|
that are used for the first time in this insn. The instruction
|
|
scheduling pass adds extra links so that every dependence will be
|
|
represented. Links represent data dependencies, antidependencies and
|
|
output dependencies; the machine mode of the link distinguishes these
|
|
three types: antidependencies have mode <CODE>REG_DEP_ANTI</CODE>, output
|
|
dependencies have mode <CODE>REG_DEP_OUTPUT</CODE>, and data dependencies have
|
|
mode <CODE>VOIDmode</CODE>.
|
|
</P><P>
|
|
|
|
The <CODE>REG_NOTES</CODE> field of an insn is a chain similar to the
|
|
<CODE>LOG_LINKS</CODE> field but it includes <CODE>expr_list</CODE> expressions in
|
|
addition to <CODE>insn_list</CODE> expressions. There are several kinds of
|
|
register notes, which are distinguished by the machine mode, which in a
|
|
register note is really understood as being an <CODE>enum reg_note</CODE>.
|
|
The first operand <VAR>op</VAR> of the note is data whose meaning depends on
|
|
the kind of note.
|
|
</P><P>
|
|
|
|
<A NAME="IDX848"></A>
|
|
<A NAME="IDX849"></A>
|
|
The macro <CODE>REG_NOTE_KIND (<VAR>x</VAR>)</CODE> returns the kind of
|
|
register note. Its counterpart, the macro <CODE>PUT_REG_NOTE_KIND
|
|
(<VAR>x</VAR>, <VAR>newkind</VAR>)</CODE> sets the register note type of <VAR>x</VAR> to be
|
|
<VAR>newkind</VAR>.
|
|
</P><P>
|
|
|
|
Register notes are of three classes: They may say something about an
|
|
input to an insn, they may say something about an output of an insn, or
|
|
they may create a linkage between two insns. There are also a set
|
|
of values that are only used in <CODE>LOG_LINKS</CODE>.
|
|
</P><P>
|
|
|
|
These register notes annotate inputs to an insn:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX850"></A>
|
|
<DT><CODE>REG_DEAD</CODE>
|
|
<DD>The value in <VAR>op</VAR> dies in this insn; that is to say, altering the
|
|
value immediately after this insn would not affect the future behavior
|
|
of the program.
|
|
<P>
|
|
|
|
This does not necessarily mean that the register <VAR>op</VAR> has no useful
|
|
value after this insn since it may also be an output of the insn. In
|
|
such a case, however, a <CODE>REG_DEAD</CODE> note would be redundant and is
|
|
usually not present until after the reload pass, but no code relies on
|
|
this fact.
|
|
</P><P>
|
|
|
|
<A NAME="IDX851"></A>
|
|
<DT><CODE>REG_INC</CODE>
|
|
<DD>The register <VAR>op</VAR> is incremented (or decremented; at this level
|
|
there is no distinction) by an embedded side effect inside this insn.
|
|
This means it appears in a <CODE>post_inc</CODE>, <CODE>pre_inc</CODE>,
|
|
<CODE>post_dec</CODE> or <CODE>pre_dec</CODE> expression.
|
|
<P>
|
|
|
|
<A NAME="IDX852"></A>
|
|
<DT><CODE>REG_NONNEG</CODE>
|
|
<DD>The register <VAR>op</VAR> is known to have a nonnegative value when this
|
|
insn is reached. This is used so that decrement and branch until zero
|
|
instructions, such as the m68k dbra, can be matched.
|
|
<P>
|
|
|
|
The <CODE>REG_NONNEG</CODE> note is added to insns only if the machine
|
|
description has a <SAMP>`decrement_and_branch_until_zero'</SAMP> pattern.
|
|
</P><P>
|
|
|
|
<A NAME="IDX853"></A>
|
|
<DT><CODE>REG_NO_CONFLICT</CODE>
|
|
<DD>This insn does not cause a conflict between <VAR>op</VAR> and the item
|
|
being set by this insn even though it might appear that it does.
|
|
In other words, if the destination register and <VAR>op</VAR> could
|
|
otherwise be assigned the same register, this insn does not
|
|
prevent that assignment.
|
|
<P>
|
|
|
|
Insns with this note are usually part of a block that begins with a
|
|
<CODE>clobber</CODE> insn specifying a multi-word pseudo register (which will
|
|
be the output of the block), a group of insns that each set one word of
|
|
the value and have the <CODE>REG_NO_CONFLICT</CODE> note attached, and a final
|
|
insn that copies the output to itself with an attached <CODE>REG_EQUAL</CODE>
|
|
note giving the expression being computed. This block is encapsulated
|
|
with <CODE>REG_LIBCALL</CODE> and <CODE>REG_RETVAL</CODE> notes on the first and
|
|
last insns, respectively.
|
|
</P><P>
|
|
|
|
<A NAME="IDX854"></A>
|
|
<DT><CODE>REG_LABEL</CODE>
|
|
<DD>This insn uses <VAR>op</VAR>, a <CODE>code_label</CODE>, but is not a
|
|
<CODE>jump_insn</CODE>. The presence of this note allows jump optimization to
|
|
be aware that <VAR>op</VAR> is, in fact, being used.
|
|
</DL>
|
|
<P>
|
|
|
|
The following notes describe attributes of outputs of an insn:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX855"></A>
|
|
<A NAME="IDX856"></A>
|
|
<DT><CODE>REG_EQUIV</CODE>
|
|
<DD><DT><CODE>REG_EQUAL</CODE>
|
|
<DD>This note is only valid on an insn that sets only one register and
|
|
indicates that that register will be equal to <VAR>op</VAR> at run time; the
|
|
scope of this equivalence differs between the two types of notes. The
|
|
value which the insn explicitly copies into the register may look
|
|
different from <VAR>op</VAR>, but they will be equal at run time. If the
|
|
output of the single <CODE>set</CODE> is a <CODE>strict_low_part</CODE> expression,
|
|
the note refers to the register that is contained in <CODE>SUBREG_REG</CODE>
|
|
of the <CODE>subreg</CODE> expression.
|
|
|
|
For <CODE>REG_EQUIV</CODE>, the register is equivalent to <VAR>op</VAR> throughout
|
|
the entire function, and could validly be replaced in all its
|
|
occurrences by <VAR>op</VAR>. ("Validly" here refers to the data flow of
|
|
the program; simple replacement may make some insns invalid.) For
|
|
example, when a constant is loaded into a register that is never
|
|
assigned any other value, this kind of note is used.
|
|
<P>
|
|
|
|
When a parameter is copied into a pseudo-register at entry to a function,
|
|
a note of this kind records that the register is equivalent to the stack
|
|
slot where the parameter was passed. Although in this case the register
|
|
may be set by other insns, it is still valid to replace the register
|
|
by the stack slot throughout the function.
|
|
</P><P>
|
|
|
|
A <CODE>REG_EQUIV</CODE> note is also used on an instruction which copies a
|
|
register parameter into a pseudo-register at entry to a function, if
|
|
there is a stack slot where that parameter could be stored. Although
|
|
other insns may set the pseudo-register, it is valid for the compiler to
|
|
replace the pseudo-register by stack slot throughout the function,
|
|
provided the compiler ensures that the stack slot is properly
|
|
initialized by making the replacement in the initial copy instruction as
|
|
well. This is used on machines for which the calling convention
|
|
allocates stack space for register parameters. See
|
|
<CODE>REG_PARM_STACK_SPACE</CODE> in <A HREF="gcc_17.html#SEC217" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC217">17.7.5 Passing Function Arguments on the Stack</A>.
|
|
</P><P>
|
|
|
|
In the case of <CODE>REG_EQUAL</CODE>, the register that is set by this insn
|
|
will be equal to <VAR>op</VAR> at run time at the end of this insn but not
|
|
necessarily elsewhere in the function. In this case, <VAR>op</VAR>
|
|
is typically an arithmetic expression. For example, when a sequence of
|
|
insns such as a library call is used to perform an arithmetic operation,
|
|
this kind of note is attached to the insn that produces or copies the
|
|
final value.
|
|
</P><P>
|
|
|
|
These two notes are used in different ways by the compiler passes.
|
|
<CODE>REG_EQUAL</CODE> is used by passes prior to register allocation (such as
|
|
common subexpression elimination and loop optimization) to tell them how
|
|
to think of that value. <CODE>REG_EQUIV</CODE> notes are used by register
|
|
allocation to indicate that there is an available substitute expression
|
|
(either a constant or a <CODE>mem</CODE> expression for the location of a
|
|
parameter on the stack) that may be used in place of a register if
|
|
insufficient registers are available.
|
|
</P><P>
|
|
|
|
Except for stack homes for parameters, which are indicated by a
|
|
<CODE>REG_EQUIV</CODE> note and are not useful to the early optimization
|
|
passes and pseudo registers that are equivalent to a memory location
|
|
throughout there entire life, which is not detected until later in
|
|
the compilation, all equivalences are initially indicated by an attached
|
|
<CODE>REG_EQUAL</CODE> note. In the early stages of register allocation, a
|
|
<CODE>REG_EQUAL</CODE> note is changed into a <CODE>REG_EQUIV</CODE> note if
|
|
<VAR>op</VAR> is a constant and the insn represents the only set of its
|
|
destination register.
|
|
</P><P>
|
|
|
|
Thus, compiler passes prior to register allocation need only check for
|
|
<CODE>REG_EQUAL</CODE> notes and passes subsequent to register allocation
|
|
need only check for <CODE>REG_EQUIV</CODE> notes.
|
|
</P><P>
|
|
|
|
<A NAME="IDX857"></A>
|
|
<DT><CODE>REG_UNUSED</CODE>
|
|
<DD>The register <VAR>op</VAR> being set by this insn will not be used in a
|
|
subsequent insn. This differs from a <CODE>REG_DEAD</CODE> note, which
|
|
indicates that the value in an input will not be used subsequently.
|
|
These two notes are independent; both may be present for the same
|
|
register.
|
|
<P>
|
|
|
|
<A NAME="IDX858"></A>
|
|
<DT><CODE>REG_WAS_0</CODE>
|
|
<DD>The single output of this insn contained zero before this insn.
|
|
<VAR>op</VAR> is the insn that set it to zero. You can rely on this note if
|
|
it is present and <VAR>op</VAR> has not been deleted or turned into a <CODE>note</CODE>;
|
|
its absence implies nothing.
|
|
</DL>
|
|
<P>
|
|
|
|
These notes describe linkages between insns. They occur in pairs: one
|
|
insn has one of a pair of notes that points to a second insn, which has
|
|
the inverse note pointing back to the first insn.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX859"></A>
|
|
<DT><CODE>REG_RETVAL</CODE>
|
|
<DD>This insn copies the value of a multi-insn sequence (for example, a
|
|
library call), and <VAR>op</VAR> is the first insn of the sequence (for a
|
|
library call, the first insn that was generated to set up the arguments
|
|
for the library call).
|
|
<P>
|
|
|
|
Loop optimization uses this note to treat such a sequence as a single
|
|
operation for code motion purposes and flow analysis uses this note to
|
|
delete such sequences whose results are dead.
|
|
</P><P>
|
|
|
|
A <CODE>REG_EQUAL</CODE> note will also usually be attached to this insn to
|
|
provide the expression being computed by the sequence.
|
|
</P><P>
|
|
|
|
These notes will be deleted after reload, since they are no longer
|
|
accurate or useful.
|
|
</P><P>
|
|
|
|
<A NAME="IDX860"></A>
|
|
<DT><CODE>REG_LIBCALL</CODE>
|
|
<DD>This is the inverse of <CODE>REG_RETVAL</CODE>: it is placed on the first
|
|
insn of a multi-insn sequence, and it points to the last one.
|
|
<P>
|
|
|
|
These notes are deleted after reload, since they are no longer useful or
|
|
accurate.
|
|
</P><P>
|
|
|
|
<A NAME="IDX861"></A>
|
|
<A NAME="IDX862"></A>
|
|
<DT><CODE>REG_CC_SETTER</CODE>
|
|
<DD><DT><CODE>REG_CC_USER</CODE>
|
|
<DD>On machines that use <CODE>cc0</CODE>, the insns which set and use <CODE>cc0</CODE>
|
|
set and use <CODE>cc0</CODE> are adjacent. However, when branch delay slot
|
|
filling is done, this may no longer be true. In this case a
|
|
<CODE>REG_CC_USER</CODE> note will be placed on the insn setting <CODE>cc0</CODE> to
|
|
point to the insn using <CODE>cc0</CODE> and a <CODE>REG_CC_SETTER</CODE> note will
|
|
be placed on the insn using <CODE>cc0</CODE> to point to the insn setting
|
|
<CODE>cc0</CODE>.</DL>
|
|
<P>
|
|
|
|
These values are only used in the <CODE>LOG_LINKS</CODE> field, and indicate
|
|
the type of dependency that each link represents. Links which indicate
|
|
a data dependence (a read after write dependence) do not use any code,
|
|
they simply have mode <CODE>VOIDmode</CODE>, and are printed without any
|
|
descriptive text.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX863"></A>
|
|
<DT><CODE>REG_DEP_ANTI</CODE>
|
|
<DD>This indicates an anti dependence (a write after read dependence).
|
|
<P>
|
|
|
|
<A NAME="IDX864"></A>
|
|
<DT><CODE>REG_DEP_OUTPUT</CODE>
|
|
<DD>This indicates an output dependence (a write after write dependence).
|
|
</DL>
|
|
<P>
|
|
|
|
These notes describe information gathered from gcov profile data. They
|
|
are stored in the <CODE>REG_NOTES</CODE> field of an insn as an
|
|
<CODE>expr_list</CODE>.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX865"></A>
|
|
<DT><CODE>REG_EXEC_COUNT</CODE>
|
|
<DD>This is used to indicate the number of times a basic block was executed
|
|
according to the profile data. The note is attached to the first insn in
|
|
the basic block.
|
|
<P>
|
|
|
|
<A NAME="IDX866"></A>
|
|
<DT><CODE>REG_BR_PROB</CODE>
|
|
<DD>This is used to specify the ratio of branches to non-branches of a
|
|
branch insn according to the profile data. The value is stored as a
|
|
value between 0 and REG_BR_PROB_BASE; larger values indicate a higher
|
|
probability that the branch will be taken.
|
|
<P>
|
|
|
|
<A NAME="IDX867"></A>
|
|
<DT><CODE>REG_BR_PRED</CODE>
|
|
<DD>These notes are found in JUMP insns after delayed branch scheduling
|
|
has taken place. They indicate both the direction and the likelyhood
|
|
of the JUMP. The format is a bitmask of ATTR_FLAG_* values.
|
|
<P>
|
|
|
|
<A NAME="IDX868"></A>
|
|
<DT><CODE>REG_FRAME_RELATED_EXPR</CODE>
|
|
<DD>This is used on an RTX_FRAME_RELATED_P insn wherein the attached expression
|
|
is used in place of the actual insn pattern. This is done in cases where
|
|
the pattern is either complex or misleading.
|
|
</DL>
|
|
<P>
|
|
|
|
For convenience, the machine mode in an <CODE>insn_list</CODE> or
|
|
<CODE>expr_list</CODE> is printed using these symbolic codes in debugging dumps.
|
|
</P><P>
|
|
|
|
<A NAME="IDX869"></A>
|
|
<A NAME="IDX870"></A>
|
|
The only difference between the expression codes <CODE>insn_list</CODE> and
|
|
<CODE>expr_list</CODE> is that the first operand of an <CODE>insn_list</CODE> is
|
|
assumed to be an insn and is printed in debugging dumps as the insn's
|
|
unique id; the first operand of an <CODE>expr_list</CODE> is printed in the
|
|
ordinary way as an expression.
|
|
</P><P>
|
|
|
|
<A NAME="Calls"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC166"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC165" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC165"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC167" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC167"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.17 RTL Representation of Function-Call Insns </H2>
|
|
<!--docid::SEC166::-->
|
|
<P>
|
|
|
|
Insns that call subroutines have the RTL expression code <CODE>call_insn</CODE>.
|
|
These insns must satisfy special rules, and their bodies must use a special
|
|
RTL expression code, <CODE>call</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX871"></A>
|
|
A <CODE>call</CODE> expression has two operands, as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(call (mem:<VAR>fm</VAR> <VAR>addr</VAR>) <VAR>nbytes</VAR>)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <VAR>nbytes</VAR> is an operand that represents the number of bytes of
|
|
argument data being passed to the subroutine, <VAR>fm</VAR> is a machine mode
|
|
(which must equal as the definition of the <CODE>FUNCTION_MODE</CODE> macro in
|
|
the machine description) and <VAR>addr</VAR> represents the address of the
|
|
subroutine.
|
|
</P><P>
|
|
|
|
For a subroutine that returns no value, the <CODE>call</CODE> expression as
|
|
shown above is the entire body of the insn, except that the insn might
|
|
also contain <CODE>use</CODE> or <CODE>clobber</CODE> expressions.
|
|
</P><P>
|
|
|
|
<A NAME="IDX872"></A>
|
|
For a subroutine that returns a value whose mode is not <CODE>BLKmode</CODE>,
|
|
the value is returned in a hard register. If this register's number is
|
|
<VAR>r</VAR>, then the body of the call insn looks like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(set (reg:<VAR>m</VAR> <VAR>r</VAR>)
|
|
(call (mem:<VAR>fm</VAR> <VAR>addr</VAR>) <VAR>nbytes</VAR>))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This RTL expression makes it clear (to the optimizer passes) that the
|
|
appropriate register receives a useful value in this insn.
|
|
</P><P>
|
|
|
|
When a subroutine returns a <CODE>BLKmode</CODE> value, it is handled by
|
|
passing to the subroutine the address of a place to store the value.
|
|
So the call insn itself does not "return" any value, and it has the
|
|
same RTL form as a call that returns nothing.
|
|
</P><P>
|
|
|
|
On some machines, the call instruction itself clobbers some register,
|
|
for example to contain the return address. <CODE>call_insn</CODE> insns
|
|
on these machines should have a body which is a <CODE>parallel</CODE>
|
|
that contains both the <CODE>call</CODE> expression and <CODE>clobber</CODE>
|
|
expressions that indicate which registers are destroyed. Similarly,
|
|
if the call instruction requires some register other than the stack
|
|
pointer that is not explicitly mentioned it its RTL, a <CODE>use</CODE>
|
|
subexpression should mention that register.
|
|
</P><P>
|
|
|
|
Functions that are called are assumed to modify all registers listed in
|
|
the configuration macro <CODE>CALL_USED_REGISTERS</CODE> (see section <A HREF="gcc_17.html#SEC205" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC205">17.5.1 Basic Characteristics of Registers</A>) and, with the exception of <CODE>const</CODE> functions and library
|
|
calls, to modify all of memory.
|
|
</P><P>
|
|
|
|
Insns containing just <CODE>use</CODE> expressions directly precede the
|
|
<CODE>call_insn</CODE> insn to indicate which registers contain inputs to the
|
|
function. Similarly, if registers other than those in
|
|
<CODE>CALL_USED_REGISTERS</CODE> are clobbered by the called function, insns
|
|
containing a single <CODE>clobber</CODE> follow immediately after the call to
|
|
indicate which registers.
|
|
</P><P>
|
|
|
|
<A NAME="Sharing"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC167"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC166" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC166"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC168" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC168"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.18 Structure Sharing Assumptions </H2>
|
|
<!--docid::SEC167::-->
|
|
<P>
|
|
|
|
The compiler assumes that certain kinds of RTL expressions are unique;
|
|
there do not exist two distinct objects representing the same value.
|
|
In other cases, it makes an opposite assumption: that no RTL expression
|
|
object of a certain kind appears in more than one place in the
|
|
containing structure.
|
|
</P><P>
|
|
|
|
These assumptions refer to a single function; except for the RTL
|
|
objects that describe global variables and external functions,
|
|
and a few standard objects such as small integer constants,
|
|
no RTL objects are common to two functions.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<A NAME="IDX873"></A>
|
|
<LI>
|
|
Each pseudo-register has only a single <CODE>reg</CODE> object to represent it,
|
|
and therefore only a single machine mode.
|
|
<P>
|
|
|
|
<A NAME="IDX874"></A>
|
|
<A NAME="IDX875"></A>
|
|
<LI>
|
|
For any symbolic label, there is only one <CODE>symbol_ref</CODE> object
|
|
referring to it.
|
|
<P>
|
|
|
|
<A NAME="IDX876"></A>
|
|
<LI>
|
|
There is only one <CODE>const_int</CODE> expression with value 0, only
|
|
one with value 1, and only one with value -1.
|
|
Some other integer values are also stored uniquely.
|
|
<P>
|
|
|
|
<A NAME="IDX877"></A>
|
|
<LI>
|
|
There is only one <CODE>pc</CODE> expression.
|
|
<P>
|
|
|
|
<A NAME="IDX878"></A>
|
|
<LI>
|
|
There is only one <CODE>cc0</CODE> expression.
|
|
<P>
|
|
|
|
<A NAME="IDX879"></A>
|
|
<LI>
|
|
There is only one <CODE>const_double</CODE> expression with value 0 for
|
|
each floating point mode. Likewise for values 1 and 2.
|
|
<P>
|
|
|
|
<A NAME="IDX880"></A>
|
|
<A NAME="IDX881"></A>
|
|
<LI>
|
|
No <CODE>label_ref</CODE> or <CODE>scratch</CODE> appears in more than one place in
|
|
the RTL structure; in other words, it is safe to do a tree-walk of all
|
|
the insns in the function and assume that each time a <CODE>label_ref</CODE>
|
|
or <CODE>scratch</CODE> is seen it is distinct from all others that are seen.
|
|
<P>
|
|
|
|
<A NAME="IDX882"></A>
|
|
<LI>
|
|
Only one <CODE>mem</CODE> object is normally created for each static
|
|
variable or stack slot, so these objects are frequently shared in all
|
|
the places they appear. However, separate but equal objects for these
|
|
variables are occasionally made.
|
|
<P>
|
|
|
|
<A NAME="IDX883"></A>
|
|
<LI>
|
|
When a single <CODE>asm</CODE> statement has multiple output operands, a
|
|
distinct <CODE>asm_operands</CODE> expression is made for each output operand.
|
|
However, these all share the vector which contains the sequence of input
|
|
operands. This sharing is used later on to test whether two
|
|
<CODE>asm_operands</CODE> expressions come from the same statement, so all
|
|
optimizations must carefully preserve the sharing if they copy the
|
|
vector at all.
|
|
<P>
|
|
|
|
<LI>
|
|
No RTL object appears in more than one place in the RTL structure
|
|
except as described above. Many passes of the compiler rely on this
|
|
by assuming that they can modify RTL objects in place without unwanted
|
|
side-effects on other insns.
|
|
<P>
|
|
|
|
<A NAME="IDX884"></A>
|
|
<LI>
|
|
During initial RTL generation, shared structure is freely introduced.
|
|
After all the RTL for a function has been generated, all shared
|
|
structure is copied by <CODE>unshare_all_rtl</CODE> in <TT>`emit-rtl.c'</TT>,
|
|
after which the above rules are guaranteed to be followed.
|
|
<P>
|
|
|
|
<A NAME="IDX885"></A>
|
|
<LI>
|
|
During the combiner pass, shared structure within an insn can exist
|
|
temporarily. However, the shared structure is copied before the
|
|
combiner is finished with the insn. This is done by calling
|
|
<CODE>copy_rtx_if_shared</CODE>, which is a subroutine of
|
|
<CODE>unshare_all_rtl</CODE>.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Reading RTL"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC168"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC167" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC167"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC149" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC149"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 15.19 Reading RTL </H2>
|
|
<!--docid::SEC168::-->
|
|
<P>
|
|
|
|
To read an RTL object from a file, call <CODE>read_rtx</CODE>. It takes one
|
|
argument, a stdio stream, and returns a single RTL object.
|
|
</P><P>
|
|
|
|
Reading RTL from a file is very slow. This is not currently a
|
|
problem since reading RTL occurs only as part of building the
|
|
compiler.
|
|
</P><P>
|
|
|
|
People frequently have the idea of using RTL stored as text in a file as
|
|
an interface between a language front end and the bulk of GNU CC. This
|
|
idea is not feasible.
|
|
</P><P>
|
|
|
|
GNU CC was designed to use RTL internally only. Correct RTL for a given
|
|
program is very dependent on the particular target machine. And the RTL
|
|
does not contain all the information about the program.
|
|
</P><P>
|
|
|
|
The proper way to interface GNU CC to a new language front end is with
|
|
the "tree" data structure. There is no manual for this data
|
|
structure, but it is described in the files <TT>`tree.h'</TT> and
|
|
<TT>`tree.def'</TT>.
|
|
</P><P>
|
|
|
|
<A NAME="Machine Desc"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_15.html#SEC151" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_15.html#SEC151"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_16.html#SEC169" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC169"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|