--- gcc/gcc.info-14 2018/04/24 17:51:20 1.1 +++ gcc/gcc.info-14 2018/04/24 17:55:42 1.1.1.3 @@ -1,1090 +1,1052 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.47 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. - 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 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 "Boycott" +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 "Boycott", 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: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros -Trampolines for Nested Functions -================================ +Register Classes +================ + + On many machines, the numbered registers are not all equivalent. For +example, certain registers may not be allowed for indexed addressing; +certain registers may not be allowed in some instructions. These +machine restrictions are described to the compiler using "register +classes". + + You define a number of register classes, giving each one a name and +saying which of the registers belong to it. Then you can specify +register classes that are allowed as operands to particular instruction +patterns. + + In general, each register will belong to several classes. In fact, +one class must be named `ALL_REGS' and contain all the registers. +Another class must be named `NO_REGS' and contain no registers. Often +the union of two classes will be another class; however, this is not +required. + + One of the classes must be named `GENERAL_REGS'. There is nothing +terribly special about the name, but the operand constraint letters `r' +and `g' specify this class. If `GENERAL_REGS' is the same as +`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. + + Order the classes so that if class X is contained in class Y then X +has a lower class number than Y. + + The way classes other than `GENERAL_REGS' are specified in operand +constraints is through machine-dependent operand constraint letters. +You can define such letters to correspond to various classes, then use +them in operand constraints. + + You should define a class for the union of two classes whenever some +instruction allows both classes. For example, if an instruction allows +either a floating point (coprocessor) register or a general register +for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' +which includes both of them. Otherwise you will get suboptimal code. + + You must also specify certain redundant information about the +register classes: for each class, which classes contain it and which +ones are contained in it; for each pair of classes, the largest class +contained in their union. + + When a value occupying several consecutive registers is expected in a +certain class, all the registers used must belong to that class. +Therefore, register classes cannot be used to enforce a requirement for +a register pair to start with an even-numbered register. The way to +specify this requirement is with `HARD_REGNO_MODE_OK'. + + Register classes used for input-operands of bitwise-and or shift +instructions have a special requirement: each such class must have, for +each fixed-point machine mode, a subclass whose registers can transfer +that mode to or from memory. For example, on some machines, the +operations for single-byte values (`QImode') are limited to certain +registers. When this is so, each register class that is used in a +bitwise-and or shift instruction must have a subclass consisting of +registers from which single-byte values can be loaded or stored. This +is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to +return. + +`enum reg_class' + An enumeral type that must be defined with all the register class + names as enumeral values. `NO_REGS' must be first. `ALL_REGS' + must be the last register class, followed by one more enumeral + value, `LIM_REG_CLASSES', which is not a register class but rather + tells how many classes there are. + + Each register class has a number, which is the value of casting + the class name to type `int'. The number serves as an index in + many of the tables described below. + +`N_REG_CLASSES' + The number of distinct register classes, defined as follows: + + #define N_REG_CLASSES (int) LIM_REG_CLASSES + +`REG_CLASS_NAMES' + An initializer containing the names of the register classes as C + string constants. These names are used in writing some of the + debugging dumps. + +`REG_CLASS_CONTENTS' + An initializer containing the contents of the register classes, as + integers which are bit masks. The Nth integer specifies the + contents of class N. The way the integer MASK is interpreted is + that register R is in the class if `MASK & (1 << R)' is 1. + + When the machine has more than 32 registers, an integer does not + suffice. Then the integers are replaced by sub-initializers, + braced groupings containing several integers. Each + sub-initializer must be suitable as an initializer for the type + `HARD_REG_SET' which is defined in `hard-reg-set.h'. + +`REGNO_REG_CLASS (REGNO)' + A C expression whose value is a register class containing hard + register REGNO. In general there is more that one such class; + choose a class which is "minimal", meaning that no smaller class + also contains the register. + +`BASE_REG_CLASS' + A macro whose definition is the name of the class to which a valid + base register must belong. A base register is one used in an + address which is the register value plus a displacement. + +`INDEX_REG_CLASS' + A macro whose definition is the name of the class to which a valid + index register must belong. An index register is one used in an + address where its value is either multiplied by a scale factor or + added to another register (as well as added to a displacement). + +`REG_CLASS_FROM_LETTER (CHAR)' + A C expression which defines the machine-dependent operand + constraint letters for register classes. If CHAR is such a + letter, the value should be the register class corresponding to + it. Otherwise, the value should be `NO_REGS'. The register + letter `r', corresponding to class `GENERAL_REGS', will not be + passed to this macro; you do not need to handle it. + +`REGNO_OK_FOR_BASE_P (NUM)' + A C expression which is nonzero if register number NUM is suitable + for use as a base register in operand addresses. It may be either + a suitable hard register or a pseudo register that has been + allocated such a hard register. + +`REGNO_OK_FOR_INDEX_P (NUM)' + A C expression which is nonzero if register number NUM is suitable + for use as an index register in operand addresses. It may be + either a suitable hard register or a pseudo register that has been + allocated such a hard register. - 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. + 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. + +`PREFERRED_RELOAD_CLASS (X, CLASS)' + A C expression that places additional restrictions on the register + class to use when it is necessary to copy value X into a register + in class CLASS. The value is a register class; perhaps CLASS, or + perhaps another, smaller class. On many machines, the definition + + #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS + + is safe. + + Sometimes returning a more restrictive class makes better code. + For example, on the 68000, when X is an integer constant that is + in range for a `moveq' instruction, the value of this macro is + always `DATA_REGS' as long as CLASS includes the data registers. + Requiring a data register guarantees that a `moveq' will be used. + + If X is a `const_double', by returning `NO_REGS' you can force X + into a memory constant. This is useful on certain machines where + immediate floating values cannot be loaded into certain kinds of + registers. + +`LIMIT_RELOAD_CLASS (MODE, CLASS)' + A C expression that places additional restrictions on the register + class to use when it is necessary to be able to hold a value of + mode MODE in a reload register for which class CLASS would + ordinarily be used. + + Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when + there are certain modes that simply can't go in certain reload + classes. + + The value is a register class; perhaps CLASS, or perhaps another, + smaller class. + + Don't define this macro unless the target machine has limitations + which require the macro to do something nontrivial. + +`SECONDARY_RELOAD_CLASS (CLASS, MODE, X)' +`SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)' +`SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)' + Many machines have some registers that cannot be copied directly + to or from memory or even from other types of registers. An + example is the `MQ' register, which on most machines, can only be + copied to or from general registers, but not memory. Some + machines allow copying all registers to and from memory, but + require a scratch register for stores to some memory locations + (e.g., those with symbolic address on the RT, and those with + certain symbolic address on the Sparc when compiling PIC). In + some cases, both an intermediate and a scratch register are + required. + + You should define these macros to indicate to the reload phase + that it may need to allocate at least one register for a reload in + addition to the register to contain the data. Specifically, if + copying X to a register CLASS in MODE requires an intermediate + register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to + return the largest register class all of whose registers can be + used as intermediate registers or scratch registers. + + If copying a register CLASS in MODE to X requires an intermediate + or scratch register, you should define + `SECONDARY_OUTPUT_RELOAD_CLASS' to return the largest register + class required. If the requirements for input and output reloads + are the same, the macro `SECONDARY_RELOAD_CLASS' should be used + instead of defining both macros identically. + + The values returned by these macros are often `GENERAL_REGS'. + Return `NO_REGS' if no spare register is needed; i.e., if X can be + directly copied to or from a register of CLASS in MODE without + requiring a scratch register. Do not define this macro if it + would always return `NO_REGS'. + + If a scratch register is required (either with or without an + intermediate register), you should define patterns for + `reload_inM' or `reload_outM', as required (*note Standard + Names::.. These patterns, which will normally be implemented with + a `define_expand', should be similar to the `movM' patterns, + except that operand 2 is the scratch register. + + Define constraints for the reload register and scratch register + that contain a single register class. If the original reload + register (whose class is CLASS) can meet the constraint given in + the pattern, the value returned by these macros is used for the + class of the scratch register. Otherwise, two additional reload + registers are required. Their classes are obtained from the + constraints in the insn pattern. + + X might be a pseudo-register or a `subreg' of a pseudo-register, + which could either be in a hard register or in memory. Use + `true_regnum' to find out; it will return -1 if the pseudo is in + memory and the hard register number if it is in a register. + + These macros should not be used in the case where a particular + class of registers can only be copied to memory and not to another + class of registers. In that case, secondary reload registers are + not needed and would not be helpful. Instead, a stack location + must be used to perform the copy and the `movM' pattern should use + memory as a intermediate storage. This case often occurs between + floating-point and general registers. + +`SMALL_REGISTER_CLASSES' + Normally the compiler will avoid choosing spill registers from + registers that have been explicitly mentioned in the rtl (these + registers are normally those used to pass parameters and return + values). However, some machines have so few registers of certain + classes that there would not be enough registers to use as spill + registers if this were done. + + On those machines, you should define `SMALL_REGISTER_CLASSES'. + When it is defined, the compiler allows registers explicitly used + in the rtl to be used as spill registers but prevents the compiler + from extending the lifetime of these registers. + + Defining this macro is always safe, but unnecessarily defining + this macro will reduce the amount of optimizations that can be + performed in some cases. If this macro is not defined but needs + to be, the compiler will run out of reload registers and print a + fatal error message. + + For most machines, this macro should not be defined. + +`CLASS_MAX_NREGS (CLASS, MODE)' + A C expression for the maximum number of consecutive registers of + class CLASS needed to hold a value of mode MODE. + + This is closely related to the macro `HARD_REGNO_NREGS'. In fact, + the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be + the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all + REGNO values in the class CLASS. + + This macro helps control the handling of multiple-word values in + the reload pass. + + Three other special macros describe which operands fit which +constraint letters. + +`CONST_OK_FOR_LETTER_P (VALUE, C)' + A C expression that defines the machine-dependent operand + constraint letters that specify particular ranges of integer + values. If C is one of those letters, the expression should check + that VALUE, an integer, is in the appropriate range and return 1 + if so, 0 otherwise. If C is not one of those letters, the value + should be 0 regardless of VALUE. + +`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)' + A C expression that defines the machine-dependent operand + constraint letters that specify particular ranges of + `const_double' values. + + If C is one of those letters, the expression should check that + VALUE, an RTX of code `const_double', is in the appropriate range + and return 1 if so, 0 otherwise. If C is not one of those + letters, the value should be 0 regardless of VALUE. + + `const_double' is used for all floating-point constants and for + `DImode' fixed-point constants. A given letter can accept either + or both kinds of values. It can use `GET_MODE' to distinguish + between these kinds. + +`EXTRA_CONSTRAINT (VALUE, C)' + A C expression that defines the optional machine-dependent + constraint letters that can be used to segregate specific types of + operands, usually memory references, for the target machine. + Normally this macro will not be defined. If it is required for a + particular target machine, it should return 1 if VALUE corresponds + to the operand type represented by the constraint letter C. If C + is not defined as an extra constraint, the value returned should + be 0 regardless of VALUE. + + For example, on the ROMP, load instructions cannot have their + output in r0 if the memory reference contains a symbolic address. + Constraint letter `Q' is defined as representing a memory address + that does *not* contain a symbolic address. An alternative is + specified with a `Q' constraint on the input and `r' on the + output. The next alternative specifies `m' on the input and a + register class that does not include r0 on the output.  -File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Machine Macros +File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros -Implicit Calls to Library Routines -================================== +Describing Stack Layout and Calling Conventions +=============================================== -`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. +* Menu: - The default calling convention passes just the object and the - selector to the lookup function, which returns a pointer to the - method. +* Frame Layout:: +* Frame Registers:: +* Elimination:: +* Stack Arguments:: +* Register Arguments:: +* Scalar Return:: +* Aggregate Return:: +* Caller Saves:: +* Function Entry:: +* Profiling::  -File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Machine Macros +File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling -Addressing Modes -================ +Basic Stack Layout +------------------ -`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. +`STACK_GROWS_DOWNWARD' + Define this macro if pushing a word onto the stack moves the stack + pointer to a smaller address. + + When we say, "define this macro if ...," it means that the + compiler checks this macro only with `#ifdef' so the precise + definition used does not matter. + +`FRAME_GROWS_DOWNWARD' + Define this macro if the addresses of local variable slots are at + negative offsets from the frame pointer. + +`ARGS_GROW_DOWNWARD' + Define this macro if successive arguments to a function occupy + decreasing addresses on the stack. + +`STARTING_FRAME_OFFSET' + Offset from the frame pointer to the first local variable slot to + be allocated. + + If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by + subtracting the length of the first slot from + `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the + length of the first slot to the value `STARTING_FRAME_OFFSET'. + +`STACK_POINTER_OFFSET' + Offset from the stack pointer register to the first location at + which outgoing arguments are placed. If not specified, the + default value of zero is used. This is the proper value for most + machines. + + If `ARGS_GROW_DOWNWARD', this is the offset to the location above + the first location at which outgoing arguments are placed. + +`FIRST_PARM_OFFSET (FUNDECL)' + Offset from the argument pointer register to the first argument's + address. On some machines it may depend on the data type of the + function. - 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. + If `ARGS_GROW_DOWNWARD', this is the offset to the location above + the first argument's address. + +`STACK_DYNAMIC_OFFSET (FUNDECL)' + Offset from the stack pointer register to an item dynamically + allocated on the stack, e.g., by `alloca'. + + The default value for this macro is `STACK_POINTER_OFFSET' plus the + length of the outgoing arguments. The default is correct for most + machines. See `function.c' for details. + +`DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)' + A C expression whose value is RTL representing the address in a + stack frame where the pointer to the caller's frame is stored. + Assume that FRAMEADDR is an RTL expression for the address of the + stack frame itself. + + If you don't define this macro, the default is to return the value + of FRAMEADDR--that is, the stack frame address is also the address + of the stack word that points to the previous frame.  -File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Machine Macros +File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling -Condition Code Status -===================== +Registers That Address the Stack Frame +-------------------------------------- - 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) +`STACK_POINTER_REGNUM' + The register number of the stack pointer register, which must also + be a fixed register according to `FIXED_REGISTERS'. On most + machines, the hardware determines which register this is. + +`FRAME_POINTER_REGNUM' + The register number of the frame pointer register, which is used to + access automatic variables in the stack frame. On some machines, + the hardware determines which register this is. On other + machines, you can choose any register you wish for this purpose. + +`ARG_POINTER_REGNUM' + The register number of the arg pointer register, which is used to + access the function's argument list. On some machines, this is + the same as the frame pointer register. On some machines, the + hardware determines which register this is. On other machines, + you can choose any register you wish for this purpose. If this is + not the same register as the frame pointer register, then you must + mark it as a fixed register according to `FIXED_REGISTERS', or + arrange to be able to eliminate it (*note Elimination::.). + +`STATIC_CHAIN_REGNUM' +`STATIC_CHAIN_INCOMING_REGNUM' + Register numbers used for passing a function's static chain + pointer. If register windows are used, + `STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by + the called function, while `STATIC_CHAIN_REGNUM' is the register + number as seen by the calling function. If these registers are + the same, `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. + + The static chain register need not be a fixed register. + + If the static chain is passed in memory, these macros should not be + defined; instead, the next two macros should be defined. + +`STATIC_CHAIN' +`STATIC_CHAIN_INCOMING' + If the static chain is passed in memory, these macros provide rtx + giving `mem' expressions that denote where they are stored. + `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as + seen by the calling and called functions, respectively. Often the + former will be at an offset from the stack pointer and the latter + at an offset from the frame pointer. + + The variables `stack_pointer_rtx', `frame_pointer_rtx', and + `arg_pointer_rtx' will have been initialized prior to the use of + these macros and should be used to refer to those items. - This macro is not required if `EXTRA_CC_MODES' is not defined. + If the static chain is passed in a register, the two previous + macros should be defined instead.  -File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Machine Macros - -Describing Relative Costs of Operations -======================================= +File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling - These macros let you describe the relative speed of various -operations on the target machine. +Eliminating Frame Pointer and Arg Pointer +----------------------------------------- -`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. - - This macro is optional; do not define it if the default cost - assumptions are adequate for the target machine. - -`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. +`FRAME_POINTER_REQUIRED' + A C expression which is nonzero if a function must have and use a + frame pointer. This expression is evaluated in the reload pass. + If its value is nonzero the function will have a frame pointer. + + The expression can in principle examine the current function and + decide according to the facts, but on most machines the constant 0 + or the constant 1 suffices. Use 0 when the machine allows code to + be generated with no frame pointer, and doing so saves some time + or space. Use 1 when there is no possible advantage to avoiding a + frame pointer. + + In certain cases, the compiler does not know how to produce valid + code without a frame pointer. The compiler recognizes those cases + and automatically gives the function a frame pointer regardless of + what `FRAME_POINTER_REQUIRED' says. You don't need to worry about + them. + + In a function that does not require a frame pointer, the frame + pointer register can be allocated for ordinary usage, unless you + mark it as a fixed register. See `FIXED_REGISTERS' for more + information. + + This macro is ignored and need not be defined if `ELIMINABLE_REGS' + is defined. + +`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)' + A C statement to store in the variable DEPTH-VAR the difference + between the frame pointer and the stack pointer values immediately + after the function prologue. The value would be computed from + information such as the result of `get_frame_size ()' and the + tables of registers `regs_ever_live' and `call_used_regs'. + + If `ELIMINABLE_REGS' is defined, this macro will be not be used and + need not be defined. Otherwise, it must be defined even if + `FRAME_POINTER_REQUIRED' is defined to always be true; in that + case, you may set DEPTH-VAR to anything. + +`ELIMINABLE_REGS' + If defined, this macro specifies a table of register pairs used to + eliminate unneeded registers that point into the stack frame. If + it is not defined, the only elimination attempted by the compiler + is to replace references to the frame pointer with references to + the stack pointer. + + The definition of this macro is a list of structure + initializations, each of which specifies an original and + replacement register. + + On some machines, the position of the argument pointer is not + known until the compilation is completed. In such a case, a + separate hard register must be used for the argument pointer. + This register can be eliminated by replacing it with either the + frame pointer or the argument pointer, depending on whether or not + the frame pointer has been eliminated. + + In this case, you might specify: + #define ELIMINABLE_REGS \ + {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ + {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ + {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} + + Note that the elimination of the argument pointer with the stack + pointer is specified first since that is the preferred elimination. + +`CAN_ELIMINATE (FROM-REG, TO-REG)' + A C expression that returns non-zero if the compiler is allowed to + try to replace register number FROM-REG with register number + TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is + defined, and will usually be the constant 1, since most of the + cases preventing register elimination are things that the compiler + already knows about. + +`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)' + This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It + specifies the initial difference between the specified pair of + registers. This macro must be defined if `ELIMINABLE_REGS' is + defined. + +`LONGJMP_RESTORE_FROM_STACK' + Define this macro if the `longjmp' function restores registers from + the stack frames, rather than from those saved specifically by + `setjmp'. Certain quantities must not be kept in registers across + a call to `setjmp' on such machines.  -File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Machine Macros +File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling -Dividing the Output into Sections (Texts, Data, ...) -==================================================== +Passing Function Arguments on the Stack +--------------------------------------- + + The macros in this section control how arguments are passed on the +stack. See the following section for other macros that control passing +certain arguments in registers. + +`PROMOTE_PROTOTYPES' + Define this macro if an argument declared as `char' or `short' in + a prototype should actually be passed as an `int'. In addition to + avoiding errors in certain cases of mismatch, it also makes for + better code on certain machines. + +`PUSH_ROUNDING (NPUSHED)' + A C expression that is the number of bytes actually pushed onto the + stack when an instruction attempts to push NPUSHED bytes. + + If the target machine does not have a push instruction, do not + define this macro. That directs GNU CC to use an alternate + strategy: to allocate the entire argument block and then store the + arguments into it. + + On some machines, the definition + + #define PUSH_ROUNDING(BYTES) (BYTES) + + will suffice. But on other machines, instructions that appear to + push one byte actually push two bytes in an attempt to maintain + alignment. Then the definition should be + + #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) + +`ACCUMULATE_OUTGOING_ARGS' + If defined, the maximum amount of space required for outgoing + arguments will be computed and placed into the variable + `current_function_outgoing_args_size'. No space will be pushed + onto the stack for each call; instead, the function prologue should + increase the stack frame size by this amount. + + It is not proper to define both `PUSH_ROUNDING' and + `ACCUMULATE_OUTGOING_ARGS'. + +`REG_PARM_STACK_SPACE (FNDECL)' + Define this macro if functions should assume that stack space has + been allocated for arguments even when their values are passed in + registers. + + The value of this macro is the size, in bytes, of the area + reserved for ! arguments passed in registers for the function + represented by FNDECL. + + This space can either be allocated by the caller or be a part of + the machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' + says which. + +`MAYBE_REG_PARM_STACK_SPACE' +`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)' + Define these macros in addition to the one above if functions might + allocate stack space for arguments even when their values are + passed in registers. These should be used when the stack space + allocated for arguments in registers is not a simple constant + independent of the function declaration. + + The value of the first macro is the size, in bytes, of the area + that we should initially assume would be reserved for arguments + passed in registers. + + The value of the second macro is the actual size, in bytes, of the + area that will be reserved for arguments passed in registers. + This takes two arguments: an integer representing the number of + bytes of fixed sized arguments on the stack, and a tree + representing the number of bytes of variable sized arguments on + the stack. + + When these macros are defined, `REG_PARM_STACK_SPACE' will only be + called for libcall functions, the current function, or for a + function being called when it is known that such stack space must + be allocated. In each case this value can be easily computed. + + When deciding whether a called function needs such stack space, + and how much space to reserve, GNU CC uses these two macros + instead of `REG_PARM_STACK_SPACE'. + +`OUTGOING_REG_PARM_STACK_SPACE' + Define this if it is the responsibility of the caller to allocate + the area reserved for arguments passed in registers. + + If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls + whether the space for these arguments counts in the value of + `current_function_outgoing_args_size'. + +`STACK_PARMS_IN_REG_PARM_AREA' + Define this macro if `REG_PARM_STACK_SPACE' is defined but stack + parameters don't skip the area specified by `REG_PARM_STACK_SPACE'. + + Normally, when a parameter is not passed in registers, it is + placed on the stack beyond the `REG_PARM_STACK_SPACE' area. + Defining this macro suppresses this behavior and causes the + parameter to be passed on the stack in its natural location. + +`RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)' + A C expression that should indicate the number of bytes of its own + arguments that a function pops on returning, or 0 if the function + pops no arguments and the caller must therefore pop them all after + the function returns. + + FUNTYPE is a C variable whose value is a tree node that describes + the function in question. Normally it is a node of type + `FUNCTION_TYPE' that describes the data type of the function. From + this it is possible to obtain the data types of the value and + arguments (if known). + + When a call to a library function is being considered, FUNTYPE + will contain an identifier node for the library function. Thus, if + you need to distinguish among various library functions, you can + do so by their names. Note that "library function" in this + context means a function used to perform arithmetic, whose name is + known specially in the compiler and was not mentioned in the C + code being compiled. + + STACK-SIZE is the number of bytes of arguments passed on the + stack. If a variable number of bytes is passed, it is zero, and + argument popping will always be the responsibility of the calling + function. - 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). + On the Vax, all functions always pop their arguments, so the + definition of this macro is STACK-SIZE. On the 68000, using the + standard calling convention, no functions pop their arguments, so + the value of the macro is always 0 in this case. But an + alternative calling convention is available in which functions + that take a fixed number of arguments pop them but other functions + (such as `printf') pop nothing (the caller pops all). When this + convention is in use, FUNTYPE is examined to determine whether a + function takes a fixed number of arguments.  -File: gcc.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Machine Macros +File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling -Position Independent Code -========================= +Passing Arguments in Registers +------------------------------ - 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.) + This section describes the macros which let you control how various +types of arguments are passed in registers or how they are arranged in +the stack. + +`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)' + A C expression that controls whether a function argument is passed + in a register, and which register. + + The arguments are CUM, which summarizes all the previous + arguments; MODE, the machine mode of the argument; TYPE, the data + type of the argument as a tree node or 0 if that is not known + (which happens for C support library functions); and NAMED, which + is 1 for an ordinary argument and 0 for nameless arguments that + correspond to `...' in the called function's prototype. + + The value of the expression should either be a `reg' RTX for the + hard register in which to pass the argument, or zero to pass the + argument on the stack. + + For machines like the Vax and 68000, where normally all arguments + are pushed, zero suffices as a definition. + + The usual way to make the ANSI library `stdarg.h' work on a machine + where some arguments are usually passed in registers, is to cause + nameless arguments to be passed on the stack instead. This is done + by making `FUNCTION_ARG' return 0 whenever NAMED is 0. + + You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the + definition of this macro to determine if this argument is of a + type that must be passed in the stack. If `REG_PARM_STACK_SPACE' + is not defined and `FUNCTION_ARG' returns non-zero for such an + argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is + defined, the argument will be computed in the stack and then + loaded into a register. + +`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)' + Define this macro if the target machine has "register windows", so + that the register in which a function sees an arguments is not + necessarily the same as the one in which the caller passed the + argument. + + For such machines, `FUNCTION_ARG' computes the register in which + the caller passes the value, and `FUNCTION_INCOMING_ARG' should be + defined in a similar fashion to tell the function being called + where the arguments will arrive. + + If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves + both purposes. + +`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)' + A C expression for the number of words, at the beginning of an + argument, must be put in registers. The value must be zero for + arguments that are passed entirely in registers or that are + entirely pushed on the stack. + + On some machines, certain arguments must be passed partially in + registers and partially in memory. On these machines, typically + the first N words of arguments are passed in registers, and the + rest on the stack. If a multi-word argument (a `double' or a + structure) crosses that boundary, its first few words must be + passed in registers and the rest must be pushed. This macro tells + the compiler when this occurs, and how many of the words should go + in registers. + + `FUNCTION_ARG' for these arguments should return the first + register to be used by the caller for this argument; likewise + `FUNCTION_INCOMING_ARG', for the called function. + +`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)' + A C expression that indicates when an argument must be passed by + reference. If nonzero for an argument, a copy of that argument is + made in memory and a pointer to the argument is passed instead of + the argument itself. The pointer is passed in whatever way is + appropriate for passing a pointer to that type. + + On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable + definition of this macro might be + #define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \ + MUST_PASS_IN_STACK (MODE, TYPE) + +`CUMULATIVE_ARGS' + A C type for declaring a variable that is used as the first + argument of `FUNCTION_ARG' and other related values. For some + target machines, the type `int' suffices and can hold the number + of bytes of argument so far. + + There is no need to record in `CUMULATIVE_ARGS' anything about the + arguments that have been passed on the stack. The compiler has + other variables to keep track of that. For target machines on + which all arguments are passed on the stack, there is no need to + store anything in `CUMULATIVE_ARGS'; however, the data structure + must exist and should not be empty, so use `int'. + +`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)' + A C statement (sans semicolon) for initializing the variable CUM + for the state at the beginning of the argument list. The variable + has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node + for the data type of the function which will receive the args, or 0 + if the args are to a compiler support library function. + + When processing a call to a compiler support library function, + LIBNAME identifies which one. It is a `symbol_ref' rtx which + contains the name of the function, as a string. LIBNAME is 0 when + an ordinary C function call is being processed. Thus, each time + this macro is called, either LIBNAME or FNTYPE is nonzero, but + never both of them at once. + +`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)' + Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of + finding the arguments for the function being compiled. If this + macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. + + The argument LIBNAME exists for symmetry with + `INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always 0, + since library routines with special calling conventions are never + compiled with GNU CC. + +`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)' + A C statement (sans semicolon) to update the summarizer variable + CUM to advance past an argument in the argument list. The values + MODE, TYPE and NAMED describe that argument. Once this is done, + the variable CUM is suitable for analyzing the *following* + argument with `FUNCTION_ARG', etc. + + This macro need not do anything if the argument in question was + passed on the stack. The compiler knows how to track the amount + of stack space used for arguments without any special help. + +`FUNCTION_ARG_PADDING (MODE, TYPE)' + If defined, a C expression which determines whether, and in which + direction, to pad out an argument with extra space. The value + should be of type `enum direction': either `upward' to pad above + the argument, `downward' to pad below, or `none' to inhibit + padding. + + This macro does not control the *amount* of padding; that is + always just enough to reach the next multiple of + `FUNCTION_ARG_BOUNDARY'. + + This macro has a default definition which is right for most + systems. For little-endian machines, the default is to pad upward. + For big-endian machines, the default is to pad downward for an + argument of constant size shorter than an `int', and upward + otherwise. + +`FUNCTION_ARG_BOUNDARY (MODE, TYPE)' + If defined, a C expression that gives the alignment boundary, in + bits, of an argument with the specified mode and type. If it is + not defined, `PARM_BOUNDARY' is used for all arguments. + +`FUNCTION_ARG_REGNO_P (REGNO)' + A C expression that is nonzero if REGNO is the number of a hard + register in which function arguments are sometimes passed. This + does *not* include implicit arguments such as the static chain and + the structure-value address. On many machines, no registers can be + used for this purpose since all function arguments are pushed on + the stack.  -File: gcc.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Machine Macros +File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling -Defining the Output Assembler Language -====================================== +How Scalar Function Values Are Returned +--------------------------------------- - This section describes macros whose principal purpose is to -describe how to write instructions in assembler language--rather than -what the instructions do. + This section discusses the macros that control returning scalars as +values--values that can fit in registers. -* Menu: - -* 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. +`TRADITIONAL_RETURN_FLOAT' + Define this macro if `-traditional' should not cause functions + declared to return `float' to convert the value to `double'. + +`FUNCTION_VALUE (VALTYPE, FUNC)' + A C expression to create an RTX representing the place where a + function returns a value of data type VALTYPE. VALTYPE is a tree + node representing a data type. Write `TYPE_MODE (VALTYPE)' to get + the machine mode used to represent that type. On many machines, + only the mode is relevant. (Actually, on most machines, scalar + values are returned in the same place regardless of mode). + + If the precise function being called is known, FUNC is a tree node + (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This + makes it possible to use a different value-returning convention + for specific functions when all their calls are known. + + `FUNCTION_VALUE' is not used for return vales with aggregate data + types, because these are returned in another way. See + `STRUCT_VALUE_REGNUM' and related macros, below. + +`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' + Define this macro if the target machine has "register windows" so + that the register in which a function returns its value is not the + same as the one in which the caller sees the value. + + For such machines, `FUNCTION_VALUE' computes the register in which + the caller will see the value, and `FUNCTION_OUTGOING_VALUE' + should be defined in a similar fashion to tell the function where + to put the value. + + If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' + serves both purposes. + + `FUNCTION_OUTGOING_VALUE' is not used for return vales with + aggregate data types, because these are returned in another way. + See `STRUCT_VALUE_REGNUM' and related macros, below. + +`LIBCALL_VALUE (MODE)' + A C expression to create an RTX representing the place where a + library function returns a value of mode MODE. If the precise + function being called is known, FUNC is a tree node + (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This + makes it possible to use a different value-returning convention + for specific functions when all their calls are known. + + Note that "library function" in this context means a compiler + support routine, used to perform arithmetic, whose name is known + specially by the compiler and was not mentioned in the C code being + compiled. + + The definition of `LIBRARY_VALUE' need not be concerned aggregate + data types, because none of the library functions returns such + types. + +`FUNCTION_VALUE_REGNO_P (REGNO)' + A C expression that is nonzero if REGNO is the number of a hard + register in which the values of called function may come back. + + A register whose use for returning values is limited to serving as + the second of a pair (for a value of type `double', say) need not + be recognized by this macro. So for most machines, this definition + suffices: + + #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) + + If the machine has register windows, so that the caller and the + called function use different registers for the return value, this + macro should recognize only the caller's register numbers.  -File: gcc.info, Node: File Framework, Next: Data Output, Prev: Assembler Format, Up: Assembler Format +File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling + +How Large Values Are Returned +----------------------------- -The Overall Framework of an Assembler File ------------------------------------------- + When a function value's mode is `BLKmode' (and in some other cases), +the value is not returned according to `FUNCTION_VALUE' (*note Scalar +Return::.). Instead, the caller passes the address of a block of +memory in which the value should be stored. This address is called the +"structure value address". + + This section describes how to control returning structure values in +memory. + +`RETURN_IN_MEMORY (TYPE)' + A C expression which can inhibit the returning of certain function + values in registers, based on the type of value. A nonzero value + says to return the function value in memory, just as large + structures are always returned. Here TYPE will be a C expression + of type `tree', representing the data type of the value. + + Note that values of mode `BLKmode' are returned in memory + regardless of this macro. Also, the option `-fpcc-struct-return' + takes effect regardless of this macro. On most systems, it is + possible to leave the macro undefined; this causes a default + definition to be used, whose value is the constant 0. + +`STRUCT_VALUE_REGNUM' + If the structure value address is passed in a register, then + `STRUCT_VALUE_REGNUM' should be the number of that register. + +`STRUCT_VALUE' + If the structure value address is not passed in a register, define + `STRUCT_VALUE' as an expression returning an RTX for the place + where the address is passed. If it returns 0, the address is + passed as an "invisible" first argument. + +`STRUCT_VALUE_INCOMING_REGNUM' + On some architectures the place where the structure value address + is found by the called function is not the same place that the + caller put it. This can be due to register windows, or it could + be because the function prologue moves it to a different place. + + If the incoming location of the structure value address is in a + register, define this macro as the register number. + +`STRUCT_VALUE_INCOMING' + If the incoming location is not a register, define + `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the + called function should find the value. If it should find the + value on the stack, define this to create a `mem' which refers to + the frame pointer. A definition of 0 means that the address is + passed as an "invisible" first argument. + +`PCC_STATIC_STRUCT_RETURN' + Define this macro if the usual system convention on the target + machine for returning structures and unions is for the called + function to return the address of a static variable containing the + value. GNU CC does not normally use this convention, even if it + is the usual one, but does use it if `-fpcc-struct-value' is + specified. -`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. + Do not define this if the usual system convention is for the + caller to pass an address to the subroutine.  -File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format +File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling -Output of Data --------------- +Caller-Saves Register Allocation +-------------------------------- -`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: + If you enable it, GNU CC can save registers around function calls. +This makes it possible to use call-clobbered registers to hold +variables that must live across calls. + +`DEFAULT_CALLER_SAVES' + Define this macro if function calls on the target machine do not + preserve any registers; in other words, if `CALL_USED_REGISTERS' + has 1 for all registers. This macro enables `-fcaller-saves' by + default. Eventually that option will be enabled by default on all + machines and both the option and this macro will be eliminated. + +`CALLER_SAVE_PROFITABLE (REFS, CALLS)' + A C expression to determine whether it is worthwhile to consider + placing a pseudo-register in a call-clobbered hard register and + saving and restoring it around each function call. The expression + should be 1 when this is worth doing, and 0 otherwise. - #define ASM_OPEN_PAREN "(" - #define ASM_CLOSE_PAREN ")" + If you don't define this macro, a default is used which is good on + most machines: `4 * CALLS < REFS'.  \ No newline at end of file