1 | This is Info file gcc.info, produced by Makeinfo version 1.67 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, 1998 |
---|
10 | Free 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 | |
---|
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 | distinguishes 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' distinguishes 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 | |
---|
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 | |
---|
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 | |
---|
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 | |
---|
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 | |
---|
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 | |
---|