--- gcc/gcc.info-14 2018/04/24 17:51:49 1.1.1.2 +++ gcc/gcc.info-14 2018/04/24 18:10:46 1.1.1.6 @@ -1,940 +1,939 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 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: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling +File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc + +C Statements for Assembler Output +================================= -Function Entry and Exit ------------------------ + 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") - This section describes the macros that output function entry -("prologue") and exit ("epilogue") code. + +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc -`FUNCTION_PROLOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for entry - to a function. The prologue is responsible for setting up the - stack frame, initializing the frame pointer register, saving - registers that must be saved, and allocating SIZE additional - bytes of storage for the local variables. SIZE is an integer. - FILE is a stdio stream to which the assembler code should be - output. - - The label for the beginning of the function need not be output by - this macro. That has already been done when the macro is run. - - To determine which registers to save, the macro can refer to the - array `regs_ever_live': element R is nonzero if hard register R - is used anywhere within the function. This implies the function - prologue should save register R, provided it is not one of the - call-used registers. (`FUNCTION_EPILOGUE' must likewise use - `regs_ever_live'.) - - On machines that have "register windows", the function entry code - does not save on the stack the registers that are in the windows, - even if they are supposed to be preserved by function calls; - instead it takes appropriate steps to "push" the register stack, - if any non-call-used registers are used in the function. - - On machines where functions may or may not have frame-pointers, - the function entry code must vary accordingly; it must set up the - frame pointer if one is wanted, and not otherwise. To determine - whether a frame pointer is in wanted, the macro can refer to the - variable `frame_pointer_needed'. The variable's value will be 1 - at run time in a function that needs a frame pointer. *Note - Elimination::. - - The function entry code is responsible for allocating any stack - space required for the function. This stack space consists of - the regions listed below. In most cases, these regions are - allocated in the order listed, with the last listed region - closest to the top of the stack (the lowest address if - `STACK_GROWS_DOWNWARD' is defined, and the highest address if it - is not defined). You can use a different order for a machine if - doing so is more convenient or required for compatibility - reasons. Except in cases where required by standard or by a - debugger, there is no reason why the stack layout used by GCC - need agree with that used by other compilers for a machine. - - * A region of `current_function_pretend_args_size' bytes of - uninitialized space just underneath the first argument - arriving on the stack. (This may not be at the very start - of the allocated stack region if the calling sequence has - pushed anything else since pushing the stack arguments. But - usually, on such machines, nothing else has been pushed yet, - because the function prologue itself does all the pushing.) - This region is used on machines where an argument may be - passed partly in registers and partly in memory, and, in - some cases to support the features in `varargs.h' and - `stdargs.h'. - - * An area of memory used to save certain registers used by the - function. The size of this area, which may also include - space for such things as the return address and pointers to - previous stack frames, is machine-specific and usually - depends on which registers have been used in the function. - Machines with register windows often do not require a save - area. - - * A region of at least SIZE bytes, possibly rounded up to an - allocation boundary, to contain the local variables of the - function. On some machines, this region and the save area - may occur in the opposite order, with the save area closer - to the top of the stack. - - * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is - defined, a region of `current_function_outgoing_args_size' - bytes to be used for outgoing argument lists of the - function. *Note Stack Arguments::. - - Normally, it is necessary for `FUNCTION_PROLOGUE' and - `FUNCTION_EPILOGUE' to treat leaf functions specially. The C - variable `leaf_function' is nonzero for such a function. - -`EXIT_IGNORE_STACK' - Define this macro as a C expression that is nonzero if the return - instruction or the function epilogue ignores the value of the - stack pointer; in other words, if it is safe to delete an - instruction to adjust the stack pointer before a return from the - function. - - Note that this macro's value is relevant only for functions for - which frame pointers are maintained. It is never safe to delete - a final stack adjustment in a function that has no frame pointer, - and the compiler knows this regardless of `EXIT_IGNORE_STACK'. - -`FUNCTION_EPILOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for exit - from a function. The epilogue is responsible for restoring the - saved registers and stack pointer to their values when the - function was called, and returning control to the caller. This - macro takes the same arguments as the macro `FUNCTION_PROLOGUE', - and the registers to restore are determined from `regs_ever_live' - and `CALL_USED_REGISTERS' in the same way. - - On some machines, there is a single instruction that does all the - work of returning from the function. On these machines, give that - instruction the name `return' and do not define the macro - `FUNCTION_EPILOGUE' at all. - - Do not define a pattern named `return' if you want the - `FUNCTION_EPILOGUE' to be used. If you want the target switches - to control whether return instructions or epilogues are used, - define a `return' pattern with a validity condition that tests - the target switches appropriately. If the `return' pattern's - validity condition is false, epilogues will be used. - - On machines where functions may or may not have frame-pointers, - the function exit code must vary accordingly. Sometimes the code - for these two cases is completely different. To determine - whether a frame pointer is in wanted, the macro can refer to the - variable `frame_pointer_needed'. The variable's value will be 1 - at run time in a function that needs a frame pointer. - - Normally, it is necessary for `FUNCTION_PROLOGUE' and - `FUNCTION_EPILOGUE' to treat leaf functions specially. The C - variable `leaf_function' is nonzero for such a function. *Note - Leaf Functions::. - - On some machines, some functions pop their arguments on exit while - others leave that for the caller to do. For example, the 68020 - when given `-mrtd' pops arguments in functions that take a fixed - number of arguments. - - Your definition of the macro `RETURN_POPS_ARGS' decides which - functions pop their own arguments. `FUNCTION_EPILOGUE' needs to - know what was decided. The variable `current_function_pops_args' - is the number of bytes of its arguments that a function should - pop. *Note Scalar Return::. - -`DELAY_SLOTS_FOR_EPILOGUE' - Define this macro if the function epilogue contains delay slots - to which instructions from the rest of the function can be - "moved". The definition should be a C expression whose value is - an integer representing the number of delay slots there. - -`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' - A C expression that returns 1 if INSN can be placed in delay slot - number N of the epilogue. - - The argument N is an integer which identifies the delay slot now - being considered (since different slots may have different rules - of eligibility). It is never negative and is always less than - the number of epilogue delay slots (what - `DELAY_SLOTS_FOR_EPILOGUE' returns). If you reject a particular - insn for a given delay slot, in principle, it may be reconsidered - for a subsequent delay slot. Also, other insns may (at least in - principle) be considered for the so far unfilled delay slot. - - The insns accepted to fill the epilogue delay slots are put in an - RTL list made with `insn_list' objects, stored in the variable - `current_function_epilogue_delay_list'. The insn for the first - delay slot comes first in the list. Your definition of the macro - `FUNCTION_EPILOGUE' should fill the delay slots by outputting the - insns in this list, usually by calling `final_scan_insn'. +Operand Constraints +=================== - You need not define this macro if you did not define - `DELAY_SLOTS_FOR_EPILOGUE'. + 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. + +* Menu: + +* 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: Profiling, Prev: Function Entry, Up: Stack and Calling +File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints -Generating Code for Profiling ------------------------------ +Simple Constraints +------------------ -`FUNCTION_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to call the profiling subroutine `mcount'. Before - calling, the assembler code must load the address of a counter - variable into a register where `mcount' expects to find the - address. The name of this variable is `LP' followed by the - number LABELNO, so you would generate the name using `LP%d' in a - `fprintf'. - - The details of how the address should be passed to `mcount' are - determined by your operating system environment, not by GNU CC. - To figure them out, compile a small program for profiling using - the system's installed C compiler and look at the assembler code - that results. - -`PROFILE_BEFORE_PROLOGUE' - Define this macro if the code for function profiling should come - before the function prologue. Normally, the profiling code comes - after. - -`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to initialize basic-block profiling for the current - object module. This code should call the subroutine - `__bb_init_func' once per object module, passing it as its sole - argument the address of a block allocated in the object module. - - The name of the block is a local symbol made with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. - - The first word of this block is a flag which will be nonzero if - the object module has already been initialized. So test this - word first, and do not call `__bb_init_func' if the flag is - nonzero. - -`BLOCK_PROFILER (FILE, BLOCKNO)' - A C statement or compound statement to increment the count - associated with the basic block number BLOCKNO. Basic blocks are - numbered separately from zero within each compilation. The count - associated with block number BLOCKNO is at index BLOCKNO in a - vector of words; the name of this array is a local symbol made - with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. + 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. + +`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: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros +File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints -Implementing the Varargs Macros -=============================== +Multiple Alternative Constraints +-------------------------------- - GNU CC comes with an implementation of `varargs.h' and `stdarg.h' -that work without change on machines that pass arguments on the stack. - Other machines require their own implementations of varargs, and the -two machine independent header files must have conditionals to include -it. - - ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the -calling convention for `va_start'. The traditional implementation -takes just one argument, which is the variable in which to store the -argument pointer. The ANSI implementation takes an additional first -argument, which is the last named argument of the function. However, -it should not use this argument. The way to find the end of the named -arguments is with the built-in functions described below. - -`__builtin_saveregs ()' - Use this built-in function to save the argument registers in - memory so that the varargs mechanism can access them. Both ANSI - and traditional versions of `va_start' must use - `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' - (see below) instead. - - On some machines, `__builtin_saveregs' is open-coded under the - control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other - machines, it calls a routine written in assembler language, found - in `libgcc2.c'. - - Regardless of what code is generated for the call to - `__builtin_saveregs', it appears at the beginning of the function, - not where the call to `__builtin_saveregs' is written. This is - because the registers must be saved before the function starts to - use them for its own purposes. - -`__builtin_args_info (CATEGORY)' - Use this built-in function to find the first anonymous arguments - in registers. - - In general, a machine may have several categories of registers - used for arguments, each for a particular category of data types. - (For example, on some machines, floating-point registers are - used for floating-point arguments while other arguments are - passed in the general registers.) To make non-varargs functions - use the proper calling convention, you have defined the - `CUMULATIVE_ARGS' data type to record how many registers in each - category have been used so far - - `__builtin_args_info' accesses the same data structure of type - `CUMULATIVE_ARGS' after the ordinary argument layout is finished - with it, with CATEGORY specifying which word to access. Thus, the - value indicates the first unused register in a given category. - - Normally, you would use `__builtin_args_info' in the - implementation of `va_start', accessing each category just once - and storing the value in the `va_list' object. This is because - `va_list' will have to update the values, and there is no way to - alter the values accessed by `__builtin_args_info'. - -`__builtin_next_arg ()' - This is the equivalent of `__builtin_args_info', for stack - arguments. It returns the address of the first anonymous stack - argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns - the address of the location above the first anonymous stack - argument. Use it in `va_start' to initialize the pointer for - fetching arguments from the stack. - -`__builtin_classify_type (OBJECT)' - Since each machine has its own conventions for which data types - are passed in which kind of register, your implementation of - `va_arg' has to embody these conventions. The easiest way to - categorize the specified data type is to use - `__builtin_classify_type' together with `sizeof' and - `__alignof__'. - - `__builtin_classify_type' ignores the value of OBJECT, - considering only its data type. It returns an integer describing - what kind of type that is--integer, floating, pointer, structure, - and so on. - - The file `typeclass.h' defines an enumeration that you can use to - interpret the values of `__builtin_classify_type'. - - These machine description macros help implement varargs: - -`EXPAND_BUILTIN_SAVEREGS (ARGS)' - If defined, is a C expression that produces the machine-specific - code for a call to `__builtin_saveregs'. This code will be moved - to the very beginning of the function, before any parameter - access are made. The return value of this function should be an - RTX that contains the value to use as the return of - `__builtin_saveregs'. - - The argument ARGS is a `tree_list' containing the arguments that - were passed to `__builtin_saveregs'. - - If this macro is not defined, the compiler will output an ordinary - call to the library function `__builtin_saveregs'. - -`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)' - This macro offers an alternative to using `__builtin_saveregs' and - defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the - anonymous register arguments into the stack so that all the - arguments appear to have been passed consecutively on the stack. - Once this is done, you can use the standard implementation of - varargs that works for machines that pass all their arguments on - the stack. - - The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, - containing the values that obtain after processing of the named - arguments. The arguments MODE and TYPE describe the last named - argument--its machine mode and its data type as a tree node. - - The macro implementation should do two things: first, push onto - the stack all the argument registers *not* used for the named - arguments, and second, store the size of the data thus pushed - into the `int'-valued variable whose name is supplied as the - argument PRETEND_ARGS_SIZE. The value that you store here will - serve as additional offset for setting up the stack frame. - - Because you must generate code to push the anonymous arguments at - compile time without knowing their data types, - `SETUP_INCOMING_VARARGS' is only useful on machines that have just - a single category of argument register and use it uniformly for - all data types. - - If the argument SECOND_TIME is nonzero, it means that the - arguments of the function are being analyzed for the second time. - This happens for an inline function, which is not actually - compiled until the end of the source file. The macro - `SETUP_INCOMING_VARARGS' should not generate any instructions in - this case. + 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::.  -File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros +File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints + +Register Class Preferences +-------------------------- -Trampolines for Nested Functions -================================ + 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. - 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. + 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: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros +File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints -Implicit Calls to Library Routines -================================== +Constraint Modifier Characters +------------------------------ -`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. +`=' + 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: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros +File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints -Addressing Modes -================ +Constraints for Particular Machines +----------------------------------- -`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. + 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: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target 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: + +`REG_CLASS_FROM_LETTER' + Register class constraints (usually lower case). + +`CONST_OK_FOR_LETTER_P' + Immediate constant constraints, for non-floating point constants of + word size or smaller precision (usually upper case). + +`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). + +`EXTRA_CONSTRAINT' + Special cases of registers or memory. This macro is not required, + and is only defined for some machines. + + 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. + +*AMD 29000 family--`a29k.h'* + `l' + Local register 0 + + `b' + Byte Pointer (`BP') register + + `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) -Condition Code Status -===================== + `J' + Constant in range 0 to 63 (for 64 bit shifts) + + `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 - 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) +Not Using Constraints +--------------------- - This macro is not required if `EXTRA_CC_MODES' is not defined. + 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