--- gcc/gcc.info-18 2018/04/24 18:08:23 1.1.1.3 +++ gcc/gcc.info-18 2018/04/24 18:12:06 1.1.1.4 @@ -28,1029 +28,999 @@ permission notice, may be included in tr Software Foundation instead of in the original English.  -File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling +File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers -How Scalar Function Values Are Returned ---------------------------------------- - - This section discusses the macros that control returning scalars as -values--values that can fit in registers. +Obsolete Macros for Controlling Register Usage +---------------------------------------------- -`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 `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same - promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar - type. - - 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. `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. + These features do not work very well. They exist because they used +to be required to generate correct code for the 80387 coprocessor of the +80386. They are no longer used by that machine description and may be +removed in a later version of the compiler. Don't use them! + +`OVERLAPPING_REGNO_P (REGNO)' + If defined, this is a C expression whose value is nonzero if hard + register number REGNO is an overlapping register. This means a + hard register which overlaps a hard register with a different + number. (Such overlap is undesirable, but occasionally it allows + a machine to be supported which otherwise could not be.) This + macro must return nonzero for *all* the registers which overlap + each other. GNU CC can use an overlapping register only in + certain limited ways. It can be used for allocation within a + basic block, and may be spilled for reloading; that is all. + + If this macro is not defined, it means that none of the hard + registers overlap each other. This is the usual situation. + +`INSN_CLOBBERS_REGNO_P (INSN, REGNO)' + If defined, this is a C expression whose value should be nonzero if + the insn INSN has the effect of mysteriously clobbering the + contents of hard register number REGNO. By "mysterious" we mean + that the insn's RTL expression doesn't describe such an effect. + + If this macro is not defined, it means that no insn clobbers + registers mysteriously. This is the usual situation; all else + being equal, it is best for the RTL expression to show all the + activity. + +`PRESERVE_DEATH_INFO_REGNO_P (REGNO)' + If defined, this is a C expression whose value is nonzero if + accurate `REG_DEAD' notes are needed for hard register number REGNO + at the time of outputting the assembler code. When this is so, a + few optimizations that take place after register allocation and + could invalidate the death notes are not done when this register is + involved. + + You would arrange to preserve death info for a register when some + of the code in the machine description which is executed to write + the assembler code looks at the death notes. This is necessary + only when the actual hardware feature which GNU CC thinks of as a + register is not actually a register of the usual sort. (It might, + for example, be a hardware stack.) -`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. - -`APPLY_RESULT_SIZE' - Define this macro if `untyped_call' and `untyped_return' need more - space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and - restoring an arbitrary return value. + If this macro is not defined, it means that no death notes need to + be preserved. This is the usual situation.  -File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling - -How Large Values Are Returned ------------------------------ +File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros - 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' must be explicitly handled by - 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 1 for `BLKmode' values, and 0 - otherwise. - - Do not use this macro to indicate that structures and unions - should always be returned in memory. You should instead use - `DEFAULT_PCC_STRUCT_RETURN' to indicate this. - -`DEFAULT_PCC_STRUCT_RETURN' - Define this macro to be 1 if all structure and union return values - must be in memory. Since this results in slower code, this should - be defined only if needed for compatibility with other compilers - or with an ABI. If you define this macro to be 0, then the - conventions used for structure and union return values are decided - by the `RETURN_IN_MEMORY' macro. - - If not defined, this defaults to the value 1. - -`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, then you should 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-return' is - specified. - - Do not define this if the usual system convention is for the - caller to pass an address to the subroutine. +Register Classes +================ - -File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling + 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 than 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. -Caller-Saves Register Allocation --------------------------------- + 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. - 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. +`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 following + definition is safe: + + #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS + + 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. - If you don't define this macro, a default is used which is good on - most machines: `4 * CALLS < REFS'. +`PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)' + Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of + input reloads. If you don't define this macro, the default is to + use CLASS, unchanged. + +`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, `SECONDARY_OUTPUT_RELOAD_CLASS' should be + defined 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. + +`SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)' + Certain machines have the property that some registers cannot be + copied to some other registers without using memory. Define this + macro on those machines to be a C expression that is non-zero if + objects of mode M in registers of CLASS1 can only be copied to + registers of class CLASS2 by storing a register of CLASS1 into + memory and loading that memory location into a register of CLASS2. + + Do not define this macro if its value would always be zero. + +`SECONDARY_MEMORY_NEEDED_RTX (MODE)' + Normally, when `SECONDARY_MEMORY_NEEDED' is defined, the compiler + will allocate a stack slot when a memory location for a register + copy is needed. If this macro is defined, the compiler instead + uses the memory location defined by this macro. + +`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. + + You should define `SMALL_REGISTER_CLASSES' on those machines. 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_LIKELY_SPILLED_P (CLASS)' + A C expression whose value is nonzero if pseudos that have been + assigned to registers of class CLASS would likely be spilled + because registers of CLASS are needed for spill registers. + + The default value of this macro returns 1 if CLASS has exactly one + register and zero otherwise. On most machines, this default + should be used. Only define this macro to some other expression + if pseudo allocated by `local-alloc.c' end up in memory because + their hard registers were needed for spill regisers. If this + macro returns nonzero for those classes, those pseudos will only + be allocated by `global.c', which knows how to reallocate the + pseudo to another register. If there would not be another + register available for reallocation, you should not change the + definition of this macro since the only effect of such a + definition would be to slow down register allocation. + +`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: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling +File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros -Function Entry and Exit ------------------------ +Stack Layout and Calling Conventions +==================================== - This section describes the macros that output function entry -("prologue") and exit ("epilogue") code. +* Menu: -`FUNCTION_PROLOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for entry - to a function. The prologue is responsible for setting up the - stack frame, initializing the frame pointer register, saving - registers that must be saved, and allocating SIZE additional bytes - of storage for the local variables. SIZE is an integer. FILE is - a stdio stream to which the assembler code should be output. - - The label for the beginning of the function need not be output by - this macro. That has already been done when the macro is run. - - To determine which registers to save, the macro can refer to the - array `regs_ever_live': element R is nonzero if hard register R is - used anywhere within the function. This implies the function - prologue should save register R, provided it is not one of the - call-used registers. (`FUNCTION_EPILOGUE' must likewise use - `regs_ever_live'.) - - On machines that have "register windows", the function entry code - does not save on the stack the registers that are in the windows, - even if they are supposed to be preserved by function calls; - instead it takes appropriate steps to "push" the register stack, - if any non-call-used registers are used in the function. - - On machines where functions may or may not have frame-pointers, the - function entry code must vary accordingly; it must set up the frame - pointer if one is wanted, and not otherwise. To determine whether - a frame pointer is in wanted, the macro can refer to the variable - `frame_pointer_needed'. The variable's value will be 1 at run - time in a function that needs a frame pointer. *Note - Elimination::. - - The function entry code is responsible for allocating any stack - space required for the function. This stack space consists of the - regions listed below. In most cases, these regions are allocated - in the order listed, with the last listed region closest to the - top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is - defined, and the highest address if it is not defined). You can - use a different order for a machine if doing so is more convenient - or required for compatibility reasons. Except in cases where - required by standard or by a debugger, there is no reason why the - stack layout used by GCC need agree with that used by other - compilers for a machine. - - * A region of `current_function_pretend_args_size' bytes of - uninitialized space just underneath the first argument - arriving on the stack. (This may not be at the very start of - the allocated stack region if the calling sequence has pushed - anything else since pushing the stack arguments. But - usually, on such machines, nothing else has been pushed yet, - because the function prologue itself does all the pushing.) - This region is used on machines where an argument may be - passed partly in registers and partly in memory, and, in some - cases to support the features in `varargs.h' and `stdargs.h'. - - * An area of memory used to save certain registers used by the - function. The size of this area, which may also include - space for such things as the return address and pointers to - previous stack frames, is machine-specific and usually - depends on which registers have been used in the function. - Machines with register windows often do not require a save - area. - - * A region of at least SIZE bytes, possibly rounded up to an - allocation boundary, to contain the local variables of the - function. On some machines, this region and the save area - may occur in the opposite order, with the save area closer to - the top of the stack. - - * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a - region of `current_function_outgoing_args_size' bytes to be - used for outgoing argument lists of the function. *Note - Stack Arguments::. - - Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and - `FUNCTION_EPILOGUE' to treat leaf functions specially. The C - variable `leaf_function' is nonzero for such a function. - -`EXIT_IGNORE_STACK' - Define this macro as a C expression that is nonzero if the return - instruction or the function epilogue ignores the value of the stack - pointer; in other words, if it is safe to delete an instruction to - adjust the stack pointer before a return from the function. - - Note that this macro's value is relevant only for functions for - which frame pointers are maintained. It is never safe to delete a - final stack adjustment in a function that has no frame pointer, - and the compiler knows this regardless of `EXIT_IGNORE_STACK'. - -`FUNCTION_EPILOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for exit - from a function. The epilogue is responsible for restoring the - saved registers and stack pointer to their values when the - function was called, and returning control to the caller. This - macro takes the same arguments as the macro `FUNCTION_PROLOGUE', - and the registers to restore are determined from `regs_ever_live' - and `CALL_USED_REGISTERS' in the same way. - - On some machines, there is a single instruction that does all the - work of returning from the function. On these machines, give that - instruction the name `return' and do not define the macro - `FUNCTION_EPILOGUE' at all. - - Do not define a pattern named `return' if you want the - `FUNCTION_EPILOGUE' to be used. If you want the target switches - to control whether return instructions or epilogues are used, - define a `return' pattern with a validity condition that tests the - target switches appropriately. If the `return' pattern's validity - condition is false, epilogues will be used. - - On machines where functions may or may not have frame-pointers, the - function exit code must vary accordingly. Sometimes the code for - these two cases is completely different. To determine whether a - frame pointer is wanted, the macro can refer to the variable - `frame_pointer_needed'. The variable's value will be 1 at run time - in a function that needs a frame pointer. - - Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat - leaf functions specially. The C variable `leaf_function' is - nonzero for such a function. *Note Leaf Functions::. - - On some machines, some functions pop their arguments on exit while - others leave that for the caller to do. For example, the 68020 - when given `-mrtd' pops arguments in functions that take a fixed - number of arguments. - - Your definition of the macro `RETURN_POPS_ARGS' decides which - functions pop their own arguments. `FUNCTION_EPILOGUE' needs to - know what was decided. The variable that is called - `current_function_pops_args' is the number of bytes of its - arguments that a function should pop. *Note Scalar Return::. - -`DELAY_SLOTS_FOR_EPILOGUE' - Define this macro if the function epilogue contains delay slots to - which instructions from the rest of the function can be "moved". - The definition should be a C expression whose value is an integer - representing the number of delay slots there. - -`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' - A C expression that returns 1 if INSN can be placed in delay slot - number N of the epilogue. - - The argument N is an integer which identifies the delay slot now - being considered (since different slots may have different rules of - eligibility). It is never negative and is always less than the - number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' - returns). If you reject a particular insn for a given delay slot, - in principle, it may be reconsidered for a subsequent delay slot. - Also, other insns may (at least in principle) be considered for - the so far unfilled delay slot. - - The insns accepted to fill the epilogue delay slots are put in an - RTL list made with `insn_list' objects, stored in the variable - `current_function_epilogue_delay_list'. The insn for the first - delay slot comes first in the list. Your definition of the macro - `FUNCTION_EPILOGUE' should fill the delay slots by outputting the - insns in this list, usually by calling `final_scan_insn'. - - You need not define this macro if you did not define - `DELAY_SLOTS_FOR_EPILOGUE'. +* Frame Layout:: +* Frame Registers:: +* Elimination:: +* Stack Arguments:: +* Register Arguments:: +* Scalar Return:: +* Aggregate Return:: +* Caller Saves:: +* Function Entry:: +* Profiling::  -File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling - -Generating Code for Profiling ------------------------------ +File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling - These macros will help you generate code for profiling. +Basic Stack Layout +------------------ -`FUNCTION_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to call the profiling subroutine `mcount'. Before - calling, the assembler code must load the address of a counter - variable into a register where `mcount' expects to find the - address. The name of this variable is `LP' followed by the number - LABELNO, so you would generate the name using `LP%d' in a - `fprintf'. - - The details of how the address should be passed to `mcount' are - determined by your operating system environment, not by GNU CC. To - figure them out, compile a small program for profiling using the - system's installed C compiler and look at the assembler code that - results. - -`PROFILE_BEFORE_PROLOGUE' - Define this macro if the code for function profiling should come - before the function prologue. Normally, the profiling code comes - after. - -`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to initialize basic-block profiling for the current - object module. This code should call the subroutine - `__bb_init_func' once per object module, passing it as its sole - argument the address of a block allocated in the object module. - - The name of the block is a local symbol made with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. - - The first word of this block is a flag which will be nonzero if the - object module has already been initialized. So test this word - first, and do not call `__bb_init_func' if the flag is nonzero. - -`BLOCK_PROFILER (FILE, BLOCKNO)' - A C statement or compound statement to increment the count - associated with the basic block number BLOCKNO. Basic blocks are - numbered separately from zero within each compilation. The count - associated with block number BLOCKNO is at index BLOCKNO in a - vector of words; the name of this array is a local symbol made - with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. +`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', find the next slot's offset by + subtracting the first slot's length 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. + + 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. + +`SERTUP_FRAME_ADDRESSES ()' + If defined, a C expression that produces the machine-specific code + to setup the stack so that arbitrary frames can be accessed. For + example, on the Sparc, we must flush all of the register windows + to the stack before we can access arbitrary stack frames. This + macro will seldom need to be defined. + +`RETURN_ADDR_RTX (COUNT, FRAMEADDR)' + A C expression whose value is RTL representing the value of the + return address for the frame COUNT steps up from the current frame. + fRAMEADDR is the frame pointer of the COUNT frame, or the frame + pointer of the COUNT - 1 frame if `RETURN_ADDR_IN_PREVIOUS_FRAME' + is defined. + +`RETURN_ADDR_IN_PREVIOUS_FRAME' + Define this if the return address of a particular stack frame is + accessed from the frame pointer of the previous stack frame.  -File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros +File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling -Implementing the Varargs Macros -=============================== +Registers That Address the Stack Frame +-------------------------------------- - GNU CC comes with an implementation of `varargs.h' and `stdarg.h' -that work without change on machines that pass arguments on the stack. -Other machines require their own implementations of varargs, and the -two machine independent header files must have conditionals to include -it. - - ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the -calling convention for `va_start'. The traditional implementation -takes just one argument, which is the variable in which to store the -argument pointer. The ANSI implementation of `va_start' takes an -additional second argument. The user is supposed to write the last -named argument of the function here. - - However, `va_start' should not use this argument. The way to find -the end of the named arguments is with the built-in functions described -below. - -`__builtin_saveregs ()' - Use this built-in function to save the argument registers in - memory so that the varargs mechanism can access them. Both ANSI - and traditional versions of `va_start' must use - `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see - below) instead. - - On some machines, `__builtin_saveregs' is open-coded under the - control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines, - it calls a routine written in assembler language, found in - `libgcc2.c'. - - Code generated for the call to `__builtin_saveregs' appears at the - beginning of the function, as opposed to where the call to - `__builtin_saveregs' is written, regardless of what the code is. - This is because the registers must be saved before the function - starts to use them for its own purposes. +`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. + +`HARD_FRAME_POINTER_REGNUM' + On some machines the offset between the frame pointer and starting + offset of the automatic variables is not known until after register + allocation has been done (for example, because the saved registers + are between these two locations). On those machines, + `FRAME_POINTER_REGNUM' as a special, fixed register to be used + internally until the offset is known, and define + `HARD_FRAME_POINTER_REGNUM' to be the hard register used for the + frame pointer. + + You should define this macro only in the very rare circumstances + when it is not possible to calculate the offset between the frame + pointer and the automatic variables until after register + allocation has been completed. When this macro is defined, you + must also indicate in your definition of `ELIMINABLE_REGS' how to + eliminate `FRAME_POINTER_REGNUM' into either + `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. + + Do not define this macro if it would be the same as + `FRAME_POINTER_REGNUM'. + +`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, the register number as + seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', + while the register number as seen by the calling function is + `STATIC_CHAIN_REGNUM'. 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. -`__builtin_args_info (CATEGORY)' - Use this built-in function to find the first anonymous arguments in - registers. - - In general, a machine may have several categories of registers - used for arguments, each for a particular category of data types. - (For example, on some machines, floating-point registers are used - for floating-point arguments while other arguments are passed in - the general registers.) To make non-varargs functions use the - proper calling convention, you have defined the `CUMULATIVE_ARGS' - data type to record how many registers in each category have been - used so far - - `__builtin_args_info' accesses the same data structure of type - `CUMULATIVE_ARGS' after the ordinary argument layout is finished - with it, with CATEGORY specifying which word to access. Thus, the - value indicates the first unused register in a given category. - - Normally, you would use `__builtin_args_info' in the implementation - of `va_start', accessing each category just once and storing the - value in the `va_list' object. This is because `va_list' will - have to update the values, and there is no way to alter the values - accessed by `__builtin_args_info'. - -`__builtin_next_arg ()' - This is the equivalent of `__builtin_args_info', for stack - arguments. It returns the address of the first anonymous stack - argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns - the address of the location above the first anonymous stack - argument. Use it in `va_start' to initialize the pointer for - fetching arguments from the stack. - -`__builtin_classify_type (OBJECT)' - Since each machine has its own conventions for which data types are - passed in which kind of register, your implementation of `va_arg' - has to embody these conventions. The easiest way to categorize the - specified data type is to use `__builtin_classify_type' together - with `sizeof' and `__alignof__'. - - `__builtin_classify_type' ignores the value of OBJECT, considering - only its data type. It returns an integer describing what kind of - type that is--integer, floating, pointer, structure, and so on. - - The file `typeclass.h' defines an enumeration that you can use to - interpret the values of `__builtin_classify_type'. - - These machine description macros help implement varargs: - -`EXPAND_BUILTIN_SAVEREGS (ARGS)' - If defined, is a C expression that produces the machine-specific - code for a call to `__builtin_saveregs'. This code will be moved - to the very beginning of the function, before any parameter access - are made. The return value of this function should be an RTX that - contains the value to use as the return of `__builtin_saveregs'. - - The argument ARGS is a `tree_list' containing the arguments that - were passed to `__builtin_saveregs'. - - If this macro is not defined, the compiler will output an ordinary - call to the library function `__builtin_saveregs'. - -`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE,' - PRETEND_ARGS_SIZE, SECOND_TIME) This macro offers an alternative - to using `__builtin_saveregs' and defining the macro - `EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous register - arguments into the stack so that all the arguments appear to have - been passed consecutively on the stack. Once this is done, you - can use the standard implementation of varargs that works for - machines that pass all their arguments on the stack. - - The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, - containing the values that obtain after processing of the named - arguments. The arguments MODE and TYPE describe the last named - argument--its machine mode and its data type as a tree node. - - The macro implementation should do two things: first, push onto the - stack all the argument registers *not* used for the named - arguments, and second, store the size of the data thus pushed into - the `int'-valued variable whose name is supplied as the argument - PRETEND_ARGS_SIZE. The value that you store here will serve as - additional offset for setting up the stack frame. - - Because you must generate code to push the anonymous arguments at - compile time without knowing their data types, - `SETUP_INCOMING_VARARGS' is only useful on machines that have just - a single category of argument register and use it uniformly for - all data types. - - If the argument SECOND_TIME is nonzero, it means that the - arguments of the function are being analyzed for the second time. - This happens for an inline function, which is not actually - compiled until the end of the source file. The macro - `SETUP_INCOMING_VARARGS' should not generate any instructions in - this case. + If the static chain is passed in a register, the two previous + macros should be defined instead.  -File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros +File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling -Trampolines for Nested Functions -================================ +Eliminating Frame Pointer and Arg Pointer +----------------------------------------- - 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_SECTION' - The name of a subroutine to switch to the section in which the - trampoline template is to be placed (*note Sections::.). The - default is a value of `readonly_data_section', which places the - trampoline in the section containing read-only data. - -`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. +`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 you do not need to define it if the + function `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: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros +File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling -Implicit Calls to Library Routines -================================== +Passing Function Arguments on the Stack +--------------------------------------- -`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_EDOM' - The value of `EDOM' on the target machine, as a C integer constant - expression. If you don't define this macro, GNU CC does not - attempt to deposit the value of `EDOM' into `errno' directly. - Look in `/usr/include/errno.h' to find the value of `EDOM' on your - system. - - If you do not define `TARGET_EDOM', then compiled code reports - domain errors by calling the library function and letting it - report the error. If mathematical functions on your system use - `matherr' when there is an error, then you should leave - `TARGET_EDOM' undefined so that `matherr' is used normally. - -`GEN_ERRNO_RTX' - Define this macro as a C expression to create an rtl expression - that refers to the global "variable" `errno'. (On certain systems, - `errno' may not actually be a variable.) If you don't define this - macro, a reasonable default is used. - -`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. - -`nongcc_SI_type' - 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 `long int', as it - usually is. - -`nongcc_word_type' - Define this macro as the name of the data type corresponding to the - word_mode in the system's own C compiler. - - You need not define this macro if that type is `long int', as it - usually is. - -`perform_...' - Define these macros to supply explicit C statements to carry out - various arithmetic operations on types `float' and `double' in the - library routines in `libgcc1.c'. See that file for a full list of - these macros and their arguments. - - On most machines, you don't need to define any of these macros, - because the C compiler that comes with the system takes care of - doing them. - -`NEXT_OBJC_RUNTIME' - Define this macro to generate code for Objective C message sending - using the calling convention of the NeXT system. This calling - convention involves passing the object, the selector and the - method arguments all at once to the method-lookup library function. - - The default calling convention passes just the object and the - selector to the lookup function, which returns a pointer to the - method. + 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 in a prototype as an + integral type smaller than `int' 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. + + Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is + not proper. + +`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 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 the + stack parameters don't skip the area specified by it. + + 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. + + 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: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros +File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling -Addressing Modes -================ +Passing Arguments in Registers +------------------------------ -`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. - - Subroutines to check for acceptable registers for various purposes - (one for base registers, one for index registers, and so on) are - typically among the subroutines used to define - `GO_IF_LEGITIMATE_ADDRESS'. 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, and define `STRIP_NAME_ENCODING' - to access the original name string. - - You can check the information stored here into the `symbol_ref' in - the definitions of the macros `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. + 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) + +`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)' + If defined, a C expression that indicates when it is the called + function's responsibility to make a copy of arguments passed by + invisible reference. Normally, the caller makes a copy and passes + the address of the copy to the routine being called. When + FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller + does not make a copy. Instead, it passes a pointer to the "live" + value. The called function must not modify this value. If it can + be determined that the value won't be modified, it need not make a + copy; otherwise a copy must be made. + +`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 value passed for LIBNAME is always 0, since library routines + with special calling conventions are never compiled with GNU CC. + The argument LIBNAME exists for symmetry with + `INIT_CUMULATIVE_ARGS'. + +`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. + + The *amount* of padding is always just enough to reach the next + multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control + it. + + 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. - 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. +`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. -`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 or if the address is valid for some modes but not - others. - - 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. +`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.