]>
Commit | Line | Data |
---|---|---|
336b436a JL |
1 | This is Info file gcc.info, produced by Makeinfo version 1.68 from the |
2 | input file gcc.texi. | |
3 | ||
4 | This file documents the use and the internals of the GNU compiler. | |
5 | ||
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 | |
7 | Boston, MA 02111-1307 USA | |
8 | ||
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free | |
10 | Software Foundation, Inc. | |
11 | ||
12 | Permission is granted to make and distribute verbatim copies of this | |
13 | manual provided the copyright notice and this permission notice are | |
14 | preserved on all copies. | |
15 | ||
16 | Permission is granted to copy and distribute modified versions of | |
17 | this manual under the conditions for verbatim copying, provided also | |
18 | that the sections entitled "GNU General Public License," "Funding for | |
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are | |
20 | included exactly as in the original, and provided that the entire | |
21 | resulting derived work is distributed under the terms of a permission | |
22 | notice identical to this one. | |
23 | ||
24 | Permission is granted to copy and distribute translations of this | |
25 | manual into another language, under the above conditions for modified | |
26 | versions, except that the sections entitled "GNU General Public | |
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight | |
28 | `Look And Feel'", and this permission notice, may be included in | |
29 | translations approved by the Free Software Foundation instead of in the | |
30 | original English. | |
31 | ||
32 | \1f | |
33 | File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling | |
34 | ||
35 | Generating Code for Profiling | |
36 | ----------------------------- | |
37 | ||
38 | These macros will help you generate code for profiling. | |
39 | ||
40 | `FUNCTION_PROFILER (FILE, LABELNO)' | |
41 | A C statement or compound statement to output to FILE some | |
42 | assembler code to call the profiling subroutine `mcount'. Before | |
43 | calling, the assembler code must load the address of a counter | |
44 | variable into a register where `mcount' expects to find the | |
45 | address. The name of this variable is `LP' followed by the number | |
46 | LABELNO, so you would generate the name using `LP%d' in a | |
47 | `fprintf'. | |
48 | ||
49 | The details of how the address should be passed to `mcount' are | |
50 | determined by your operating system environment, not by GNU CC. To | |
51 | figure them out, compile a small program for profiling using the | |
52 | system's installed C compiler and look at the assembler code that | |
53 | results. | |
54 | ||
55 | `PROFILE_BEFORE_PROLOGUE' | |
56 | Define this macro if the code for function profiling should come | |
57 | before the function prologue. Normally, the profiling code comes | |
58 | after. | |
59 | ||
60 | `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' | |
61 | A C statement or compound statement to output to FILE some | |
62 | assembler code to initialize basic-block profiling for the current | |
63 | object module. The global compile flag `profile_block_flag' | |
64 | distingishes two profile modes. | |
65 | ||
66 | `profile_block_flag != 2' | |
67 | Output code to call the subroutine `__bb_init_func' once per | |
68 | object module, passing it as its sole argument the address of | |
69 | a block allocated in the object module. | |
70 | ||
71 | The name of the block is a local symbol made with this | |
72 | statement: | |
73 | ||
74 | ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); | |
75 | ||
76 | Of course, since you are writing the definition of | |
77 | `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, | |
78 | you can take a short cut in the definition of this macro and | |
79 | use the name that you know will result. | |
80 | ||
81 | The first word of this block is a flag which will be nonzero | |
82 | if the object module has already been initialized. So test | |
83 | this word first, and do not call `__bb_init_func' if the flag | |
84 | is nonzero. BLOCK_OR_LABEL contains a unique number which | |
85 | may be used to generate a label as a branch destination when | |
86 | `__bb_init_func' will not be called. | |
87 | ||
88 | Described in assembler language, the code to be output looks | |
89 | like: | |
90 | ||
91 | cmp (LPBX0),0 | |
92 | bne local_label | |
93 | parameter1 <- LPBX0 | |
94 | call __bb_init_func | |
95 | local_label: | |
96 | ||
97 | `profile_block_flag == 2' | |
98 | Output code to call the subroutine `__bb_init_trace_func' and | |
99 | pass two parameters to it. The first parameter is the same as | |
100 | for `__bb_init_func'. The second parameter is the number of | |
101 | the first basic block of the function as given by | |
102 | BLOCK_OR_LABEL. Note that `__bb_init_trace_func' has to be | |
103 | called, even if the object module has been initialized | |
104 | already. | |
105 | ||
106 | Described in assembler language, the code to be output looks | |
107 | like: | |
108 | parameter1 <- LPBX0 | |
109 | parameter2 <- BLOCK_OR_LABEL | |
110 | call __bb_init_trace_func | |
111 | ||
112 | `BLOCK_PROFILER (FILE, BLOCKNO)' | |
113 | A C statement or compound statement to output to FILE some | |
114 | assembler code to increment the count associated with the basic | |
115 | block number BLOCKNO. The global compile flag | |
116 | `profile_block_flag' distingishes two profile modes. | |
117 | ||
118 | `profile_block_flag != 2' | |
119 | Output code to increment the counter directly. Basic blocks | |
120 | are numbered separately from zero within each compilation. | |
121 | The count associated with block number BLOCKNO is at index | |
122 | BLOCKNO in a vector of words; the name of this array is a | |
123 | local symbol made with this statement: | |
124 | ||
125 | ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); | |
126 | ||
127 | Of course, since you are writing the definition of | |
128 | `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, | |
129 | you can take a short cut in the definition of this macro and | |
130 | use the name that you know will result. | |
131 | ||
132 | Described in assembler language, the code to be output looks | |
133 | like: | |
134 | ||
135 | inc (LPBX2+4*BLOCKNO) | |
136 | ||
137 | `profile_block_flag == 2' | |
138 | Output code to initialize the global structure `__bb' and | |
139 | call the function `__bb_trace_func', which will increment the | |
140 | counter. | |
141 | ||
142 | `__bb' consists of two words. In the first word, the current | |
143 | basic block number, as given by BLOCKNO, has to be stored. In | |
144 | the second word, the address of a block allocated in the | |
145 | object module has to be stored. The address is given by the | |
146 | label created with this statement: | |
147 | ||
148 | ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); | |
149 | ||
150 | Described in assembler language, the code to be output looks | |
151 | like: | |
152 | move BLOCKNO -> (__bb) | |
153 | move LPBX0 -> (__bb+4) | |
154 | call __bb_trace_func | |
155 | ||
156 | `FUNCTION_BLOCK_PROFILER_EXIT (FILE)' | |
157 | A C statement or compound statement to output to FILE assembler | |
158 | code to call function `__bb_trace_ret'. The assembler code should | |
159 | only be output if the global compile flag `profile_block_flag' == | |
160 | 2. This macro has to be used at every place where code for | |
161 | returning from a function is generated (e.g. `FUNCTION_EPILOGUE'). | |
162 | Although you have to write the definition of `FUNCTION_EPILOGUE' | |
163 | as well, you have to define this macro to tell the compiler, that | |
164 | the proper call to `__bb_trace_ret' is produced. | |
165 | ||
166 | `MACHINE_STATE_SAVE (ID)' | |
167 | A C statement or compound statement to save all registers, which | |
168 | may be clobbered by a function call, including condition codes. | |
169 | The `asm' statement will be mostly likely needed to handle this | |
170 | task. Local labels in the assembler code can be concatenated with | |
171 | the string ID, to obtain a unique lable name. | |
172 | ||
173 | Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or | |
174 | `FUNCTION_EPILOGUE' must be saved in the macros | |
175 | `FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and | |
176 | `BLOCK_PROFILER' prior calling `__bb_init_trace_func', | |
177 | `__bb_trace_ret' and `__bb_trace_func' respectively. | |
178 | ||
179 | `MACHINE_STATE_RESTORE (ID)' | |
180 | A C statement or compound statement to restore all registers, | |
181 | including condition codes, saved by `MACHINE_STATE_SAVE'. | |
182 | ||
183 | Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or | |
184 | `FUNCTION_EPILOGUE' must be restored in the macros | |
185 | `FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and | |
186 | `BLOCK_PROFILER' after calling `__bb_init_trace_func', | |
187 | `__bb_trace_ret' and `__bb_trace_func' respectively. | |
188 | ||
189 | `BLOCK_PROFILER_CODE' | |
190 | A C function or functions which are needed in the library to | |
191 | support block profiling. | |
192 | ||
193 | \1f | |
194 | File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros | |
195 | ||
196 | Implementing the Varargs Macros | |
197 | =============================== | |
198 | ||
199 | GNU CC comes with an implementation of `varargs.h' and `stdarg.h' | |
200 | that work without change on machines that pass arguments on the stack. | |
201 | Other machines require their own implementations of varargs, and the | |
202 | two machine independent header files must have conditionals to include | |
203 | it. | |
204 | ||
205 | ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the | |
206 | calling convention for `va_start'. The traditional implementation | |
207 | takes just one argument, which is the variable in which to store the | |
208 | argument pointer. The ANSI implementation of `va_start' takes an | |
209 | additional second argument. The user is supposed to write the last | |
210 | named argument of the function here. | |
211 | ||
212 | However, `va_start' should not use this argument. The way to find | |
213 | the end of the named arguments is with the built-in functions described | |
214 | below. | |
215 | ||
216 | `__builtin_saveregs ()' | |
217 | Use this built-in function to save the argument registers in | |
218 | memory so that the varargs mechanism can access them. Both ANSI | |
219 | and traditional versions of `va_start' must use | |
220 | `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see | |
221 | below) instead. | |
222 | ||
223 | On some machines, `__builtin_saveregs' is open-coded under the | |
224 | control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines, | |
225 | it calls a routine written in assembler language, found in | |
226 | `libgcc2.c'. | |
227 | ||
228 | Code generated for the call to `__builtin_saveregs' appears at the | |
229 | beginning of the function, as opposed to where the call to | |
230 | `__builtin_saveregs' is written, regardless of what the code is. | |
231 | This is because the registers must be saved before the function | |
232 | starts to use them for its own purposes. | |
233 | ||
234 | `__builtin_args_info (CATEGORY)' | |
235 | Use this built-in function to find the first anonymous arguments in | |
236 | registers. | |
237 | ||
238 | In general, a machine may have several categories of registers | |
239 | used for arguments, each for a particular category of data types. | |
240 | (For example, on some machines, floating-point registers are used | |
241 | for floating-point arguments while other arguments are passed in | |
242 | the general registers.) To make non-varargs functions use the | |
243 | proper calling convention, you have defined the `CUMULATIVE_ARGS' | |
244 | data type to record how many registers in each category have been | |
245 | used so far | |
246 | ||
247 | `__builtin_args_info' accesses the same data structure of type | |
248 | `CUMULATIVE_ARGS' after the ordinary argument layout is finished | |
249 | with it, with CATEGORY specifying which word to access. Thus, the | |
250 | value indicates the first unused register in a given category. | |
251 | ||
252 | Normally, you would use `__builtin_args_info' in the implementation | |
253 | of `va_start', accessing each category just once and storing the | |
254 | value in the `va_list' object. This is because `va_list' will | |
255 | have to update the values, and there is no way to alter the values | |
256 | accessed by `__builtin_args_info'. | |
257 | ||
258 | `__builtin_next_arg (LASTARG)' | |
259 | This is the equivalent of `__builtin_args_info', for stack | |
260 | arguments. It returns the address of the first anonymous stack | |
261 | argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns | |
262 | the address of the location above the first anonymous stack | |
263 | argument. Use it in `va_start' to initialize the pointer for | |
264 | fetching arguments from the stack. Also use it in `va_start' to | |
265 | verify that the second parameter LASTARG is the last named argument | |
266 | of the current function. | |
267 | ||
268 | `__builtin_classify_type (OBJECT)' | |
269 | Since each machine has its own conventions for which data types are | |
270 | passed in which kind of register, your implementation of `va_arg' | |
271 | has to embody these conventions. The easiest way to categorize the | |
272 | specified data type is to use `__builtin_classify_type' together | |
273 | with `sizeof' and `__alignof__'. | |
274 | ||
275 | `__builtin_classify_type' ignores the value of OBJECT, considering | |
276 | only its data type. It returns an integer describing what kind of | |
277 | type that is--integer, floating, pointer, structure, and so on. | |
278 | ||
279 | The file `typeclass.h' defines an enumeration that you can use to | |
280 | interpret the values of `__builtin_classify_type'. | |
281 | ||
282 | These machine description macros help implement varargs: | |
283 | ||
284 | `EXPAND_BUILTIN_SAVEREGS (ARGS)' | |
285 | If defined, is a C expression that produces the machine-specific | |
286 | code for a call to `__builtin_saveregs'. This code will be moved | |
287 | to the very beginning of the function, before any parameter access | |
288 | are made. The return value of this function should be an RTX that | |
289 | contains the value to use as the return of `__builtin_saveregs'. | |
290 | ||
291 | The argument ARGS is a `tree_list' containing the arguments that | |
292 | were passed to `__builtin_saveregs'. | |
293 | ||
294 | If this macro is not defined, the compiler will output an ordinary | |
295 | call to the library function `__builtin_saveregs'. | |
296 | ||
297 | `SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE,' | |
298 | PRETEND_ARGS_SIZE, SECOND_TIME) This macro offers an alternative | |
299 | to using `__builtin_saveregs' and defining the macro | |
300 | `EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous register | |
301 | arguments into the stack so that all the arguments appear to have | |
302 | been passed consecutively on the stack. Once this is done, you | |
303 | can use the standard implementation of varargs that works for | |
304 | machines that pass all their arguments on the stack. | |
305 | ||
306 | The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, | |
307 | containing the values that obtain after processing of the named | |
308 | arguments. The arguments MODE and TYPE describe the last named | |
309 | argument--its machine mode and its data type as a tree node. | |
310 | ||
311 | The macro implementation should do two things: first, push onto the | |
312 | stack all the argument registers *not* used for the named | |
313 | arguments, and second, store the size of the data thus pushed into | |
314 | the `int'-valued variable whose name is supplied as the argument | |
315 | PRETEND_ARGS_SIZE. The value that you store here will serve as | |
316 | additional offset for setting up the stack frame. | |
317 | ||
318 | Because you must generate code to push the anonymous arguments at | |
319 | compile time without knowing their data types, | |
320 | `SETUP_INCOMING_VARARGS' is only useful on machines that have just | |
321 | a single category of argument register and use it uniformly for | |
322 | all data types. | |
323 | ||
324 | If the argument SECOND_TIME is nonzero, it means that the | |
325 | arguments of the function are being analyzed for the second time. | |
326 | This happens for an inline function, which is not actually | |
327 | compiled until the end of the source file. The macro | |
328 | `SETUP_INCOMING_VARARGS' should not generate any instructions in | |
329 | this case. | |
330 | ||
331 | `STRICT_ARGUMENT_NAMING' | |
332 | Define this macro if the location where a function argument is | |
333 | passed depends on whether or not it is a named argument. | |
334 | ||
335 | This macro controls how the NAMED argument to `FUNCTION_ARG' is | |
336 | set for varargs and stdarg functions. With this macro defined, | |
337 | the NAMED argument is always true for named arguments, and false | |
338 | for unnamed arguments. If this is not defined, but | |
339 | `SETUP_INCOMING_VARARGS' is defined, then all arguments are | |
340 | treated as named. Otherwise, all named arguments except the last | |
341 | are treated as named. | |
342 | ||
343 | \1f | |
344 | File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros | |
345 | ||
346 | Trampolines for Nested Functions | |
347 | ================================ | |
348 | ||
349 | A "trampoline" is a small piece of code that is created at run time | |
350 | when the address of a nested function is taken. It normally resides on | |
351 | the stack, in the stack frame of the containing function. These macros | |
352 | tell GNU CC how to generate code to allocate and initialize a | |
353 | trampoline. | |
354 | ||
355 | The instructions in the trampoline must do two things: load a | |
356 | constant address into the static chain register, and jump to the real | |
357 | address of the nested function. On CISC machines such as the m68k, | |
358 | this requires two instructions, a move immediate and a jump. Then the | |
359 | two addresses exist in the trampoline as word-long immediate operands. | |
360 | On RISC machines, it is often necessary to load each address into a | |
361 | register in two parts. Then pieces of each address form separate | |
362 | immediate operands. | |
363 | ||
364 | The code generated to initialize the trampoline must store the | |
365 | variable parts--the static chain value and the function address--into | |
366 | the immediate operands of the instructions. On a CISC machine, this is | |
367 | simply a matter of copying each address to a memory reference at the | |
368 | proper offset from the start of the trampoline. On a RISC machine, it | |
369 | may be necessary to take out pieces of the address and store them | |
370 | separately. | |
371 | ||
372 | `TRAMPOLINE_TEMPLATE (FILE)' | |
373 | A C statement to output, on the stream FILE, assembler code for a | |
374 | block of data that contains the constant parts of a trampoline. | |
375 | This code should not include a label--the label is taken care of | |
376 | automatically. | |
377 | ||
378 | If you do not define this macro, it means no template is needed | |
379 | for the target. Do not define this macro on systems where the | |
380 | block move code to copy the trampoline into place would be larger | |
381 | than the code to generate it on the spot. | |
382 | ||
383 | `TRAMPOLINE_SECTION' | |
384 | The name of a subroutine to switch to the section in which the | |
385 | trampoline template is to be placed (*note Sections::.). The | |
386 | default is a value of `readonly_data_section', which places the | |
387 | trampoline in the section containing read-only data. | |
388 | ||
389 | `TRAMPOLINE_SIZE' | |
390 | A C expression for the size in bytes of the trampoline, as an | |
391 | integer. | |
392 | ||
393 | `TRAMPOLINE_ALIGNMENT' | |
394 | Alignment required for trampolines, in bits. | |
395 | ||
396 | If you don't define this macro, the value of `BIGGEST_ALIGNMENT' | |
397 | is used for aligning trampolines. | |
398 | ||
399 | `INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' | |
400 | A C statement to initialize the variable parts of a trampoline. | |
401 | ADDR is an RTX for the address of the trampoline; FNADDR is an RTX | |
402 | for the address of the nested function; STATIC_CHAIN is an RTX for | |
403 | the static chain value that should be passed to the function when | |
404 | it is called. | |
405 | ||
406 | `ALLOCATE_TRAMPOLINE (FP)' | |
407 | A C expression to allocate run-time space for a trampoline. The | |
408 | expression value should be an RTX representing a memory reference | |
409 | to the space for the trampoline. | |
410 | ||
411 | If this macro is not defined, by default the trampoline is | |
412 | allocated as a stack slot. This default is right for most | |
413 | machines. The exceptions are machines where it is impossible to | |
414 | execute instructions in the stack area. On such machines, you may | |
415 | have to implement a separate stack, using this macro in | |
416 | conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. | |
417 | ||
418 | FP points to a data structure, a `struct function', which | |
419 | describes the compilation status of the immediate containing | |
420 | function of the function which the trampoline is for. Normally | |
421 | (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for the | |
422 | trampoline is in the stack frame of this containing function. | |
423 | Other allocation strategies probably must do something analogous | |
424 | with this information. | |
425 | ||
426 | Implementing trampolines is difficult on many machines because they | |
427 | have separate instruction and data caches. Writing into a stack | |
428 | location fails to clear the memory in the instruction cache, so when | |
429 | the program jumps to that location, it executes the old contents. | |
430 | ||
431 | Here are two possible solutions. One is to clear the relevant parts | |
432 | of the instruction cache whenever a trampoline is set up. The other is | |
433 | to make all trampolines identical, by having them jump to a standard | |
434 | subroutine. The former technique makes trampoline execution faster; the | |
435 | latter makes initialization faster. | |
436 | ||
437 | To clear the instruction cache when a trampoline is initialized, | |
438 | define the following macros which describe the shape of the cache. | |
439 | ||
440 | `INSN_CACHE_SIZE' | |
441 | The total size in bytes of the cache. | |
442 | ||
443 | `INSN_CACHE_LINE_WIDTH' | |
444 | The length in bytes of each cache line. The cache is divided into | |
445 | cache lines which are disjoint slots, each holding a contiguous | |
446 | chunk of data fetched from memory. Each time data is brought into | |
447 | the cache, an entire line is read at once. The data loaded into a | |
448 | cache line is always aligned on a boundary equal to the line size. | |
449 | ||
450 | `INSN_CACHE_DEPTH' | |
451 | The number of alternative cache lines that can hold any particular | |
452 | memory location. | |
453 | ||
454 | Alternatively, if the machine has system calls or instructions to | |
455 | clear the instruction cache directly, you can define the following | |
456 | macro. | |
457 | ||
458 | `CLEAR_INSN_CACHE (BEG, END)' | |
459 | If defined, expands to a C expression clearing the *instruction | |
460 | cache* in the specified interval. If it is not defined, and the | |
461 | macro INSN_CACHE_SIZE is defined, some generic code is generated | |
462 | to clear the cache. The definition of this macro would typically | |
463 | be a series of `asm' statements. Both BEG and END are both pointer | |
464 | expressions. | |
465 | ||
466 | To use a standard subroutine, define the following macro. In | |
467 | addition, you must make sure that the instructions in a trampoline fill | |
468 | an entire cache line with identical instructions, or else ensure that | |
469 | the beginning of the trampoline code is always aligned at the same | |
470 | point in its cache line. Look in `m68k.h' as a guide. | |
471 | ||
472 | `TRANSFER_FROM_TRAMPOLINE' | |
473 | Define this macro if trampolines need a special subroutine to do | |
474 | their work. The macro should expand to a series of `asm' | |
475 | statements which will be compiled with GNU CC. They go in a | |
476 | library function named `__transfer_from_trampoline'. | |
477 | ||
478 | If you need to avoid executing the ordinary prologue code of a | |
479 | compiled C function when you jump to the subroutine, you can do so | |
480 | by placing a special label of your own in the assembler code. Use | |
481 | one `asm' statement to generate an assembler label, and another to | |
482 | make the label global. Then trampolines can use that label to | |
483 | jump directly to your special assembler code. | |
484 | ||
485 | \1f | |
486 | File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros | |
487 | ||
488 | Implicit Calls to Library Routines | |
489 | ================================== | |
490 | ||
491 | Here is an explanation of implicit calls to library routines. | |
492 | ||
493 | `MULSI3_LIBCALL' | |
494 | A C string constant giving the name of the function to call for | |
495 | multiplication of one signed full-word by another. If you do not | |
496 | define this macro, the default name is used, which is `__mulsi3', | |
497 | a function defined in `libgcc.a'. | |
498 | ||
499 | `DIVSI3_LIBCALL' | |
500 | A C string constant giving the name of the function to call for | |
501 | division of one signed full-word by another. If you do not define | |
502 | this macro, the default name is used, which is `__divsi3', a | |
503 | function defined in `libgcc.a'. | |
504 | ||
505 | `UDIVSI3_LIBCALL' | |
506 | A C string constant giving the name of the function to call for | |
507 | division of one unsigned full-word by another. If you do not | |
508 | define this macro, the default name is used, which is `__udivsi3', | |
509 | a function defined in `libgcc.a'. | |
510 | ||
511 | `MODSI3_LIBCALL' | |
512 | A C string constant giving the name of the function to call for the | |
513 | remainder in division of one signed full-word by another. If you | |
514 | do not define this macro, the default name is used, which is | |
515 | `__modsi3', a function defined in `libgcc.a'. | |
516 | ||
517 | `UMODSI3_LIBCALL' | |
518 | A C string constant giving the name of the function to call for the | |
519 | remainder in division of one unsigned full-word by another. If | |
520 | you do not define this macro, the default name is used, which is | |
521 | `__umodsi3', a function defined in `libgcc.a'. | |
522 | ||
523 | `MULDI3_LIBCALL' | |
524 | A C string constant giving the name of the function to call for | |
525 | multiplication of one signed double-word by another. If you do not | |
526 | define this macro, the default name is used, which is `__muldi3', | |
527 | a function defined in `libgcc.a'. | |
528 | ||
529 | `DIVDI3_LIBCALL' | |
530 | A C string constant giving the name of the function to call for | |
531 | division of one signed double-word by another. If you do not | |
532 | define this macro, the default name is used, which is `__divdi3', a | |
533 | function defined in `libgcc.a'. | |
534 | ||
535 | `UDIVDI3_LIBCALL' | |
536 | A C string constant giving the name of the function to call for | |
537 | division of one unsigned full-word by another. If you do not | |
538 | define this macro, the default name is used, which is `__udivdi3', | |
539 | a function defined in `libgcc.a'. | |
540 | ||
541 | `MODDI3_LIBCALL' | |
542 | A C string constant giving the name of the function to call for the | |
543 | remainder in division of one signed double-word by another. If | |
544 | you do not define this macro, the default name is used, which is | |
545 | `__moddi3', a function defined in `libgcc.a'. | |
546 | ||
547 | `UMODDI3_LIBCALL' | |
548 | A C string constant giving the name of the function to call for the | |
549 | remainder in division of one unsigned full-word by another. If | |
550 | you do not define this macro, the default name is used, which is | |
551 | `__umoddi3', a function defined in `libgcc.a'. | |
552 | ||
553 | `INIT_TARGET_OPTABS' | |
554 | Define this macro as a C statement that declares additional library | |
555 | routines renames existing ones. `init_optabs' calls this macro | |
556 | after initializing all the normal library routines. | |
557 | ||
558 | `TARGET_EDOM' | |
559 | The value of `EDOM' on the target machine, as a C integer constant | |
560 | expression. If you don't define this macro, GNU CC does not | |
561 | attempt to deposit the value of `EDOM' into `errno' directly. | |
562 | Look in `/usr/include/errno.h' to find the value of `EDOM' on your | |
563 | system. | |
564 | ||
565 | If you do not define `TARGET_EDOM', then compiled code reports | |
566 | domain errors by calling the library function and letting it | |
567 | report the error. If mathematical functions on your system use | |
568 | `matherr' when there is an error, then you should leave | |
569 | `TARGET_EDOM' undefined so that `matherr' is used normally. | |
570 | ||
571 | `GEN_ERRNO_RTX' | |
572 | Define this macro as a C expression to create an rtl expression | |
573 | that refers to the global "variable" `errno'. (On certain systems, | |
574 | `errno' may not actually be a variable.) If you don't define this | |
575 | macro, a reasonable default is used. | |
576 | ||
577 | `TARGET_MEM_FUNCTIONS' | |
578 | Define this macro if GNU CC should generate calls to the System V | |
579 | (and ANSI C) library functions `memcpy' and `memset' rather than | |
580 | the BSD functions `bcopy' and `bzero'. | |
581 | ||
582 | `LIBGCC_NEEDS_DOUBLE' | |
583 | Define this macro if only `float' arguments cannot be passed to | |
584 | library routines (so they must be converted to `double'). This | |
585 | macro affects both how library calls are generated and how the | |
586 | library routines in `libgcc1.c' accept their arguments. It is | |
587 | useful on machines where floating and fixed point arguments are | |
588 | passed differently, such as the i860. | |
589 | ||
590 | `FLOAT_ARG_TYPE' | |
591 | Define this macro to override the type used by the library | |
592 | routines to pick up arguments of type `float'. (By default, they | |
593 | use a union of `float' and `int'.) | |
594 | ||
595 | The obvious choice would be `float'--but that won't work with | |
596 | traditional C compilers that expect all arguments declared as | |
597 | `float' to arrive as `double'. To avoid this conversion, the | |
598 | library routines ask for the value as some other type and then | |
599 | treat it as a `float'. | |
600 | ||
601 | On some systems, no other type will work for this. For these | |
602 | systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force | |
603 | conversion of the values `double' before they are passed. | |
604 | ||
605 | `FLOATIFY (PASSED-VALUE)' | |
606 | Define this macro to override the way library routines redesignate | |
607 | a `float' argument as a `float' instead of the type it was passed | |
608 | as. The default is an expression which takes the `float' field of | |
609 | the union. | |
610 | ||
611 | `FLOAT_VALUE_TYPE' | |
612 | Define this macro to override the type used by the library | |
613 | routines to return values that ought to have type `float'. (By | |
614 | default, they use `int'.) | |
615 | ||
616 | The obvious choice would be `float'--but that won't work with | |
617 | traditional C compilers gratuitously convert values declared as | |
618 | `float' into `double'. | |
619 | ||
620 | `INTIFY (FLOAT-VALUE)' | |
621 | Define this macro to override the way the value of a | |
622 | `float'-returning library routine should be packaged in order to | |
623 | return it. These functions are actually declared to return type | |
624 | `FLOAT_VALUE_TYPE' (normally `int'). | |
625 | ||
626 | These values can't be returned as type `float' because traditional | |
627 | C compilers would gratuitously convert the value to a `double'. | |
628 | ||
629 | A local variable named `intify' is always available when the macro | |
630 | `INTIFY' is used. It is a union of a `float' field named `f' and | |
631 | a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. | |
632 | ||
633 | If you don't define this macro, the default definition works by | |
634 | copying the value through that union. | |
635 | ||
636 | `nongcc_SI_type' | |
637 | Define this macro as the name of the data type corresponding to | |
638 | `SImode' in the system's own C compiler. | |
639 | ||
640 | You need not define this macro if that type is `long int', as it | |
641 | usually is. | |
642 | ||
643 | `nongcc_word_type' | |
644 | Define this macro as the name of the data type corresponding to the | |
645 | word_mode in the system's own C compiler. | |
646 | ||
647 | You need not define this macro if that type is `long int', as it | |
648 | usually is. | |
649 | ||
650 | `perform_...' | |
651 | Define these macros to supply explicit C statements to carry out | |
652 | various arithmetic operations on types `float' and `double' in the | |
653 | library routines in `libgcc1.c'. See that file for a full list of | |
654 | these macros and their arguments. | |
655 | ||
656 | On most machines, you don't need to define any of these macros, | |
657 | because the C compiler that comes with the system takes care of | |
658 | doing them. | |
659 | ||
660 | `NEXT_OBJC_RUNTIME' | |
661 | Define this macro to generate code for Objective C message sending | |
662 | using the calling convention of the NeXT system. This calling | |
663 | convention involves passing the object, the selector and the | |
664 | method arguments all at once to the method-lookup library function. | |
665 | ||
666 | The default calling convention passes just the object and the | |
667 | selector to the lookup function, which returns a pointer to the | |
668 | method. | |
669 | ||
670 | \1f | |
671 | File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros | |
672 | ||
673 | Addressing Modes | |
674 | ================ | |
675 | ||
676 | This is about addressing modes. | |
677 | ||
678 | `HAVE_POST_INCREMENT' | |
679 | Define this macro if the machine supports post-increment | |
680 | addressing. | |
681 | ||
682 | `HAVE_PRE_INCREMENT' | |
683 | `HAVE_POST_DECREMENT' | |
684 | `HAVE_PRE_DECREMENT' | |
685 | Similar for other kinds of addressing. | |
686 | ||
687 | `CONSTANT_ADDRESS_P (X)' | |
688 | A C expression that is 1 if the RTX X is a constant which is a | |
689 | valid address. On most machines, this can be defined as | |
690 | `CONSTANT_P (X)', but a few machines are more restrictive in which | |
691 | constant addresses are supported. | |
692 | ||
693 | `CONSTANT_P' accepts integer-values expressions whose values are | |
694 | not explicitly known, such as `symbol_ref', `label_ref', and | |
695 | `high' expressions and `const' arithmetic expressions, in addition | |
696 | to `const_int' and `const_double' expressions. | |
697 | ||
698 | `MAX_REGS_PER_ADDRESS' | |
699 | A number, the maximum number of registers that can appear in a | |
700 | valid memory address. Note that it is up to you to specify a | |
701 | value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' | |
702 | would ever accept. | |
703 | ||
704 | `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' | |
705 | A C compound statement with a conditional `goto LABEL;' executed | |
706 | if X (an RTX) is a legitimate memory address on the target machine | |
707 | for a memory operand of mode MODE. | |
708 | ||
709 | It usually pays to define several simpler macros to serve as | |
710 | subroutines for this one. Otherwise it may be too complicated to | |
711 | understand. | |
712 | ||
713 | This macro must exist in two variants: a strict variant and a | |
714 | non-strict one. The strict variant is used in the reload pass. It | |
715 | must be defined so that any pseudo-register that has not been | |
716 | allocated a hard register is considered a memory reference. In | |
717 | contexts where some kind of register is required, a pseudo-register | |
718 | with no hard register must be rejected. | |
719 | ||
720 | The non-strict variant is used in other passes. It must be | |
721 | defined to accept all pseudo-registers in every context where some | |
722 | kind of register is required. | |
723 | ||
724 | Compiler source files that want to use the strict variant of this | |
725 | macro define the macro `REG_OK_STRICT'. You should use an `#ifdef | |
726 | REG_OK_STRICT' conditional to define the strict variant in that | |
727 | case and the non-strict variant otherwise. | |
728 | ||
729 | Subroutines to check for acceptable registers for various purposes | |
730 | (one for base registers, one for index registers, and so on) are | |
731 | typically among the subroutines used to define | |
732 | `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros | |
733 | need have two variants; the higher levels of macros may be the | |
734 | same whether strict or not. | |
735 | ||
736 | Normally, constant addresses which are the sum of a `symbol_ref' | |
737 | and an integer are stored inside a `const' RTX to mark them as | |
738 | constant. Therefore, there is no need to recognize such sums | |
739 | specifically as legitimate addresses. Normally you would simply | |
740 | recognize any `const' as legitimate. | |
741 | ||
742 | Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant | |
743 | sums that are not marked with `const'. It assumes that a naked | |
744 | `plus' indicates indexing. If so, then you *must* reject such | |
745 | naked constant sums as illegitimate addresses, so that none of | |
746 | them will be given to `PRINT_OPERAND_ADDRESS'. | |
747 | ||
748 | On some machines, whether a symbolic address is legitimate depends | |
749 | on the section that the address refers to. On these machines, | |
750 | define the macro `ENCODE_SECTION_INFO' to store the information | |
751 | into the `symbol_ref', and then check for it here. When you see a | |
752 | `const', you will have to look inside it to find the `symbol_ref' | |
753 | in order to determine the section. *Note Assembler Format::. | |
754 | ||
755 | The best way to modify the name string is by adding text to the | |
756 | beginning, with suitable punctuation to prevent any ambiguity. | |
757 | Allocate the new name in `saveable_obstack'. You will have to | |
758 | modify `ASM_OUTPUT_LABELREF' to remove and decode the added text | |
759 | and output the name accordingly, and define `STRIP_NAME_ENCODING' | |
760 | to access the original name string. | |
761 | ||
762 | You can check the information stored here into the `symbol_ref' in | |
763 | the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and | |
764 | `PRINT_OPERAND_ADDRESS'. | |
765 | ||
766 | `REG_OK_FOR_BASE_P (X)' | |
767 | A C expression that is nonzero if X (assumed to be a `reg' RTX) is | |
768 | valid for use as a base register. For hard registers, it should | |
769 | always accept those which the hardware permits and reject the | |
770 | others. Whether the macro accepts or rejects pseudo registers | |
771 | must be controlled by `REG_OK_STRICT' as described above. This | |
772 | usually requires two variant definitions, of which `REG_OK_STRICT' | |
773 | controls the one actually used. | |
774 | ||
775 | `REG_MODE_OK_FOR_BASE_P (X, MODE)' | |
776 | A C expression that is just like `REG_OK_FOR_BASE_P', except that | |
777 | that expression may examine the mode of the memory reference in | |
778 | MODE. You should define this macro if the mode of the memory | |
779 | reference affects whether a register may be used as a base | |
780 | register. If you define this macro, the compiler will use it | |
781 | instead of `REG_OK_FOR_BASE_P'. | |
782 | ||
783 | `REG_OK_FOR_INDEX_P (X)' | |
784 | A C expression that is nonzero if X (assumed to be a `reg' RTX) is | |
785 | valid for use as an index register. | |
786 | ||
787 | The difference between an index register and a base register is | |
788 | that the index register may be scaled. If an address involves the | |
789 | sum of two registers, neither one of them scaled, then either one | |
790 | may be labeled the "base" and the other the "index"; but whichever | |
791 | labeling is used must fit the machine's constraints of which | |
792 | registers may serve in each capacity. The compiler will try both | |
793 | labelings, looking for one that is valid, and will reload one or | |
794 | both registers only if neither labeling works. | |
795 | ||
796 | `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' | |
797 | A C compound statement that attempts to replace X with a valid | |
798 | memory address for an operand of mode MODE. WIN will be a C | |
799 | statement label elsewhere in the code; the macro definition may use | |
800 | ||
801 | GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); | |
802 | ||
803 | to avoid further processing if the address has become legitimate. | |
804 | ||
805 | X will always be the result of a call to `break_out_memory_refs', | |
806 | and OLDX will be the operand that was given to that function to | |
807 | produce X. | |
808 | ||
809 | The code generated by this macro should not alter the substructure | |
810 | of X. If it transforms X into a more legitimate form, it should | |
811 | assign X (which will always be a C variable) a new value. | |
812 | ||
813 | It is not necessary for this macro to come up with a legitimate | |
814 | address. The compiler has standard ways of doing so in all cases. | |
815 | In fact, it is safe for this macro to do nothing. But often a | |
816 | machine-dependent strategy can generate better code. | |
817 | ||
818 | `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' | |
819 | A C statement or compound statement with a conditional `goto | |
820 | LABEL;' executed if memory address X (an RTX) can have different | |
821 | meanings depending on the machine mode of the memory reference it | |
822 | is used for or if the address is valid for some modes but not | |
823 | others. | |
824 | ||
825 | Autoincrement and autodecrement addresses typically have | |
826 | mode-dependent effects because the amount of the increment or | |
827 | decrement is the size of the operand being addressed. Some | |
828 | machines have other mode-dependent addresses. Many RISC machines | |
829 | have no mode-dependent addresses. | |
830 | ||
831 | You may assume that ADDR is a valid address for the machine. | |
832 | ||
833 | `LEGITIMATE_CONSTANT_P (X)' | |
834 | A C expression that is nonzero if X is a legitimate constant for | |
835 | an immediate operand on the target machine. You can assume that X | |
836 | satisfies `CONSTANT_P', so you need not check this. In fact, `1' | |
837 | is a suitable definition for this macro on machines where anything | |
838 | `CONSTANT_P' is valid. | |
839 | ||
840 | \1f | |
841 | File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros | |
842 | ||
843 | Condition Code Status | |
844 | ===================== | |
845 | ||
846 | This describes the condition code status. | |
847 | ||
848 | The file `conditions.h' defines a variable `cc_status' to describe | |
849 | how the condition code was computed (in case the interpretation of the | |
850 | condition code depends on the instruction that it was set by). This | |
851 | variable contains the RTL expressions on which the condition code is | |
852 | currently based, and several standard flags. | |
853 | ||
854 | Sometimes additional machine-specific flags must be defined in the | |
855 | machine description header file. It can also add additional | |
856 | machine-specific information by defining `CC_STATUS_MDEP'. | |
857 | ||
858 | `CC_STATUS_MDEP' | |
859 | C code for a data type which is used for declaring the `mdep' | |
860 | component of `cc_status'. It defaults to `int'. | |
861 | ||
862 | This macro is not used on machines that do not use `cc0'. | |
863 | ||
864 | `CC_STATUS_MDEP_INIT' | |
865 | A C expression to initialize the `mdep' field to "empty". The | |
866 | default definition does nothing, since most machines don't use the | |
867 | field anyway. If you want to use the field, you should probably | |
868 | define this macro to initialize it. | |
869 | ||
870 | This macro is not used on machines that do not use `cc0'. | |
871 | ||
872 | `NOTICE_UPDATE_CC (EXP, INSN)' | |
873 | A C compound statement to set the components of `cc_status' | |
874 | appropriately for an insn INSN whose body is EXP. It is this | |
875 | macro's responsibility to recognize insns that set the condition | |
876 | code as a byproduct of other activity as well as those that | |
877 | explicitly set `(cc0)'. | |
878 | ||
879 | This macro is not used on machines that do not use `cc0'. | |
880 | ||
881 | If there are insns that do not set the condition code but do alter | |
882 | other machine registers, this macro must check to see whether they | |
883 | invalidate the expressions that the condition code is recorded as | |
884 | reflecting. For example, on the 68000, insns that store in address | |
885 | registers do not set the condition code, which means that usually | |
886 | `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. | |
887 | But suppose that the previous insn set the condition code based | |
888 | on location `a4@(102)' and the current insn stores a new value in | |
889 | `a4'. Although the condition code is not changed by this, it will | |
890 | no longer be true that it reflects the contents of `a4@(102)'. | |
891 | Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case | |
892 | to say that nothing is known about the condition code value. | |
893 | ||
894 | The definition of `NOTICE_UPDATE_CC' must be prepared to deal with | |
895 | the results of peephole optimization: insns whose patterns are | |
896 | `parallel' RTXs containing various `reg', `mem' or constants which | |
897 | are just the operands. The RTL structure of these insns is not | |
898 | sufficient to indicate what the insns actually do. What | |
899 | `NOTICE_UPDATE_CC' should do when it sees one is just to run | |
900 | `CC_STATUS_INIT'. | |
901 | ||
902 | A possible definition of `NOTICE_UPDATE_CC' is to call a function | |
903 | that looks at an attribute (*note Insn Attributes::.) named, for | |
904 | example, `cc'. This avoids having detailed information about | |
905 | patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. | |
906 | ||
907 | `EXTRA_CC_MODES' | |
908 | A list of names to be used for additional modes for condition code | |
909 | values in registers (*note Jump Patterns::.). These names are | |
910 | added to `enum machine_mode' and all have class `MODE_CC'. By | |
911 | convention, they should start with `CC' and end with `mode'. | |
912 | ||
913 | You should only define this macro if your machine does not use | |
914 | `cc0' and only if additional modes are required. | |
915 | ||
916 | `EXTRA_CC_NAMES' | |
917 | A list of C strings giving the names for the modes listed in | |
918 | `EXTRA_CC_MODES'. For example, the Sparc defines this macro and | |
919 | `EXTRA_CC_MODES' as | |
920 | ||
921 | #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode | |
922 | #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE" | |
923 | ||
924 | This macro is not required if `EXTRA_CC_MODES' is not defined. | |
925 | ||
926 | `SELECT_CC_MODE (OP, X, Y)' | |
927 | Returns a mode from class `MODE_CC' to be used when comparison | |
928 | operation code OP is applied to rtx X and Y. For example, on the | |
929 | Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. | |
930 | for a description of the reason for this definition) | |
931 | ||
932 | #define SELECT_CC_MODE(OP,X,Y) \ | |
933 | (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ | |
934 | ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ | |
935 | : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ | |
936 | || GET_CODE (X) == NEG) \ | |
937 | ? CC_NOOVmode : CCmode)) | |
938 | ||
939 | You need not define this macro if `EXTRA_CC_MODES' is not defined. | |
940 | ||
941 | `CANONICALIZE_COMPARISON (CODE, OP0, OP1)' | |
942 | One some machines not all possible comparisons are defined, but | |
943 | you can convert an invalid comparison into a valid one. For | |
944 | example, the Alpha does not have a `GT' comparison, but you can | |
945 | use an `LT' comparison instead and swap the order of the operands. | |
946 | ||
947 | On such machines, define this macro to be a C statement to do any | |
948 | required conversions. CODE is the initial comparison code and OP0 | |
949 | and OP1 are the left and right operands of the comparison, | |
950 | respectively. You should modify CODE, OP0, and OP1 as required. | |
951 | ||
952 | GNU CC will not assume that the comparison resulting from this | |
953 | macro is valid but will see if the resulting insn matches a | |
954 | pattern in the `md' file. | |
955 | ||
956 | You need not define this macro if it would never change the | |
957 | comparison code or operands. | |
958 | ||
959 | `REVERSIBLE_CC_MODE (MODE)' | |
960 | A C expression whose value is one if it is always safe to reverse a | |
961 | comparison whose mode is MODE. If `SELECT_CC_MODE' can ever | |
962 | return MODE for a floating-point inequality comparison, then | |
963 | `REVERSIBLE_CC_MODE (MODE)' must be zero. | |
964 | ||
965 | You need not define this macro if it would always returns zero or | |
966 | if the floating-point format is anything other than | |
967 | `IEEE_FLOAT_FORMAT'. For example, here is the definition used on | |
968 | the Sparc, where floating-point inequality comparisons are always | |
969 | given `CCFPEmode': | |
970 | ||
971 | #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) | |
972 |