--- gcc/gcc.info-14 2018/04/24 17:51:20 1.1.1.1 +++ gcc/gcc.info-14 2018/04/24 18:10:46 1.1.1.6 @@ -1,1090 +1,939 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.54 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. - Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. + Published by the Free Software Foundation 675 Massachusetts Avenue +Cambridge, MA 02139 USA - Permission is granted to make and distribute verbatim copies of -this manual provided the copyright notice and this permission notice -are preserved on all copies. + Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc. + + Permission is granted to make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also -that the section entitled "GNU General Public License" is included -exactly as in the original, and provided that the entire resulting -derived work is distributed under the terms of a permission notice -identical to this one. +that the sections entitled "GNU General Public License" and "Protect +Your Freedom--Fight `Look And Feel'" are included exactly as in the +original, and provided that the entire resulting derived work is +distributed under the terms of a permission notice identical to this +one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified -versions, except that the section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +License" and "Protect Your Freedom--Fight `Look And Feel'", and this +permission notice, may be included in translations approved by the Free +Software Foundation instead of in the original English.  -File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Machine Macros +File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc -Trampolines for Nested Functions -================================ +C Statements for Assembler Output +================================= - A "trampoline" is a small piece of code that is created at run time -when the address of a nested function is taken. It normally resides on -the stack, in the stack frame of the containing function. These macros -tell GNU CC how to generate code to allocate and initialize a -trampoline. - - The instructions in the trampoline must do two things: load a -constant address into the static chain register, and jump to the real -address of the nested function. On CISC machines such as the m68k, -this requires two instructions, a move immediate and a jump. Then the -two addresses exist in the trampoline as word-long immediate operands. - On RISC machines, it is often necessary to load each address into a -register in two parts. Then pieces of each address form separate -immediate operands. - - The code generated to initialize the trampoline must store the -variable parts--the static chain value and the function address--into -the immediate operands of the instructions. On a CISC machine, this is -simply a matter of copying each address to a memory reference at the -proper offset from the start of the trampoline. On a RISC machine, it -may be necessary to take out pieces of the address and store them -separately. - -`TRAMPOLINE_TEMPLATE (FILE)' - A C statement to output, on the stream FILE, assembler code for a - block of data that contains the constant parts of a trampoline. - This code should not include a label--the label is taken care of - automatically. - -`TRAMPOLINE_SIZE' - A C expression for the size in bytes of the trampoline, as an - integer. - -`TRAMPOLINE_ALIGNMENT' - Alignment required for trampolines, in bits. - - If you don't define this macro, the value of `BIGGEST_ALIGNMENT' - is used for aligning trampolines. - -`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' - A C statement to initialize the variable parts of a trampoline. - ADDR is an RTX for the address of the trampoline; FNADDR is an - RTX for the address of the nested function; STATIC_CHAIN is an - RTX for the static chain value that should be passed to the - function when it is called. - -`ALLOCATE_TRAMPOLINE (FP)' - A C expression to allocate run-time space for a trampoline. The - expression value should be an RTX representing a memory reference - to the space for the trampoline. - - If this macro is not defined, by default the trampoline is - allocated as a stack slot. This default is right for most - machines. The exceptions are machines where it is impossible to - execute instructions in the stack area. On such machines, you - may have to implement a separate stack, using this macro in - conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. - - FP points to a data structure, a `struct function', which - describes the compilation status of the immediate containing - function of the function which the trampoline is for. Normally - (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for - the trampoline is in the stack frame of this containing function. - Other allocation strategies probably must do something analogous - with this information. - - Implementing trampolines is difficult on many machines because they -have separate instruction and data caches. Writing into a stack -location fails to clear the memory in the instruction cache, so when -the program jumps to that location, it executes the old contents. - - Here are two possible solutions. One is to clear the relevant -parts of the instruction cache whenever a trampoline is set up. The -other is to make all trampolines identical, by having them jump to a -standard subroutine. The former technique makes trampoline execution -faster; the latter makes initialization faster. - - To clear the instruction cache when a trampoline is initialized, -define the following macros which describe the shape of the cache. - -`INSN_CACHE_SIZE' - The total size in bytes of the cache. - -`INSN_CACHE_LINE_WIDTH' - The length in bytes of each cache line. The cache is divided - into cache lines which are disjoint slots, each holding a - contiguous chunk of data fetched from memory. Each time data is - brought into the cache, an entire line is read at once. The data - loaded into a cache line is always aligned on a boundary equal to - the line size. - -`INSN_CACHE_DEPTH' - The number of alternative cache lines that can hold any - particular memory location. - - To use a standard subroutine, define the following macro. In -addition, you must make sure that the instructions in a trampoline -fill an entire cache line with identical instructions, or else ensure -that the beginning of the trampoline code is always aligned at the -same point in its cache line. Look in `m68k.h' as a guide. - -`TRANSFER_FROM_TRAMPOLINE' - Define this macro if trampolines need a special subroutine to do - their work. The macro should expand to a series of `asm' - statements which will be compiled with GNU CC. They go in a - library function named `__transfer_from_trampoline'. - - If you need to avoid executing the ordinary prologue code of a - compiled C function when you jump to the subroutine, you can do - so by placing a special label of your own in the assembler code. - Use one `asm' statement to generate an assembler label, and - another to make the label global. Then trampolines can use that - label to jump directly to your special assembler code. + Often a single fixed template string cannot produce correct and +efficient assembler code for all the cases that are recognized by a +single instruction pattern. For example, the opcodes may depend on the +kinds of operands; or some unfortunate combinations of operands may +require extra machine instructions. + + If the output control string starts with a `@', then it is actually +a series of templates, each on a separate line. (Blank lines and +leading spaces and tabs are ignored.) The templates correspond to the +pattern's constraint alternatives (*note Multi-Alternative::.). For +example, if a target machine has a two-address add instruction `addr' +to add into a register and another `addm' to add a register to memory, +you might write this pattern: + + (define_insn "addsi3" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (plus:SI (match_operand:SI 1 "general_operand" "0,0") + (match_operand:SI 2 "general_operand" "g,r")))] + "" + "@ + addr %2,%0 + addm %2,%0") + + If the output control string starts with a `*', then it is not an +output template but rather a piece of C program that should compute a +template. It should execute a `return' statement to return the +template-string you want. Most such templates use C string literals, +which require doublequote characters to delimit them. To include these +doublequote characters in the string, prefix each one with `\'. + + The operands may be found in the array `operands', whose C data type +is `rtx []'. + + It is very common to select different ways of generating assembler +code based on whether an immediate operand is within a certain range. +Be careful when doing this, because the result of `INTVAL' is an +integer on the host machine. If the host machine has more bits in an +`int' than the target machine has in the mode in which the constant +will be used, then some of the bits you get from `INTVAL' will be +superfluous. For proper results, you must carefully disregard the +values of those bits. + + It is possible to output an assembler instruction and then go on to +output or compute more of them, using the subroutine `output_asm_insn'. +This receives two arguments: a template-string and a vector of +operands. The vector may be `operands', or it may be another array of +`rtx' that you declare locally and initialize yourself. + + When an insn pattern has multiple alternatives in its constraints, +often the appearance of the assembler code is determined mostly by +which alternative was matched. When this is so, the C code can test +the variable `which_alternative', which is the ordinal number of the +alternative that was actually satisfied (0 for the first, 1 for the +second alternative, etc.). + + For example, suppose there are two opcodes for storing zero, `clrreg' +for registers and `clrmem' for memory locations. Here is how a pattern +could use `which_alternative' to choose between them: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "* + return (which_alternative == 0 + ? \"clrreg %0\" : \"clrmem %0\"); + ") + + The example above, where the assembler code to generate was *solely* +determined by the alternative, could also have been specified as +follows, having the output control string start with a `@': + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "@ + clrreg %0 + clrmem %0")  -File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Machine Macros - -Implicit Calls to Library Routines -================================== +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc -`MULSI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed full-word by another. If you do not - define this macro, the default name is used, which is `__mulsi3', - a function defined in `libgcc.a'. - -`DIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed full-word by another. If you do not define - this macro, the default name is used, which is `__divsi3', a - function defined in `libgcc.a'. - -`UDIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivsi3', a function defined in `libgcc.a'. - -`MODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed full-word by another. If - you do not define this macro, the default name is used, which is - `__modsi3', a function defined in `libgcc.a'. - -`UMODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umodsi3', a function defined in `libgcc.a'. - -`MULDI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed double-word by another. If you do - not define this macro, the default name is used, which is - `__muldi3', a function defined in `libgcc.a'. - -`DIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed double-word by another. If you do not - define this macro, the default name is used, which is `__divdi3', - a function defined in `libgcc.a'. - -`UDIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivdi3', a function defined in `libgcc.a'. - -`MODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed double-word by another. - If you do not define this macro, the default name is used, which - is `__moddi3', a function defined in `libgcc.a'. - -`UMODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umoddi3', a function defined in `libgcc.a'. - -`TARGET_MEM_FUNCTIONS' - Define this macro if GNU CC should generate calls to the System V - (and ANSI C) library functions `memcpy' and `memset' rather than - the BSD functions `bcopy' and `bzero'. - -`LIBGCC_NEEDS_DOUBLE' - Define this macro if only `float' arguments cannot be passed to - library routines (so they must be converted to `double'). This - macro affects both how library calls are generated and how the - library routines in `libgcc1.c' accept their arguments. It is - useful on machines where floating and fixed point arguments are - passed differently, such as the i860. - -`FLOAT_ARG_TYPE' - Define this macro to override the type used by the library - routines to pick up arguments of type `float'. (By default, they - use a union of `float' and `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers that expect all arguments declared as - `float' to arrive as `double'. To avoid this conversion, the - library routines ask for the value as some other type and then - treat it as a `float'. - - On some systems, no other type will work for this. For these - systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force - conversion of the values `double' before they are passed. - -`FLOATIFY (PASSED-VALUE)' - Define this macro to override the way library routines - redesignate a `float' argument as a `float' instead of the type - it was passed as. The default is an expression which takes the - `float' field of the union. - -`FLOAT_VALUE_TYPE' - Define this macro to override the type used by the library - routines to return values that ought to have type `float'. (By - default, they use `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers gratuitously convert values declared as - `float' into `double'. - -`INTIFY (FLOAT-VALUE)' - Define this macro to override the way the value of a - `float'-returning library routine should be packaged in order to - return it. These functions are actually declared to return type - `FLOAT_VALUE_TYPE' (normally `int'). - - These values can't be returned as type `float' because traditional - C compilers would gratuitously convert the value to a `double'. - - A local variable named `intify' is always available when the macro - `INTIFY' is used. It is a union of a `float' field named `f' and - a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. - - If you don't define this macro, the default definition works by - copying the value through that union. - -`SItype' - Define this macro as the name of the data type corresponding to - `SImode' in the system's own C compiler. - - You need not define this macro if that type is `int', as it - usually is. - -`perform_...' - Define these macros to supply explicit C statements to carry out - various arithmetic operations on types `float' and `double' in the - library routines in `libgcc1.c'. See that file for a full list - of these macros and their arguments. - - On most machines, you don't need to define any of these macros, - because the C compiler that comes with the system takes care of - doing them. - -`NEXT_OBJC_RUNTIME' - Define this macro to generate code for Objective C message - sending using the calling convention of the NeXT system. This - calling convention involves passing the object, the selector and - the method arguments all at once to the method-lookup library - function. - - The default calling convention passes just the object and the - selector to the lookup function, which returns a pointer to the - method. +Operand Constraints +=================== - -File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Machine Macros + Each `match_operand' in an instruction pattern can specify a +constraint for the type of operands allowed. Constraints can say +whether an operand may be in a register, and which kinds of register; +whether the operand can be a memory reference, and which kinds of +address; whether the operand may be an immediate constant, and which +possible values it may have. Constraints can also require two operands +to match. -Addressing Modes -================ +* Menu: -`HAVE_POST_INCREMENT' - Define this macro if the machine supports post-increment - addressing. - -`HAVE_PRE_INCREMENT' -`HAVE_POST_DECREMENT' -`HAVE_PRE_DECREMENT' - Similar for other kinds of addressing. - -`CONSTANT_ADDRESS_P (X)' - A C expression that is 1 if the RTX X is a constant which is a - valid address. On most machines, this can be defined as - `CONSTANT_P (X)', but a few machines are more restrictive in - which constant addresses are supported. - - `CONSTANT_P' accepts integer-values expressions whose values are - not explicitly known, such as `symbol_ref', `label_ref', and - `high' expressions and `const' arithmetic expressions, in - addition to `const_int' and `const_double' expressions. - -`MAX_REGS_PER_ADDRESS' - A number, the maximum number of registers that can appear in a - valid memory address. Note that it is up to you to specify a - value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' - would ever accept. - -`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' - A C compound statement with a conditional `goto LABEL;' executed - if X (an RTX) is a legitimate memory address on the target - machine for a memory operand of mode MODE. - - It usually pays to define several simpler macros to serve as - subroutines for this one. Otherwise it may be too complicated to - understand. - - This macro must exist in two variants: a strict variant and a - non-strict one. The strict variant is used in the reload pass. - It must be defined so that any pseudo-register that has not been - allocated a hard register is considered a memory reference. In - contexts where some kind of register is required, a - pseudo-register with no hard register must be rejected. - - The non-strict variant is used in other passes. It must be - defined to accept all pseudo-registers in every context where - some kind of register is required. - - Compiler source files that want to use the strict variant of this - macro define the macro `REG_OK_STRICT'. You should use an - `#ifdef REG_OK_STRICT' conditional to define the strict variant - in that case and the non-strict variant otherwise. - - Typically among the subroutines used to define - `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for - acceptable registers for various purposes (one for base - registers, one for index registers, and so on). Then only these - subroutine macros need have two variants; the higher levels of - macros may be the same whether strict or not. - - Normally, constant addresses which are the sum of a `symbol_ref' - and an integer are stored inside a `const' RTX to mark them as - constant. Therefore, there is no need to recognize such sums - specifically as legitimate addresses. Normally you would simply - recognize any `const' as legitimate. - - Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant - sums that are not marked with `const'. It assumes that a naked - `plus' indicates indexing. If so, then you *must* reject such - naked constant sums as illegitimate addresses, so that none of - them will be given to `PRINT_OPERAND_ADDRESS'. - - On some machines, whether a symbolic address is legitimate - depends on the section that the address refers to. On these - machines, define the macro `ENCODE_SECTION_INFO' to store the - information into the `symbol_ref', and then check for it here. - When you see a `const', you will have to look inside it to find - the `symbol_ref' in order to determine the section. *Note - Assembler Format::. - - The best way to modify the name string is by adding text to the - beginning, with suitable punctuation to prevent any ambiguity. - Allocate the new name in `saveable_obstack'. You will have to - modify `ASM_OUTPUT_LABELREF' to remove and decode the added text - and output the name accordingly. - - You can check the information stored here into the `symbol_ref' in - the definitions of `GO_IF_LEGITIMATE_ADDRESS' and - `PRINT_OPERAND_ADDRESS'. - -`REG_OK_FOR_BASE_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as a base register. For hard registers, it - should always accept those which the hardware permits and reject - the others. Whether the macro accepts or rejects pseudo - registers must be controlled by `REG_OK_STRICT' as described - above. This usually requires two variant definitions, of which - `REG_OK_STRICT' controls the one actually used. - -`REG_OK_FOR_INDEX_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as an index register. - - The difference between an index register and a base register is - that the index register may be scaled. If an address involves - the sum of two registers, neither one of them scaled, then either - one may be labeled the "base" and the other the "index"; but - whichever labeling is used must fit the machine's constraints of - which registers may serve in each capacity. The compiler will - try both labelings, looking for one that is valid, and will - reload one or both registers only if neither labeling works. - -`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' - A C compound statement that attempts to replace X with a valid - memory address for an operand of mode MODE. WIN will be a C - statement label elsewhere in the code; the macro definition may - use - - GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); - - to avoid further processing if the address has become legitimate. - - X will always be the result of a call to `break_out_memory_refs', - and OLDX will be the operand that was given to that function to - produce X. - - The code generated by this macro should not alter the - substructure of X. If it transforms X into a more legitimate - form, it should assign X (which will always be a C variable) a - new value. - - It is not necessary for this macro to come up with a legitimate - address. The compiler has standard ways of doing so in all - cases. In fact, it is safe for this macro to do nothing. But - often a machine-dependent strategy can generate better code. - -`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' - A C statement or compound statement with a conditional `goto - LABEL;' executed if memory address X (an RTX) can have different - meanings depending on the machine mode of the memory reference it - is used for. - - Autoincrement and autodecrement addresses typically have - mode-dependent effects because the amount of the increment or - decrement is the size of the operand being addressed. Some - machines have other mode-dependent addresses. Many RISC machines - have no mode-dependent addresses. - - You may assume that ADDR is a valid address for the machine. - -`LEGITIMATE_CONSTANT_P (X)' - A C expression that is nonzero if X is a legitimate constant for - an immediate operand on the target machine. You can assume that - X satisfies `CONSTANT_P', so you need not check this. In fact, - `1' is a suitable definition for this macro on machines where - anything `CONSTANT_P' is valid. - -`LEGITIMATE_PIC_OPERAND_P (X)' - A C expression that is nonzero if X is a legitimate immediate - operand on the target machine when generating position - independent code. You can assume that X satisfies `CONSTANT_P', - so you need not check this. You can also assume FLAG_PIC is - true, so you need not check it either. You need not define this - macro if all constants (including `SYMBOL_REF') can be immediate - operands when generating position independent code. +* Simple Constraints:: Basic use of constraints. +* Multi-Alternative:: When an insn has two alternative constraint-patterns. +* Class Preferences:: Constraints guide which hard register to put things in. +* Modifiers:: More precise control over effects of constraints. +* Machine Constraints:: Existing constraints for some particular machines. +* No Constraints:: Describing a clean machine without constraints.  -File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Machine Macros +File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints -Condition Code Status -===================== +Simple Constraints +------------------ - The file `conditions.h' defines a variable `cc_status' to describe -how the condition code was computed (in case the interpretation of the -condition code depends on the instruction that it was set by). This -variable contains the RTL expressions on which the condition code is -currently based, and several standard flags. - - Sometimes additional machine-specific flags must be defined in the -machine description header file. It can also add additional -machine-specific information by defining `CC_STATUS_MDEP'. - -`CC_STATUS_MDEP' - C code for a data type which is used for declaring the `mdep' - component of `cc_status'. It defaults to `int'. - - This macro is not used on machines that do not use `cc0'. - -`CC_STATUS_MDEP_INIT' - A C expression to initialize the `mdep' field to "empty". The - default definition does nothing, since most machines don't use - the field anyway. If you want to use the field, you should - probably define this macro to initialize it. - - This macro is not used on machines that do not use `cc0'. - -`NOTICE_UPDATE_CC (EXP, INSN)' - A C compound statement to set the components of `cc_status' - appropriately for an insn INSN whose body is EXP. It is this - macro's responsibility to recognize insns that set the condition - code as a byproduct of other activity as well as those that - explicitly set `(cc0)'. - - This macro is not used on machines that do not use `cc0'. - - If there are insns that do not set the condition code but do alter - other machine registers, this macro must check to see whether they - invalidate the expressions that the condition code is recorded as - reflecting. For example, on the 68000, insns that store in - address registers do not set the condition code, which means that - usually `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for - such insns. But suppose that the previous insn set the condition - code based on location `a4@(102)' and the current insn stores a - new value in `a4'. Although the condition code is not changed by - this, it will no longer be true that it reflects the contents of - `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' - in this case to say that nothing is known about the condition - code value. - - The definition of `NOTICE_UPDATE_CC' must be prepared to deal - with the results of peephole optimization: insns whose patterns - are `parallel' RTXs containing various `reg', `mem' or constants - which are just the operands. The RTL structure of these insns is - not sufficient to indicate what the insns actually do. What - `NOTICE_UPDATE_CC' should do when it sees one is just to run - `CC_STATUS_INIT'. - - A possible definition of `NOTICE_UPDATE_CC' is to call a function - that looks at an attribute (*note Insn Attributes::.) named, for - example, `cc'. This avoids having detailed information about - patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. - -`EXTRA_CC_MODES' - A list of names to be used for additional modes for condition code - values in registers (*note Jump Patterns::.). These names are - added to `enum machine_mode' and all have class `MODE_CC'. By - convention, they should start with `CC' and end with `mode'. - - You should only define this macro if your machine does not use - `cc0' and only if additional modes are required. - -`EXTRA_CC_NAMES' - A list of C strings giving the names for the modes listed in - `EXTRA_CC_MODES'. For example, the Sparc defines this macro and - `EXTRA_CC_MODES' as - - #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode - #define EXTRA_CC_NAMES "CC_NOOV", "CCFP" - - This macro is not required if `EXTRA_CC_MODES' is not defined. - -`SELECT_CC_MODE (OP, X)' - Returns a mode from class `MODE_CC' to be used when comparison - operation code OP is applied to rtx X. For example, on the Sparc, - `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. for a - description of the reason for this definition) - - #define SELECT_CC_MODE(OP,X) \ - (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \ - : (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ - || GET_CODE (X) == NEG) \ - ? CC_NOOVmode : CCmode) + The simplest kind of constraint is a string full of letters, each of +which describes one kind of operand that is permitted. Here are the +letters that are allowed: + +`m' + A memory operand is allowed, with any kind of address that the + machine supports in general. + +`o' + A memory operand is allowed, but only if the address is + "offsettable". This means that adding a small integer (actually, + the width in bytes of the operand, as determined by its machine + mode) may be added to the address and the result is also a valid + memory address. + + For example, an address which is constant is offsettable; so is an + address that is the sum of a register and a constant (as long as a + slightly larger constant is also within the range of + address-offsets supported by the machine); but an autoincrement or + autodecrement address is not offsettable. More complicated + indirect/indexed addresses may or may not be offsettable depending + on the other addressing modes that the machine supports. + + Note that in an output operand which can be matched by another + operand, the constraint letter `o' is valid only when accompanied + by both `<' (if the target machine has predecrement addressing) + and `>' (if the target machine has preincrement addressing). + +`V' + A memory operand that is not offsettable. In other words, + anything that would fit the `m' constraint but not the `o' + constraint. + +`<' + A memory operand with autodecrement addressing (either + predecrement or postdecrement) is allowed. + +`>' + A memory operand with autoincrement addressing (either + preincrement or postincrement) is allowed. + +`r' + A register operand is allowed provided that it is in a general + register. + +`d', `a', `f', ... + Other letters can be defined in machine-dependent fashion to stand + for particular classes of registers. `d', `a' and `f' are defined + on the 68000/68020 to stand for data, address and floating point + registers. + +`i' + An immediate integer operand (one with constant value) is allowed. + This includes symbolic constants whose values will be known only at + assembly time. + +`n' + An immediate integer operand with a known numeric value is allowed. + Many systems cannot support assembly-time constants for operands + less than a word wide. Constraints for these operands should use + `n' rather than `i'. + +`I', `J', `K', ... `P' + Other letters in the range `I' through `P' may be defined in a + machine-dependent fashion to permit immediate integer operands with + explicit integer values in specified ranges. For example, on the + 68000, `I' is defined to stand for the range of values 1 to 8. + This is the range permitted as a shift count in the shift + instructions. - This macro is not required if `EXTRA_CC_MODES' is not defined. +`E' + An immediate floating operand (expression code `const_double') is + allowed, but only if the target floating point format is the same + as that of the host machine (on which the compiler is running). + +`F' + An immediate floating operand (expression code `const_double') is + allowed. + +`G', `H' + `G' and `H' may be defined in a machine-dependent fashion to + permit immediate floating operands in particular ranges of values. + +`s' + An immediate integer operand whose value is not an explicit + integer is allowed. + + This might appear strange; if an insn allows a constant operand + with a value not known at compile time, it certainly must allow + any known value. So why use `s' instead of `i'? Sometimes it + allows better code to be generated. + + For example, on the 68000 in a fullword instruction it is possible + to use an immediate operand; but if the immediate value is between + -128 and 127, better code results from loading the value into a + register and using the register. This is because the load into + the register can be done with a `moveq' instruction. We arrange + for this to happen by defining the letter `K' to mean "any integer + outside the range -128 to 127", and then specifying `Ks' in the + operand constraints. + +`g' + Any register, memory or immediate integer operand is allowed, + except for registers that are not general registers. + +`X' + Any operand whatsoever is allowed, even if it does not satisfy + `general_operand'. This is normally used in the constraint of a + `match_scratch' when certain alternatives will not actually + require a scratch register. + +`0', `1', `2', ... `9' + An operand that matches the specified operand number is allowed. + If a digit is used together with letters within the same + alternative, the digit should come last. + + This is called a "matching constraint" and what it really means is + that the assembler has only a single operand that fills two roles + considered separate in the RTL insn. For example, an add insn has + two input operands and one output operand in the RTL, but on most + CISC machines an add instruction really has only two operands, one + of them an input-output operand: + + addl #35,r12 + + Matching constraints are used in these circumstances. More + precisely, the two operands that match must include one input-only + operand and one output-only operand. Moreover, the digit must be a + smaller number than the number of the operand that uses it in the + constraint. + + For operands to match in a particular case usually means that they + are identical-looking RTL expressions. But in a few special cases + specific kinds of dissimilarity are allowed. For example, `*x' as + an input operand will match `*x++' as an output operand. For + proper results in such cases, the output template should always + use the output-operand's number when printing the operand. + +`p' + An operand that is a valid memory address is allowed. This is for + "load address" and "push address" instructions. + + `p' in the constraint must be accompanied by `address_operand' as + the predicate in the `match_operand'. This predicate interprets + the mode specified in the `match_operand' as the mode of the memory + reference for which the address would be valid. + +`Q', `R', `S', ... `U' + Letters in the range `Q' through `U' may be defined in a + machine-dependent fashion to stand for arbitrary operand types. + The machine description macro `EXTRA_CONSTRAINT' is passed the + operand as its first argument and the constraint letter as its + second operand. + + A typical use for this would be to distinguish certain types of + memory references that affect other insn operands. + + Do not define these constraint letters to accept register + references (`reg'); the reload pass does not expect this and would + not handle it properly. + + In order to have valid assembler code, each operand must satisfy its +constraint. But a failure to do so does not prevent the pattern from +applying to an insn. Instead, it directs the compiler to modify the +code so that the constraint will be satisfied. Usually this is done by +copying an operand into a register. + + Contrast, therefore, the two instruction patterns that follow: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_dup 0) + (match_operand:SI 1 "general_operand" "r")))] + "" + "...") + +which has two operands, one of which must appear in two places, and + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_operand:SI 1 "general_operand" "0") + (match_operand:SI 2 "general_operand" "r")))] + "" + "...") + +which has three operands, two of which are required by a constraint to +be identical. If we are considering an insn of the form + + (insn N PREV NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 6) (reg:SI 109))) + ...) + +the first pattern would not apply at all, because this insn does not +contain two identical subexpressions in the right place. The pattern +would say, "That does not look like an add instruction; try other +patterns." The second pattern would say, "Yes, that's an add +instruction, but there is something wrong with it." It would direct +the reload pass of the compiler to generate additional insns to make +the constraint true. The results might look like this: + + (insn N2 PREV N + (set (reg:SI 3) (reg:SI 6)) + ...) + + (insn N N2 NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 3) (reg:SI 109))) + ...) + + It is up to you to make sure that each operand, in each pattern, has +constraints that can handle any RTL expression that could be present for +that operand. (When multiple alternatives are in use, each pattern +must, for each possible combination of operand expressions, have at +least one alternative which can handle that combination of operands.) +The constraints don't need to *allow* any possible operand--when this is +the case, they do not constrain--but they must at least point the way to +reloading any possible operand so that it will fit. + + * If the constraint accepts whatever operands the predicate permits, + there is no problem: reloading is never necessary for this operand. + + For example, an operand whose constraints permit everything except + registers is safe provided its predicate rejects registers. + + An operand whose predicate accepts only constant values is safe + provided its constraints include the letter `i'. If any possible + constant value is accepted, then nothing less than `i' will do; if + the predicate is more selective, then the constraints may also be + more selective. + + * Any operand expression can be reloaded by copying it into a + register. So if an operand's constraints allow some kind of + register, it is certain to be safe. It need not permit all + classes of registers; the compiler knows how to copy a register + into another register of the proper class in order to make an + instruction valid. + + * A nonoffsettable memory reference can be reloaded by copying the + address into a register. So if the constraint uses the letter + `o', all memory references are taken care of. + + * A constant operand can be reloaded by allocating space in memory to + hold it as preinitialized data. Then the memory reference can be + used in place of the constant. So if the constraint uses the + letters `o' or `m', constant operands are not a problem. + + * If the constraint permits a constant and a pseudo register used in + an insn was not allocated to a hard register and is equivalent to + a constant, the register will be replaced with the constant. If + the predicate does not permit a constant and the insn is + re-recognized for some reason, the compiler will crash. Thus the + predicate must always recognize any objects allowed by the + constraint. + + If the operand's predicate can recognize registers, but the +constraint does not permit them, it can make the compiler crash. When +this operand happens to be a register, the reload pass will be stymied, +because it does not know how to copy a register temporarily into memory.  -File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Machine Macros +File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints -Describing Relative Costs of Operations -======================================= +Multiple Alternative Constraints +-------------------------------- - These macros let you describe the relative speed of various -operations on the target machine. + Sometimes a single instruction has multiple alternative sets of +possible operands. For example, on the 68000, a logical-or instruction +can combine register or an immediate value into memory, or it can +combine any kind of operand into a register; but it cannot combine one +memory location into another. + + These constraints are represented as multiple alternatives. An +alternative can be described by a series of letters for each operand. +The overall constraint for an operand is made from the letters for this +operand from the first alternative, a comma, the letters for this +operand from the second alternative, a comma, and so on until the last +alternative. Here is how it is done for fullword logical-or on the +68000: + + (define_insn "iorsi3" + [(set (match_operand:SI 0 "general_operand" "=m,d") + (ior:SI (match_operand:SI 1 "general_operand" "%0,0") + (match_operand:SI 2 "general_operand" "dKs,dmKs")))] + ...) + + The first alternative has `m' (memory) for operand 0, `0' for +operand 1 (meaning it must match operand 0), and `dKs' for operand 2. +The second alternative has `d' (data register) for operand 0, `0' for +operand 1, and `dmKs' for operand 2. The `=' and `%' in the +constraints apply to all the alternatives; their meaning is explained +in the next section (*note Class Preferences::.). + + If all the operands fit any one alternative, the instruction is +valid. Otherwise, for each alternative, the compiler counts how many +instructions must be added to copy the operands so that that +alternative applies. The alternative requiring the least copying is +chosen. If two alternatives need the same amount of copying, the one +that comes first is chosen. These choices can be altered with the `?' +and `!' characters: + +`?' + Disparage slightly the alternative that the `?' appears in, as a + choice when no alternative applies exactly. The compiler regards + this alternative as one unit more costly for each `?' that appears + in it. + +`!' + Disparage severely the alternative that the `!' appears in. This + alternative can still be used if it fits without reloading, but if + reloading is needed, some other alternative will be used. + + When an insn pattern has multiple alternatives in its constraints, +often the appearance of the assembler code is determined mostly by which +alternative was matched. When this is so, the C code for writing the +assembler code can use the variable `which_alternative', which is the +ordinal number of the alternative that was actually satisfied (0 for +the first, 1 for the second alternative, etc.). *Note Output +Statement::. -`CONST_COSTS (X, CODE)' - A part of a C `switch' statement that describes the relative costs - of constant RTL expressions. It must contain `case' labels for - expression codes `const_int', `const', `symbol_ref', `label_ref' - and `const_double'. Each case must ultimately reach a `return' - statement to return the relative cost of the use of that kind of - constant value in an expression. The cost may depend on the - precise value of the constant, which is available for examination - in X. - - CODE is the expression code--redundant, since it can be obtained - with `GET_CODE (X)'. - -`RTX_COSTS (X, CODE)' - Like `CONST_COSTS' but applies to nonconstant RTL expressions. - This can be used, for example, to indicate how costly a multiply - instruction is. In writing this macro, you can use the construct - `COSTS_N_INSNS (N)' to specify a cost equal to N fast - instructions. + +File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints - This macro is optional; do not define it if the default cost - assumptions are adequate for the target machine. +Register Class Preferences +-------------------------- -`ADDRESS_COST (ADDRESS)' - An expression giving the cost of an addressing mode that contains - ADDRESS. If not defined, the cost is computed from the ADDRESS - expression and the `CONST_COSTS' values. - - For most CISC machines, the default cost is a good approximation - of the true cost of the addressing mode. However, on RISC - machines, all instructions normally have the same length and - execution time. Hence all addresses will have equal costs. - - In cases where more than one form of an address is known, the - form with the lowest cost will be used. If multiple forms have - the same, lowest, cost, the one that is the most complex will be - used. - - For example, suppose an address that is equal to the sum of a - register and a constant is used twice in the same basic block. - When this macro is not defined, the address will be computed in a - register and memory references will be indirect through that - register. On machines where the cost of the addressing mode - containing the sum is no higher than that of a simple indirect - reference, this will produce an additional instruction and - possibly require an additional register. Proper specification of - this macro eliminates this overhead for such machines. - - Similar use of this macro is made in strength reduction of loops. - - ADDRESS need not be valid as an address. In such a case, the cost - is not relevant and can be any value; invalid addresses need not - be assigned a different cost. - - On machines where an address involving more than one register is - as cheap as an address computation involving only one register, - defining `ADDRESS_COST' to reflect this can cause two registers - to be live over a region of code where only one would have been if - `ADDRESS_COST' were not defined in that manner. This effect - should be considered in the definition of this macro. Equivalent - costs should probably only be given to addresses with different - numbers of registers on machines with lots of registers. - - This macro will normally either not be defined or be defined as a - constant. - -`REGISTER_MOVE_COST (FROM, TO)' - A C expression for the cost of moving data from a register in - class FROM to one in class TO. The classes are expressed using - the enumeration values such as `GENERAL_REGS'. A value of 2 is - the default; other values are interpreted relative to that. - - It is not required that the cost always equal 2 when FROM is the - same as TO; on some machines it is expensive to move between - registers if they are not general registers. - - If reload sees an insn consisting of a single `set' between two - hard registers, and if `REGISTER_MOVE_COST' applied to their - classes returns a value of 2, reload does not check to ensure - that the constraints of the insn are met. Setting a cost of - other than 2 will allow reload to verify that the constraints are - met. You should do this if the `movM' pattern's constraints do - not allow such copying. - -`MEMORY_MOVE_COST (M)' - A C expression for the cost of moving data of mode M between a - register and memory. A value of 2 is the default; this cost is - relative to those in `REGISTER_MOVE_COST'. - - If moving between registers and memory is more expensive than - between two registers, you should define this macro to express - the relative cost. - -`BRANCH_COST' - A C expression for the cost of a branch instruction. A value of - 1 is the default; other values are interpreted relative to that. - - Here are additional macros which do not specify precise relative -costs, but only that certain actions are more expensive than GNU CC -would ordinarily expect. - -`SLOW_BYTE_ACCESS' - Define this macro as a C expression which is nonzero if accessing - less than a word of memory (i.e. a `char' or a `short') is no - faster than accessing a word of memory, i.e., if such access - require more than one instruction or if there is no difference in - cost between byte and (aligned) word loads. - - When this macro is not defined, the compiler will access a field - by finding the smallest containing object; when it is defined, a - fullword load will be used if alignment permits. Unless bytes - accesses are faster than word accesses, using word accesses is - preferable since it may eliminate subsequent memory access if - subsequent accesses occur to other fields in the same word of the - structure, but to different bytes. - -`SLOW_ZERO_EXTEND' - Define this macro if zero-extension (of a `char' or `short' to an - `int') can be done faster if the destination is a register that - is known to be zero. - - If you define this macro, you must have instruction patterns that - recognize RTL structures like this: - - (set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...) - - and likewise for `HImode'. - -`SLOW_UNALIGNED_ACCESS' - Define this macro if unaligned accesses have a cost many times - greater than aligned accesses, for example if they are emulated - in a trap handler. - - When this macro is defined, the compiler will act as if - `STRICT_ALIGNMENT' were defined when generating code for block - moves. This can cause significantly more instructions to be - produced. Therefore, do not define this macro if unaligned - accesses only add a cycle or two to the time for a memory access. - -`DONT_REDUCE_ADDR' - Define this macro to inhibit strength reduction of memory - addresses. (On some machines, such strength reduction seems to - do harm rather than good.) - -`MOVE_RATIO' - The number of scalar move insns which should be generated instead - of a string move insn or a library call. Increasing the value - will always make code faster, but eventually incurs high cost in - increased code size. - - If you don't define this, a reasonable default is used. - -`NO_FUNCTION_CSE' - Define this macro if it is as good or better to call a constant - function address than to call an address kept in a register. - -`NO_RECURSIVE_FUNCTION_CSE' - Define this macro if it is as good or better for a function to - call itself with an explicit address than to call an address kept - in a register. + The operand constraints have another function: they enable the +compiler to decide which kind of hardware register a pseudo register is +best allocated to. The compiler examines the constraints that apply to +the insns that use the pseudo register, looking for the +machine-dependent letters such as `d' and `a' that specify classes of +registers. The pseudo register is put in whichever class gets the most +"votes". The constraint letters `g' and `r' also vote: they vote in +favor of a general register. The machine description says which +registers are considered general. + + Of course, on some machines all registers are equivalent, and no +register classes are defined. Then none of this complexity is relevant.  -File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Machine Macros +File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints -Dividing the Output into Sections (Texts, Data, ...) -==================================================== +Constraint Modifier Characters +------------------------------ - An object file is divided into sections containing different types -of data. In the most common case, there are three sections: the "text -section", which holds instructions and read-only data; the "data -section", which holds initialized writable data; and the "bss -section", which holds uninitialized data. Some systems have other -kinds of sections. - - The compiler must tell the assembler when to switch sections. These -macros control what commands to output to tell the assembler this. You -can also define additional sections. - -`TEXT_SECTION_ASM_OP' - A C string constant for the assembler operation that should - precede instructions and read-only data. Normally `".text"' is - right. - -`DATA_SECTION_ASM_OP' - A C string constant for the assembler operation to identify the - following data as writable initialized data. Normally `".data"' - is right. - -`SHARED_SECTION_ASM_OP' - If defined, a C string constant for the assembler operation to - identify the following data as shared data. If not defined, - `DATA_SECTION_ASM_OP' will be used. - -`INIT_SECTION_ASM_OP' - If defined, a C string constant for the assembler operation to - identify the following data as initialization code. If not - defined, GNU CC will assume such a section does not exist. - -`EXTRA_SECTIONS' - A list of names for sections other than the standard two, which - are `in_text' and `in_data'. You need not define this macro on a - system with no other sections (that GCC needs to use). - -`EXTRA_SECTION_FUNCTIONS' - One or more functions to be defined in `varasm.c'. These - functions should do jobs analogous to those of `text_section' and - `data_section', for your additional sections. Do not define this - macro if you do not define `EXTRA_SECTIONS'. - -`READONLY_DATA_SECTION' - On most machines, read-only variables, constants, and jump tables - are placed in the text section. If this is not the case on your - machine, this macro should be defined to be the name of a - function (either `data_section' or a function defined in - `EXTRA_SECTIONS') that switches to the section to be used for - read-only items. - - If these items should be placed in the text section, this macro - should not be defined. - -`SELECT_SECTION (EXP, RELOC)' - A C statement or statements to switch to the appropriate section - for output of EXP. You can assume that EXP is either a - `VAR_DECL' node or a constant of some sort. RELOC indicates - whether the initial value of EXP requires link-time relocations. - Select the section by calling `text_section' or one of the - alternatives for other sections. - - Do not define this macro if you put all read-only variables and - constants in the read-only data section (usually the text - section). - -`SELECT_RTX_SECTION (MODE, RTX)' - A C statement or statements to switch to the appropriate section - for output of RTX in mode MODE. You can assume that RTX is some - kind of constant in RTL. The argument MODE is redundant except - in the case of a `const_int' rtx. Select the section by calling - `text_section' or one of the alternatives for other sections. - - Do not define this macro if you put all constants in the read-only - data section. - -`JUMP_TABLES_IN_TEXT_SECTION' - Define this macro if jump tables (for `tablejump' insns) should be - output in the text section, along with the assembler instructions. - Otherwise, the readonly data section is used. - - This macro is irrelevant if there is no separate readonly data - section. - -`ENCODE_SECTION_INFO (DECL)' - Define this macro if references to a symbol must be treated - differently depending on something about the variable or function - named by the symbol (such as what section it is in). - - The macro definition, if any, is executed immediately after the - rtl for DECL has been created and stored in `DECL_RTL (DECL)'. - The value of the rtl will be a `mem' whose address is a - `symbol_ref'. - - The usual thing for this macro to do is to record a flag in the - `symbol_ref' (such as `SYMBOL_REF_FLAG') or to store a modified - name string in the `symbol_ref' (if one bit is not enough - information). +`=' + Means that this operand is write-only for this instruction: the + previous value is discarded and replaced by output data. + +`+' + Means that this operand is both read and written by the + instruction. + + When the compiler fixes up the operands to satisfy the constraints, + it needs to know which operands are inputs to the instruction and + which are outputs from it. `=' identifies an output; `+' + identifies an operand that is both input and output; all other + operands are assumed to be input only. + +`&' + Means (in a particular alternative) that this operand is written + before the instruction is finished using the input operands. + Therefore, this operand may not lie in a register that is used as + an input operand or as part of any memory address. + + `&' applies only to the alternative in which it is written. In + constraints with multiple alternatives, sometimes one alternative + requires `&' while others do not. See, for example, the `movdf' + insn of the 68000. + + `&' does not obviate the need to write `='. + +`%' + Declares the instruction to be commutative for this operand and the + following operand. This means that the compiler may interchange + the two operands if that is the cheapest way to make all operands + fit the constraints. This is often used in patterns for addition + instructions that really have only two operands: the result must + go in one of the arguments. Here for example, is how the 68000 + halfword-add instruction is defined: + + (define_insn "addhi3" + [(set (match_operand:HI 0 "general_operand" "=m,r") + (plus:HI (match_operand:HI 1 "general_operand" "%0,0") + (match_operand:HI 2 "general_operand" "di,g")))] + ...) + +`#' + Says that all following characters, up to the next comma, are to be + ignored as a constraint. They are significant only for choosing + register preferences. + +`*' + Says that the following character should be ignored when choosing + register preferences. `*' has no effect on the meaning of the + constraint as a constraint, and no effect on reloading. + + Here is an example: the 68000 has an instruction to sign-extend a + halfword in a data register, and can also sign-extend a value by + copying it into an address register. While either kind of + register is acceptable, the constraints on an address-register + destination are less strict, so it is best if register allocation + makes an address register its goal. Therefore, `*' is used so + that the `d' constraint letter (for data register) is ignored when + computing register preferences. + + (define_insn "extendhisi2" + [(set (match_operand:SI 0 "general_operand" "=*d,a") + (sign_extend:SI + (match_operand:HI 1 "general_operand" "0,g")))] + ...)  -File: gcc.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Machine Macros +File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints -Position Independent Code -========================= +Constraints for Particular Machines +----------------------------------- - This section describes macros that help implement generation of -position independent code. Simply defining these macros is not enough -to generate valid PIC; you must also add support to the macros -`GO_IF_LEGITIMATE_ADDRESS' and `LEGITIMIZE_ADDRESS', and -`PRINT_OPERAND_ADDRESS' as well. You must modify the definition of -`movsi' to do something appropriate when the source operand contains a -symbolic address. You may also need to alter the handling of switch -statements so that they use relative addresses. - -`PIC_OFFSET_TABLE_REGNUM' - The register number of the register used to address a table of - static data addresses in memory. In some cases this register is - defined by a processor's "application binary interface" (ABI). - When this macro is defined, RTL is generated for this register - once, as with the stack pointer and frame pointer registers. If - this macro is not defined, it is up to the machine-dependent - files to allocate such a register (if necessary). - -`FINALIZE_PIC' - By generating position-independent code, when two different - programs (A and B) share a common library (libC.a), the text of - the library can be shared whether or not the library is linked at - the same address for both programs. In some of these - environments, position-independent code requires not only the use - of different addressing modes, but also special code to enable - the use of these addressing modes. - - The `FINALIZE_PIC' macro serves as a hook to emit these special - codes once the function is being compiled into assembly code, but - not before. (It is not done before, because in the case of - compiling an inline function, it would lead to multiple PIC - prologues being included in functions which used inline functions - and were compiled to assembly language.) + Whenever possible, you should use the general-purpose constraint +letters in `asm' arguments, since they will convey meaning more readily +to people reading your code. Failing that, use the constraint letters +that usually have very similar meanings across architectures. The most +commonly used constraints are `m' and `r' (for memory and +general-purpose registers respectively; *note Simple Constraints::.), +and `I', usually the letter indicating the most common +immediate-constant format. - -File: gcc.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Machine Macros + For each machine architecture, the `config/MACHINE.h' file defines +additional constraints. These constraints are used by the compiler +itself for instruction generation, as well as for `asm' statements; +therefore, some of the constraints are not particularly interesting for +`asm'. The constraints are defined through these macros: -Defining the Output Assembler Language -====================================== +`REG_CLASS_FROM_LETTER' + Register class constraints (usually lower case). - This section describes macros whose principal purpose is to -describe how to write instructions in assembler language--rather than -what the instructions do. +`CONST_OK_FOR_LETTER_P' + Immediate constant constraints, for non-floating point constants of + word size or smaller precision (usually upper case). -* Menu: +`CONST_DOUBLE_OK_FOR_LETTER_P' + Immediate constant constraints, for all floating point constants + and for constants of greater than word size precision (usually + upper case). -* File Framework:: Structural information for the assembler file. -* Data Output:: Output of constants (numbers, strings, addresses). -* Uninitialized Data:: Output of uninitialized variables. -* Label Output:: Output and generation of labels. -* Constructor Output:: Output of initialization and termination routines. -* Instruction Output:: Output of actual instructions. -* Dispatch Tables:: Output of jump tables. -* Alignment Output:: Pseudo ops for alignment and skipping data. +`EXTRA_CONSTRAINT' + Special cases of registers or memory. This macro is not required, + and is only defined for some machines. - -File: gcc.info, Node: File Framework, Next: Data Output, Prev: Assembler Format, Up: Assembler Format + Inspecting these macro definitions in the compiler source for your +machine is the best way to be certain you have the right constraints. +However, here is a summary of the machine-dependent constraints +available on some particular machines. -The Overall Framework of an Assembler File ------------------------------------------- +*AMD 29000 family--`a29k.h'* + `l' + Local register 0 -`ASM_FILE_START (STREAM)' - A C expression which outputs to the stdio stream STREAM some - appropriate text to go at the start of an assembler file. - - Normally this macro is defined to output a line containing - `#NO_APP', which is a comment that has no effect on most - assemblers but tells the GNU assembler that it can save time by - not checking for certain assembler constructs. - - On systems that use SDB, it is necessary to output certain - commands; see `attasm.h'. - -`ASM_FILE_END (STREAM)' - A C expression which outputs to the stdio stream STREAM some - appropriate text to go at the end of an assembler file. - - If this macro is not defined, the default is to output nothing - special at the end of the file. Most systems don't require any - definition. - - On systems that use SDB, it is necessary to output certain - commands; see `attasm.h'. - -`ASM_IDENTIFY_GCC (FILE)' - A C statement to output assembler commands which will identify - the object file as having been compiled with GNU CC (or another - GNU compiler). - - If you don't define this macro, the string `gcc_compiled.:' is - output. This string is calculated to define a symbol which, on - BSD systems, will never be defined for any other reason. GDB - checks for the presence of this symbol when reading the symbol - table of an executable. - - On non-BSD systems, you must arrange communication with GDB in - some other fashion. If GDB is not used on your system, you can - define this macro with an empty body. - -`ASM_COMMENT_START' - A C string constant describing how to begin a comment in the - target assembler language. The compiler assumes that the comment - will end at the end of the line. - -`ASM_APP_ON' - A C string constant for text to be output before each `asm' - statement or group of consecutive ones. Normally this is - `"#APP"', which is a comment that has no effect on most - assemblers but tells the GNU assembler that it must check the - lines that follow for all valid assembler constructs. - -`ASM_APP_OFF' - A C string constant for text to be output after each `asm' - statement or group of consecutive ones. Normally this is - `"#NO_APP"', which tells the GNU assembler to resume making the - time-saving assumptions that are valid for ordinary compiler - output. - -`ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output COFF information or DWARF debugging - information which indicates that filename NAME is the current - source file to the stdio stream STREAM. - - This macro need not be defined if the standard form of output for - the file format in use is appropriate. - -`ASM_OUTPUT_SOURCE_LINE (STREAM, LINE)' - A C statement to output DBX or SDB debugging information before - code for line number LINE of the current source file to the stdio - stream STREAM. - - This macro need not be defined if the standard form of debugging - information for the debugger in use is appropriate. - -`ASM_OUTPUT_IDENT (STREAM, STRING)' - A C statement to output something to the assembler file to handle - a `#ident' directive containing the text STRING. If this macro - is not defined, nothing is output for a `#ident' directive. - -`OBJC_PROLOGUE' - A C statement to output any assembler statements which are - required to precede any Objective C object definitions or message - sending. The statement is executed only when compiling an - Objective C program. + `b' + Byte Pointer (`BP') register - -File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format + `q' + `Q' register + + `h' + Special purpose register + + `A' + First accumulator register + + `a' + Other accumulator register + + `f' + Floating point register + + `I' + Constant greater than 0, less than 0x100 + + `J' + Constant greater than 0, less than 0x10000 + + `K' + Constant whose high 24 bits are on (1) + + `L' + 16 bit constant whose high 8 bits are on (1) + + `M' + 32 bit constant whose high 16 bits are on (1) + + `N' + 32 bit negative constant that fits in 8 bits + + `O' + The constant 0x80000000 or, on the 29050, any 32 bit constant + whose low 16 bits are 0. + + `P' + 16 bit negative constant that fits in 8 bits + + `G' + `H' + A floating point constant (in `asm' statements, use the + machine independent `E' or `F' instead) + +*IBM RS6000--`rs6000.h'* + `b' + Address base register + + `f' + Floating point register + + `h' + `MQ', `CTR', or `LINK' register + + `q' + `MQ' register + + `c' + `CTR' register + + `l' + `LINK' register + + `x' + `CR' register (condition register) number 0 + + `y' + `CR' register (condition register) + + `I' + Signed 16 bit constant + + `J' + Constant whose low 16 bits are 0 + + `K' + Constant whose high 16 bits are 0 + + `L' + Constant suitable as a mask operand + + `M' + Constant larger than 31 + + `N' + Exact power of 2 + + `O' + Zero + + `P' + Constant whose negation is a signed 16 bit constant + + `G' + Floating point constant that can be loaded into a register + with one instruction per word + + `Q' + Memory operand that is an offset from a register (`m' is + preferable for `asm' statements) + +*Intel 386--`i386.h'* + `q' + `a', `b', `c', or `d' register + + `f' + Floating point register + + `t' + First (top of stack) floating point register + + `u' + Second floating point register + + `a' + `a' register + + `b' + `b' register + + `c' + `c' register + + `d' + `d' register + + `D' + `di' register + + `S' + `si' register + + `I' + Constant in range 0 to 31 (for 32 bit shifts) + + `J' + Constant in range 0 to 63 (for 64 bit shifts) -Output of Data --------------- + `K' + `0xff' + + `L' + `0xffff' + + `M' + 0, 1, 2, or 3 (shifts for `lea' instruction) + + `G' + Standard 80387 floating point constant + +*Intel 960--`i960.h'* + `f' + Floating point register (`fp0' to `fp3') + + `l' + Local register (`r0' to `r15') + + `b' + Global register (`g0' to `g15') + + `d' + Any local or global register + + `I' + Integers from 0 to 31 + + `J' + 0 + + `K' + Integers from -31 to 0 + + `G' + Floating point 0 + + `H' + Floating point 1 + +*MIPS--`mips.h'* + `d' + General-purpose integer register + + `f' + Floating-point register (if available) + + `h' + `Hi' register + + `l' + `Lo' register + + `x' + `Hi' or `Lo' register + + `y' + General-purpose integer register + + `z' + Floating-point status register + + `I' + Signed 16 bit constant (for arithmetic instructions) + + `J' + Zero + + `K' + Zero-extended 16-bit constant (for logic instructions) + + `L' + Constant with low 16 bits zero (can be loaded with `lui') + + `M' + 32 bit constant which requires two instructions to load (a + constant which is not `I', `K', or `L') + + `N' + Negative 16 bit constant + + `O' + Exact power of two + + `P' + Positive 16 bit constant + + `G' + Floating point zero + + `Q' + Memory reference that can be loaded with more than one + instruction (`m' is preferable for `asm' statements) + + `R' + Memory reference that can be loaded with one instruction (`m' + is preferable for `asm' statements) + + `S' + Memory reference in external OSF/rose PIC format (`m' is + preferable for `asm' statements) + +*Motorola 680x0--`m68k.h'* + `a' + Address register + + `d' + Data register + + `f' + 68881 floating-point register, if available + + `x' + Sun FPA (floating-point) register, if available + + `y' + First 16 Sun FPA registers, if available + + `I' + Integer in the range 1 to 8 + + `J' + 16 bit signed number + + `K' + Signed number whose magnitude is greater than 0x80 + + `L' + Integer in the range -8 to -1 + + `G' + Floating point constant that is not a 68881 constant + + `H' + Floating point constant that can be used by Sun FPA + +*SPARC--`sparc.h'* + `f' + Floating-point register + + `I' + Signed 13 bit constant + + `J' + Zero + + `K' + 32 bit constant with the low 12 bits clear (a constant that + can be loaded with the `sethi' instruction) + + `G' + Floating-point zero + + `H' + Signed 13 bit constant, sign-extended to 32 or 64 bits + + `Q' + Memory reference that can be loaded with one instruction + (`m' is more appropriate for `asm' statements) + + `S' + Constant, or memory address + + `T' + Memory address aligned to an 8-byte boundary + + `U' + Even register + + +File: gcc.info, Node: No Constraints, Prev: Machine Constraints, Up: Constraints -`ASM_OUTPUT_LONG_DOUBLE (STREAM, VALUE)' -`ASM_OUTPUT_DOUBLE (STREAM, VALUE)' -`ASM_OUTPUT_FLOAT (STREAM, VALUE)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a floating-point constant of `TFmode', - `DFmode' or `SFmode', respectively, whose value is VALUE. VALUE - will be a C expression of type `REAL_VALUE__TYPE', usually - `double'. - -`ASM_OUTPUT_QUADRUPLE_INT (STREAM, EXP)' -`ASM_OUTPUT_DOUBLE_INT (STREAM, EXP)' -`ASM_OUTPUT_INT (STREAM, EXP)' -`ASM_OUTPUT_SHORT (STREAM, EXP)' -`ASM_OUTPUT_CHAR (STREAM, EXP)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble an integer of 16, 8, 4, 2 or 1 bytes, - respectively, whose value is VALUE. The argument EXP will be an - RTL expression which represents a constant value. Use - `output_addr_const (STREAM, EXP)' to output this value as an - assembler expression. - - For sizes larger than `UNITS_PER_WORD', if the action of a macro - would be identical to repeatedly calling the macro corresponding - to a size of `UNITS_PER_WORD', once for each word, you need not - define the macro. - -`ASM_OUTPUT_BYTE (STREAM, VALUE)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a single byte containing the number VALUE. - -`ASM_BYTE_OP' - A C string constant giving the pseudo-op to use for a sequence of - single-byte constants. If this macro is not defined, the default - is `"byte"'. - -`ASM_OUTPUT_ASCII (STREAM, PTR, LEN)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a string constant containing the LEN - bytes at PTR. PTR will be a C expression of type `char *' and - LEN a C expression of type `int'. - - If the assembler has a `.ascii' pseudo-op as found in the - Berkeley Unix assembler, do not define the macro - `ASM_OUTPUT_ASCII'. - -`ASM_OUTPUT_POOL_PROLOGUE (FILE FUNNAME FUNDECL SIZE)' - A C statement to output assembler commands to define the start of - the constant pool for a function. FUNNAME is a string giving the - name of the function. Should the return type of the function be - required, it can be obtained via FUNDECL. SIZE is the size, in - bytes, of the constant pool that will be written immediately - after this call. - - If no constant-pool prefix is required, the usual case, this - macro need not be defined. - -`ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, JUMPTO)' - A C statement (with or without semicolon) to output a constant in - the constant pool, if it needs special treatment. (This macro - need not do anything for RTL expressions that can be output - normally.) - - The argument FILE is the standard I/O stream to output the - assembler code on. X is the RTL expression for the constant to - output, and MODE is the machine mode (in case X is a - `const_int'). ALIGN is the required alignment for the value X; - you should output an assembler directive to force this much - alignment. - - The argument LABELNO is a number to use in an internal label for - the address of this pool entry. The definition of this macro is - responsible for outputting the label definition at the proper - place. Here is how to do this: - - ASM_OUTPUT_INTERNAL_LABEL (FILE, "LC", LABELNO); - - When you output a pool entry specially, you should end with a - `goto' to the label JUMPTO. This will prevent the same pool - entry from being output a second time in the usual manner. - - You need not define this macro if it would do nothing. - -`ASM_OPEN_PAREN' -`ASM_CLOSE_PAREN' - These macros are defined as C string constant, describing the - syntax in the assembler for grouping arithmetic expressions. The - following definitions are correct for most assemblers: +Not Using Constraints +--------------------- - #define ASM_OPEN_PAREN "(" - #define ASM_CLOSE_PAREN ")" + Some machines are so clean that operand constraints are not +required. For example, on the Vax, an operand valid in one context is +valid in any other context. On such a machine, every operand +constraint would be `g', excepting only operands of "load address" +instructions which are written as if they referred to a memory +location's contents but actual refer to its address. They would have +constraint `p'. + + For such machines, instead of writing `g' and `p' for all the +constraints, you can choose to write a description with empty +constraints. Then you write `""' for the constraint in every +`match_operand'. Address operands are identified by writing an +`address' expression around the `match_operand', not by their +constraints. + + When the machine description has just empty constraints, certain +parts of compilation are skipped, making the compiler faster. However, +few machines actually do not need constraints; all machine descriptions +now in existence use constraints. - \ No newline at end of file