Chapter 13: Target Description Macros and Functions 313 profiling using the system’s installed C compiler and look at the assembler code that results.
Older implementations of mcount expect the address of a counter variable to be loaded into some register. The name of this variable is ‘LP’ followed by the number labelno, so you would generate the name using ‘LP%d’ in a fprintf.
PROFILE_HOOK
[Macro]
A C statement or compound statement to output to file some assembly code to call the profiling subroutine mcount even the target does not support profiling.
NO_PROFILE_COUNTERS
[Macro]
Define this macro if the mcount subroutine on your system does not need a counter variable allocated for each function. This is true for almost all modern implementations. If you define this macro, you must not use the labelno argument to FUNCTION_
PROFILER
.
PROFILE_BEFORE_PROLOGUE
[Macro]
Define this macro if the code for function profiling should come before the function prologue. Normally, the profiling code comes after.
13.9.13 Permitting tail calls
bool TARGET_FUNCTION_OK_FOR_SIBCALL
(tree
decl
, tree
exp
) [Target Hook]
True if it is ok to do sibling call optimization for the specified call expression exp.
decl will be the called function, or NULL if this is an indirect call.
It is not uncommon for limitations of calling conventions to prevent tail calls to functions outside the current unit of translation, or during PIC compilation. The hook is used to enforce these restrictions, as the sibcall md pattern can not fail, or fall over to a “normal” call. The criteria for successful sibling call optimization may vary greatly between different architectures.
13.10 Implementing the Varargs Macros
GCC 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.
ISO <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 ISO 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
() [Macro]
Use this built-in function to save the argument registers in memory so that the varargs mechanism can access them. Both ISO and traditional versions of va_start must use
314 GNU Compiler Collection (GCC) Internals
__builtin_saveregs , unless you use TARGET_SETUP_INCOMING_VARARGS (see below) instead.
On some machines, __builtin_saveregs is open-coded under the control of the target hook TARGET_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.
__builtin_args_info
(
category
)
Use this built-in function to find the first anonymous arguments in registers.
[Macro]
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, floatingpoint 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
(
lastarg
) [Macro]
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. Also use it in va_start to verify that the second parameter lastarg is the last named argument of the current function.
__builtin_classify_type
(
object
) [Macro]
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:
Chapter 13: Target Description Macros and Functions 315
rtx TARGET_EXPAND_BUILTIN_SAVEREGS
(void) [Target Hook]
If defined, this hook 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.
void TARGET_SETUP_INCOMING_VARARGS
(CUMULATIVE ARGS
*
args_so_far
, enum machine mode
mode
, tree
type
, int
*
pretend_args_size
, int
second_time
)
[Target Hook]
This target hook offers an alternative to using __builtin_saveregs and defining the hook TARGET_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 points to the CUMULATIVE_ARGS data structure, containing the values that are obtained after processing 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 target hook 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 pointed to by 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, TARGET_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 hook TARGET_SETUP_
INCOMING_VARARGS should not generate any instructions in this case.
bool TARGET_STRICT_ARGUMENT_NAMING
(CUMULATIVE ARGS
*
ca
)
[Target Hook]
Define this hook to return true if the location where a function argument is passed depends on whether or not it is a named argument.
This hook controls how the named argument to FUNCTION_ARG is set for varargs and stdarg functions. If this hook returns true, the named argument is always true for named arguments, and false for unnamed arguments. If it returns false, but TARGET_
PRETEND_OUTGOING_VARARGS_NAMED returns true, then all arguments are treated as named. Otherwise, all named arguments except the last are treated as named.
You need not define this hook if it always returns zero.
bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
[Target Hook]
If you need to conditionally change ABIs so that one works with TARGET_SETUP_
INCOMING_VARARGS
, but the other works like neither TARGET_SETUP_INCOMING_
VARARGS nor TARGET_STRICT_ARGUMENT_NAMING was defined, then define this hook
