![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to internals-5 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file internals, produced by Makeinfo, -*- Text -*-
2: from input file internals.texinfo.
3:
4:
5:
6: This file documents the internals of the GNU compiler.
7:
8: Copyright (C) 1988 Free Software Foundation, Inc.
9:
10: Permission is granted to make and distribute verbatim copies of
11: this manual provided the copyright notice and this permission notice
12: are preserved on all copies.
13:
14: Permission is granted to copy and distribute modified versions of this
15: manual under the conditions for verbatim copying, provided also that the
16: section entitled ``GNU CC General Public License'' is included exactly as
17: in the original, and provided that the entire resulting derived work is
18: distributed under the terms of a permission notice identical to this one.
19:
20: Permission is granted to copy and distribute translations of this manual
21: into another language, under the above conditions for modified versions,
22: except that the section entitled ``GNU CC General Public License'' and
23: this permission notice may be included in translations approved by the
24: Free Software Foundation instead of in the original English.
25:
26:
27:
28:
29:
30:
31: File: internals, Node: Peephole Definitions, Next: Expander Definitions, Prev: Jump Patterns, Up: Machine Desc
32:
33: Defining Machine-Specific Peephole Optimizers
34: =============================================
35:
36: In addition to instruction patterns the `md' file may contain definitions
37: of machine-specific peephole optimizations.
38:
39: The combiner does not notice certain peephole optimizations when the data
40: flow in the program does not suggest that it should try them. For example,
41: sometimes two consecutive insns related in purpose can be combined even
42: though the second one does not appear to use a register computed in the
43: first one. A machine-specific peephole optimizer can detect such
44: opportunities.
45:
46: A definition looks like this:
47:
48: (define_peephole
49: [INSN-PATTERN-1
50: INSN-PATTERN-2
51: ...]
52: "CONDITION"
53: "TEMPLATE")
54:
55:
56: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
57: consecutive instructions. The optimization applies to a sequence of
58: instructions when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2
59: matches the next, and so on.
60:
61: INSN-PATTERN-1 and so on look *almost* like the second operand of
62: `define_insn'. There is one important difference: this pattern is an RTX,
63: not a vector. If the `define_insn' pattern would be a vector of one
64: element, the INSN-PATTERN should be just that element, no vector. If the
65: `define_insn' pattern would have multiple elements then the INSN-PATTERN
66: must place the vector inside an explicit `parallel' RTX.
67:
68: The operands of the instructions are matched with `match_operands' and
69: `match_dup', as usual). What is not usual is that the operand numbers
70: apply to all the instruction patterns in the definition. So, you can check
71: for identical operands in two instructions by using `match_operand' in one
72: instruction and `match_dup' in the other.
73:
74: The operand constraints used in `match_operand' patterns do not have any
75: direct effect on the applicability of the optimization, but they will be
76: validated afterward, so write constraints that are sure to fit whenever the
77: optimization is applied. It is safe to use `"g"' for each operand.
78:
79: Once a sequence of instructions matches the patterns, the CONDITION is
80: checked. This is a C expression which makes the final decision whether to
81: perform the optimization (do so if the expression is nonzero). If
82: CONDITION is omitted (in other words, the string is empty) then the
83: optimization is applied to every sequence of instructions that matches the
84: patterns.
85:
86: The defined peephole optimizations are applied after register allocation is
87: complete. Therefore, the optimizer can check which operands have ended up
88: in which kinds of registers, just by looking at the operands.
89:
90: The way to refer to the operands in CONDITION is to write `operands[I]' for
91: operand number I (as matched by `(match_operand I ...)'). Use the variable
92: `insn' to refer to the last of the insns being matched; use `PREV_INSN' to
93: find the preceding insns (but be careful to skip over any `note' insns that
94: intervene).
95:
96: When optimizing computations with intermediate results, you can use
97: CONDITION to match only when the intermediate results are not used
98: elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN is
99: the insn in which you expect the value to be used for the last time (from
100: the value of `insn', together with use of `PREV_INSN'), and OP is the
101: intermediate value (from `operands[I]').
102:
103: Applying the optimization means replacing the sequence of instructions with
104: one new instruction. The TEMPLATE controls ultimate output of assembler
105: code for this combined instruction. It works exactly like the template of
106: a `define_insn'. Operand numbers in this template are the same ones used
107: in matching the original sequence of instructions.
108:
109: The result of a defined peephole optimizer does not need to match any of
110: the instruction patterns, and it does not have an opportunity to match
111: them. The peephole optimizer definition itself serves as the instruction
112: pattern to control how the instruction is output.
113:
114: Defined peephole optimizers are run in the last jump optimization pass, so
115: the instructions they produce are never combined or rearranged
116: automatically in any way.
117:
118: Here is an example, taken from the 68000 machine description:
119:
120: (define_peephole
121: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
122: (set (match_operand:DF 0 "register_operand" "f")
123: (match_operand:DF 1 "register_operand" "ad"))]
124: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
125: "*
126: {
127: rtx xoperands[2];
128: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
129: #ifdef MOTOROLA
130: output_asm_insn (\"move.l %1,(sp)\", xoperands);
131: output_asm_insn (\"move.l %1,-(sp)\", operands);
132: return \"fmove.d (sp)+,%0\";
133: #else
134: output_asm_insn (\"movel %1,sp@\", xoperands);
135: output_asm_insn (\"movel %1,sp@-\", operands);
136: return \"fmoved sp@+,%0\";
137: #endif
138: }
139: ")
140:
141:
142: The effect of this optimization is to change
143:
144: jbsr _foobar
145: addql #4,sp
146: movel d1,sp@-
147: movel d0,sp@-
148: fmoved sp@+,fp0
149:
150:
151: into
152:
153: jbsr _foobar
154: movel d1,sp@
155: movel d0,sp@-
156: fmoved sp@+,fp0
157:
158:
159:
160: File: internals, Node: Expander Definitions, Prev: Peephole Definitions, Up: Machine Desc
161:
162: Defining RTL Sequences for Code Generation
163: ==========================================
164:
165: On some target machines, some standard pattern names for RTL generation
166: cannot be handled with single insn, but a sequence of RTL insns can
167: represent them. For these target machines, you can write a `define_expand'
168: to specify how to generate the sequence of RTL.
169:
170: A `define_expand' is an RTL expression that looks almost like a
171: `define_insn'; but, unlike the latter, a `define_expand' is used only for
172: RTL generation and it can produce more than one RTL insn.
173:
174: A `define_expand' RTX has four operands:
175:
176: * The name. Each `define_expand' must have a name, since the only use
177: for it is to refer to it by name.
178:
179: * The RTL template. This is just like the RTL template for a
180: `define_peephole' in that it is a vector of RTL expressions each being
181: one insn.
182:
183: * The condition, a string containing a C expression. This expression is
184: used to express how the availability of this pattern depends on
185: subclasses of target machine, selected by command-line options when
186: GNU CC is run. This is just like the condition of a `define_insn'
187: that has a standard name.
188:
189: * The preparation statements, a string containing zero or more C
190: statements which are to be executed before RTL code is generated from
191: the RTL template.
192:
193: Usually these statements prepare temporary registers for use as
194: internal operands in the RTL template, but they can also generate RTL
195: insns directly by calling routines such as `emit_insn', etc. Any such
196: insns precede the ones that come from the RTL template.
197:
198: The RTL template, in addition to controlling generation of RTL insns, also
199: describes the operands that need to be specified when this pattern is used.
200: In particular, it gives a predicate for each operand.
201:
202: A true operand, which need to be specified in order to generate RTL from
203: the pattern, should be described with a `match_operand' in its first
204: occurrence in the RTL template. This enters information on the operand's
205: predicate into the tables that record such things. GNU CC uses the
206: information to preload the operand into a register if that is required for
207: valid RTL code. If the operand is referred to more than once, subsequent
208: references should use `match_dup'.
209:
210: The RTL template may also refer to internal ``operands'' which are
211: temporary registers or labels used only within the sequence made by the
212: `define_expand'. Internal operands are substituted into the RTL template
213: with `match_dup', never with `match_operand'. The values of the internal
214: operands are not passed in as arguments by the compiler when it requests
215: use of this pattern. Instead, they are computed within the pattern, in the
216: preparation statements. These statements compute the values and store them
217: into the appropriate elements of `operands' so that `match_dup' can find
218: them.
219:
220: There are two special macros defined for use in the preparation statements:
221: `DONE' and `FAIL'. Use them with a following semicolon, as a statement.
222:
223: `DONE'
224: Use the `DONE' macro to end RTL generation for the pattern. The only
225: RTL insns resulting from the pattern on this occasion will be those
226: already emitted by explicit calls to `emit_insn' within the
227: preparation statements; the RTL template will not be generated.
228:
229: `FAIL'
230: Make the pattern fail on this occasion. When a pattern fails, it
231: means that the pattern was not truly available. The calling routines
232: in the compiler will try other strategies for code generation using
233: other patterns.
234:
235: Failure is currently supported only for binary operations (addition,
236: multiplication, shifting, etc.).
237:
238: Do not emit any insns explicitly with `emit_insn' before failing.
239:
240: Here is an example, the definition of left-shift for the SPUR chip:
241:
242: (define_expand "ashlsi3"
243: [(set (match_operand:SI 0 "register_operand" "")
244: (ashift:SI
245: (match_operand:SI 1 "register_operand" "")
246: (match_operand:SI 2 "nonmemory_operand" "")))]
247: ""
248: "
249: {
250: if (GET_CODE (operands[2]) != CONST_INT
251: || (unsigned) INTVAL (operands[2]) > 3)
252: FAIL;
253: }")
254:
255:
256: This example uses `define_expand' so that it can generate an RTL insn for
257: shifting when the shift-count is in the supported range of 0 to 3 but fail
258: in other cases where machine insns aren't available. When it fails, the
259: compiler tries another strategy using different patterns (such as, a
260: library call).
261:
262: If the compiler were able to handle nontrivial condition-strings in
263: patterns with names, then there would be possible to use a `define_insn' in
264: that case. Here is another case (zero-extension on the 68000) which makes
265: more use of the power of `define_expand':
266:
267: (define_expand "zero_extendhisi2"
268: [(set (match_operand:SI 0 "general_operand" "")
269: (const_int 0))
270: (set (strict_low_part
271: (subreg:HI
272: (match_operand:SI 0 "general_operand" "")
273: 0))
274: (match_operand:HI 1 "general_operand" ""))]
275: ""
276: "operands[1] = make_safe_from (operands[1], operands[0]);")
277:
278:
279: Here two RTL insns are generated, one to clear the entire output operand
280: and the other to copy the input operand into its low half. This sequence
281: is incorrect if the input operand refers to [the old value of] the output
282: operand, so the preparation statement makes sure this isn't so. The
283: function `make_safe_from' copies the `operands[1]' into a temporary
284: register if it refers to `operands[0]'. It does this by emitting another
285: RTL insn.
286:
287: Finally, a third example shows the use of an internal operand.
288: Zero-extension on the SPUR chip is done by `and'-ing the result against a
289: halfword mask. But this mask cannot be represented by a `const_int'
290: because the constant value is too large to be legitimate on this machine.
291: So it must be copied into a register with `force_reg' and then the register
292: used in the `and'.
293:
294: (define_expand "zero_extendhisi2"
295: [(set (match_operand:SI 0 "register_operand" "")
296: (and:SI (subreg:SI
297: (match_operand:HI 1 "register_operand" "")
298: 0)
299: (match_dup 2)))]
300: ""
301: "operands[2]
302: = force_reg (SImode, gen_rtx (CONST_INT,
303: VOIDmode, 65535)); ")
304:
305:
306:
307: File: internals, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top
308:
309: Machine Description Macros
310: **************************
311:
312: The other half of the machine description is a C header file conventionally
313: given the name `tm-MACHINE.h'. The file `tm.h' should be a link to it.
314: The header file `config.h' includes `tm.h' and most compiler source files
315: include `config.h'.
316:
317:
318: * Menu:
319:
320: * Run-time Target:: Defining -m options like -m68000 and -m68020.
321: * Storage Layout:: Defining sizes and alignments of data types.
322: * Registers:: Naming and describing the hardware registers.
323: * Register Classes:: Defining the classes of hardware registers.
324: * Stack Layout:: Defining which way the stack grows and by how much.
325: * Library Names:: Specifying names of subroutines to call automatically.
326: * Addressing Modes:: Defining addressing modes valid for memory operands.
327: * Condition Code:: Defining how insns update the condition code.
328: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
329: * Misc:: Everything else.
330:
331:
332:
333: File: internals, Node: Run-time Target, Next: Storage Layout, Prev: Machine Macros, Up: Machine Macros
334:
335: Run-time Target Specification
336: =============================
337:
338: `CPP_PREDEFINES'
339: Define this to be a string constant containing `-D' options to define
340: the predefined macros that identify this machine and system.
341:
342: For example, on the Sun, one can use the value
343:
344: "-Dmc68000 -Dsun -Dunix"
345:
346:
347: `extern int target_flags;'
348: This declaration should be present.
349:
350: `TARGET_...'
351: This series of macros is to allow compiler command arguments to enable
352: or disable the use of optional features of the target machine. For
353: example, one machine description serves both the 68000 and the 68020;
354: a command argument tells the compiler whether it should use 68020-only
355: instructions or not. This command argument works by means of a macro
356: `TARGET_68020' that tests a bit in `target_flags'.
357:
358: Define a macro `TARGET_FEATURENAME' for each such option. Its
359: definition should test a bit in `target_flags'; for example:
360:
361: #define TARGET_68020 (target_flags & 1)
362:
363:
364: One place where these macros are used is in the condition-expressions
365: of instruction patterns. Note how `TARGET_68020' appears frequently
366: in the 68000 machine description file, `m68k.md'. Another place they
367: are used is in the definitions of the other macros in the
368: `tm-MACHINE.h' file.
369:
370: `TARGET_SWITCHES'
371: This macro defines names of command options to set and clear bits in
372: `target_flags'. Its definition is an initializer with a subgrouping
373: for each command option.
374:
375: Each subgrouping contains a string constant, that defines the option
376: name, and a number, which contains the bits to set in `target_flags'.
377: A negative number says to clear bits instead; the negative of the
378: number is which bits to clear. The actual option name is made by
379: appending `-m' to the specified name.
380:
381: One of the subgroupings should have a null string. The number in this
382: grouping is the default value for `target_flags'. Any target options
383: act starting with that value.
384:
385: Here is an example which defines `-m68000' and `-m68020' with opposite
386: meanings, and picks the latter as the default:
387:
388: #define TARGET_SWITCHES \
389: { { "68020", 1}, \
390: { "68000", -1}, \
391: { "", 1}}
392:
393:
394: Sometimes certain combinations of command options do not make sense on a
395: particular target machine. You can define a macro `OVERRIDE_OPTIONS' to
396: take account of this. This macro, if defined, is executed once just after
397: all the command options have been parsed.
398:
399:
400: File: internals, Node: Storage Layout, Next: Registers, Prev: Run-time Target, Up: Machine Macros
401:
402: Storage Layout
403: ==============
404:
405: Note that the definitions of the macros in this table which are sizes or
406: alignments measured in bits do not need to be constant. They can be C
407: expressions that refer to static variables, such as the `target_flags'.
408: *note Run-time Target::.
409:
410: `BITS_BIG_ENDIAN'
411: Define this macro if the most significant bit in a byte has the lowest
412: number. This means that bit-field instructions count from the most
413: significant bit. If the machine has no bit-field instructions, this
414: macro is irrelevant.
415:
416: `BYTES_BIG_ENDIAN'
417: Define this macro if the most significant byte in a word has the
418: lowest number.
419:
420: `WORDS_BIG_ENDIAN'
421: Define this macro if, in a multiword object, the most significant word
422: has the lowest number.
423:
424: `BITS_PER_UNIT'
425: Number of bits in an addressable storage unit (byte); normally 8.
426:
427: `BITS_PER_WORD'
428: Number of bits in a word; normally 32.
429:
430: `UNITS_PER_WORD'
431: Number of storage units in a word; normally 4.
432:
433: `POINTER_SIZE'
434: Width of a pointer, in bits.
435:
436: `PARM_BOUNDARY'
437: Alignment required for function parameters on the stack, in bits.
438:
439: `STACK_BOUNDARY'
440: Define this macro if you wish to preserve a certain alignment for the
441: stack pointer at all times. The definition is a C expression for the
442: desired alignment (measured in bits).
443:
444: `FUNCTION_BOUNDARY'
445: Alignment required for a function entry point, in bits.
446:
447: `BIGGEST_ALIGNMENT'
448: Biggest alignment that any data type can require on this machine, in
449: bits.
450:
451: `EMPTY_FIELD_ALIGNMENT'
452: Alignment in bits to be given to a structure bit field that follows an
453: empty field such as `int : 0;'.
454:
455: `STRUCTURE_SIZE_BOUNDARY'
456: Number of bits which any structure or union's size must be a multiple
457: of. Each structure or union's size is rounded up to a multiple of this.
458:
459: If you do not define this macro, the default is the same as
460: `BITS_PER_UNIT'.
461:
462: `STRICT_ALIGNMENT'
463: Define this if instructions will fail to work if given data not on the
464: nominal alignment. If instructions will merely go slower in that
465: case, do not define this macro.
466:
467:
468: File: internals, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
469:
470: Register Usage
471: ==============
472:
473: `FIRST_PSEUDO_REGISTER'
474: Number of hardware registers known to the compiler. They receive
475: numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo
476: register's number really is assigned the number `FIRST_PSEUDO_REGISTER'.
477:
478: `FIXED_REGISTERS'
479: An initializer that says which registers are used for fixed purposes
480: all throughout the compiled code and are therefore not available for
481: general allocation. These would include the stack pointer, the frame
482: pointer, the program counter on machines where that is considered one
483: of the addressable registers, and any other numbered register with a
484: standard use.
485:
486: This information is expressed as a sequence of numbers, separated by
487: commas and surrounded by braces. The Nth number is 1 if register N is
488: fixed, 0 otherwise.
489:
490: The table initialized from this macro, and the table initialized by
491: the following one, may be overridden at run time either automatically,
492: by the actions of the macro `CONDITIONAL_REGISTER_USAGE', or by the
493: user with the command options `-ffixed-REG', `-fcall-used-REG' and
494: `-fcall-saved-REG'.
495:
496: `CALL_USED_REGISTERS'
497: Like `FIXED_REGISTERS' but has 1 for each register that is clobbered
498: (in general) by function calls as well as for fixed registers. This
499: macro therefore identifies the registers that are not available for
500: general allocation of values that must live across function calls.
501:
502: If a register has 0 in `CALL_USED_REGISTERS', the compiler
503: automatically saves it on function entry and restores it on function
504: exit, if the register is used within the function.
505:
506: `CONDITIONAL_REGISTER_USAGE'
507: Zero or more C statements that may conditionally modify two variables
508: `fixed_regs' and `call_used_regs' (both of type `char []') after they
509: have been initialized from the two preceding macros.
510:
511: This is necessary in case the fixed or call-clobbered registers depend
512: on target flags.
513:
514: You need not define this macro if it has no work to do.
515:
516: `HARD_REGNO_REGS (REGNO, MODE)'
517: A C expression for the number of consecutive hard registers, starting
518: at register number REGNO, required to hold a value of mode MODE.
519:
520: On a machine where all registers are exactly one word, a suitable
521: definition of this macro is
522:
523: #define HARD_REGNO_NREGS(REGNO, MODE) \
524: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
525: / UNITS_PER_WORD))
526:
527:
528: `HARD_REGNO_MODE_OK (REGNO, MODE)'
529: A C expression that is nonzero if it is permissible to store a value
530: of mode MODE in hard register number REGNO (or in several registers
531: starting with that one). For a machine where all registers are
532: equivalent, a suitable definition is
533:
534: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
535:
536:
537: It is not necessary for this macro to check for fixed register numbers
538: because the allocation mechanism considers them to be always occupied.
539:
540: Many machines have special registers for floating point arithmetic.
541: Often people assume that floating point machine modes are allowed only
542: in floating point registers. This is not true. Any registers that
543: can hold integers can safely *hold* a floating point machine mode,
544: whether or not floating arithmetic can be done on it in those registers.
545:
546: The true significance of special floating registers is rather than
547: non-floating-point machine modes *may not* go in those registers.
548: This is true if the floating registers normalize any value stored in
549: them, because storing a non-floating value there would garble it. If
550: the floating registers do not automatically normalize, if you can
551: store any bit pattern in one and retrieve it unchanged without a trap,
552: then any machine mode may go in a floating register and this macro
553: should say so.
554:
555: Sometimes there are floating registers that are especially slow to
556: access, so that it is better to store a value in a stack frame than in
557: such a register if floating point arithmetic is not being done. As
558: long as the floating registers are not in class `GENERAL_REGS', they
559: will not be used unless some insn's constraint asks for one.
560:
561: It is obligatory to support floating point `move' instructions into
562: and out of general registers, because unions and structures (which
563: have modes `SImode' or `DImode') can be in those registers and they
564: may have floating point members.
565:
566: `MODES_TIEABLE_P (MODE1, MODE2)'
567: A C expression that is nonzero if it is desirable to choose register
568: allocation so as to avoid move instructions between a value of mode
569: MODE1 and a value of mode MODE2.
570:
571: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, MODE2)'
572: are ever different for any R, then `MODES_TIEABLE_P (MODE1, MODE2)'
573: must be zero.
574:
575: `PC_REGNUM'
576: If the program counter has a register number, define this as that
577: register number. Otherwise, do not define it.
578:
579: `STACK_POINTER_REGNUM'
580: The register number of the stack pointer register, which must also be
581: a fixed register according to `FIXED_REGISTERS'. On many machines,
582: the hardware determines which register this is.
583:
584: `FRAME_POINTER_REGNUM'
585: The register number of the frame pointer register, which is used to
586: access automatic variables in the stack frame. On some machines, the
587: hardware determines which register this is. On other machines, you
588: can choose any register you wish for this purpose.
589:
590: `FRAME_POINTER_REQUIRED'
591: A C expression which is nonzero if a function must have and use a
592: frame pointer. This expression is evaluated in the reload pass, in
593: the function `reload', and it can in principle examine the current
594: function and decide according to the facts, but on most machines the
595: constant 0 or the constant 1 suffices. Use 0 when the machine allows
596: code to be generated with no frame pointer, and doing so saves some
597: time or space. Use 1 when there is no possible advantage to avoiding
598: a frame pointer.
599:
600: In certain cases, the compiler does not know how to do without a frame
601: pointer. The compiler recognizes those cases and automatically gives
602: the function a frame pointer regardless of what
603: `FRAME_POINTER_REQUIRED' says. You don't need to worry about them.
604:
605: In a function that does not require a frame pointer, the frame pointer
606: register can be allocated for ordinary usage, provided it is not
607: marked as a fixed register. See `FIXED_REGISTERS' for more information.
608:
609: `ARG_POINTER_REGNUM'
610: The register number of the arg pointer register, which is used to
611: access the function's argument list. On some machines, this is the
612: same as the frame pointer register. On some machines, the hardware
613: determines which register this is. On other machines, you can choose
614: any register you wish for this purpose. It must in any case be a
615: fixed register according to `FIXED_REGISTERS'.
616:
617: `STATIC_CHAIN_REGNUM'
618: The register number used for passing a function's static chain
619: pointer. This is needed for languages such as Pascal and Algol where
620: functions defined within other functions can access the local
621: variables of the outer functions; it is not currently used because C
622: does not provide this feature.
623:
624: The static chain register need not be a fixed register.
625:
626: `STRUCT_VALUE_REGNUM'
627: When a function's value's mode is `BLKmode', the value is not returned
628: according to `FUNCTION_VALUE'. Instead, the caller passes the address
629: of a block of memory in which the value should be stored.
630: `STRUCT_VALUE_REGNUM' is the register in which this address is passed.
631:
632:
633: File: internals, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
634:
635: Register Classes
636: ================
637:
638: On many machines, the numbered registers are not all equivalent. For
639: example, certain registers may not be allowed for indexed addressing;
640: certain registers may not be allowed in some instructions. These machine
641: restrictions are described to the compiler using "register classes".
642:
643: You define a number of register classes, giving each one a name and saying
644: which of the registers belong to it. Then you can specify register classes
645: that are allowed as operands to particular instruction patterns.
646:
647: In general, each register will belong to several classes. In fact, one
648: class must be named `ALL_REGS' and contain all the registers. Another
649: class must be named `NO_REGS' and contain no registers. Often the union of
650: two classes will be another class; however, this is not required.
651:
652: One of the classes must be named `GENERAL_REGS'. There is nothing terribly
653: special about the name, but the operand constraint letters `r' and `g'
654: specify this class. If `GENERAL_REGS' is the same as `ALL_REGS', just
655: define it as a macro which expands to `ALL_REGS'.
656:
657: The way classes other than `GENERAL_REGS' are specified in operand
658: constraints is through machine-dependent operand constraint letters. You
659: can define such letters to correspond to various classes, then use them in
660: operand constraints.
661:
662: You should define a class for the union of two classes whenever some
663: instruction allows both classes. For example, if an instruction allows
664: either a floating-point (coprocessor) register or a general register for a
665: certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' which
666: includes both of them. Otherwise you will get suboptimal code.
667:
668: You must also specify certain redundant information about the register
669: classes: for each class, which classes contain it and which ones are
670: contained in it; for each pair of classes, the largest class contained in
671: their union.
672:
673: `enum reg_class'
674: An enumeral type that must be defined with all the register class
675: names as enumeral values. `NO_REGS' must be first. `ALL_REGS' must
676: be the last register class, followed by one more enumeral value,
677: `LIM_REG_CLASSES', which is not a register class but rather tells how
678: many classes there are.
679:
680: Each register class has a number, which is the value of casting the
681: class name to type `int'. The number serves as an index in many of
682: the tables described below.
683:
684: `REG_CLASS_NAMES'
685: An initializer containing the names of the register classes as C
686: string constants. These names are used in writing some of the
687: debugging dumps.
688:
689: `REG_CLASS_CONTENTS'
690: An initializer containing the contents of the register classes, as
691: integers which are bit masks. The Nth integer specifies the contents
692: of class N. The way the integer MASK is interpreted is that register
693: R is in the class if `MASK & (1 << R)' is 1.
694:
695: When the machine has more than 32 registers, an integer does not
696: suffice. Then the integers are replaced by sub-initializers, braced
697: groupings containing several integers. Each sub-initializer must be
698: suitable as an initializer for the type `HARD_REG_SET' which is
699: defined in `hard-reg-set.h'.
700:
701: `REGNO_REG_CLASS (REGNO)'
702: A C expression whose value is a register class containing hard
703: regiSTER REGNO. In general there is more that one such class; choose
704: a class which is "minimal", meaning that no smaller class also
705: contains the register.
706:
707: `INDEX_REG_CLASS'
708: A macro whose definition is the name of the class to which a valid
709: index register must belong.
710:
711: `REG_CLASS_FROM_LETTER (CHAR)'
712: A C expression which defines the machine-dependent operand constraint
713: letters for register classes. If CHAR is such a letter, the value
714: should be the register class corresponding to it. Otherwise, the
715: value should be `NO_REGS'.
716:
717: `REGNO_OK_FOR_BASE_P (NUM)'
718: A C expression which is nonzero if register number NUM is suitable for
719: use as a base register in operand addresses. It may be either a
720: suitable hard register or a pseudo register that has been allocated
721: such a hard register.
722:
723: `REGNO_OK_FOR_INDEX_P (NUM)'
724: A C expression which is nonzero if register number NUM is suitable for
725: use as an index register in operand addresses. It may be either a
726: suitable hard register or a pseudo register that has been allocated
727: such a hard register.
728:
729: The difference between an index register and a base register is that
730: the index register may be scaled. If an address involves the sum of
731: two registers, neither one of them scaled, then either one may be
732: labeled the ``base'' and the other the ``index''; but whichever
733: labeling is used must fit the machine's constraints of which registers
734: may serve in each capacity. The compiler will try both labelings,
735: looking for one that is valid, and reload one or both registers only
736: if neither labeling works.
737:
738: `PREFERRED_RELOAD_CLASS (X, CLASS)'
739: A C expression that places additional restrictions on the register
740: class to use when it is necessary to copy value X into a register in
741: class CLASS. The value is a register class; perhaps CLASS, or perhaps
742: another, smaller class. CLASS is always safe as a value. In fact,
743: the definition
744:
745: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
746:
747:
748: is always safe. However, sometimes returning a more restrictive class
749: makes better code. For example, on the 68000, when X is an integer
750: constant that is in range for a `moveq' instruction, the value of this
751: macro is always `DATA_REGS' as long as CLASS includes the data
752: registers. Requiring a data register guarantees that a `moveq' will
753: be used.
754:
755: `CLASS_MAX_NREGS (CLASS, MODE)'
756: A C expression for the maximum number of consecutive registers of
757: cLASS CLASS needed to hold a value of mode MODE.
758:
759: This is closely related to the macro `HARD_REGNO_NREGS'. In fact, the
760: value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be the
761: maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO values
762: in the class CLASS.
763:
764: This macro helps control the handling of multiple-word values in the
765: reload pass.
766:
767: Two other special macros describe which constants fit which constraint
768: letters.
769:
770: `CONST_OK_FOR_LETTER_P (VALUE, C)'
771: A C expression that defines the machine-dependent operand constraint
772: letters that specify particular ranges of integer values. If C is one
773: of those letters, the expression should check that VALUE, an integer,
774: is in the appropriate range and return 1 if so, 0 otherwise. If C is
775: not one of those letters, the value should be 0 regardless of VALUE.
776:
777: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
778: A C expression that defines the machine-dependent operand constraint
779: letters that specify particular ranges of floating values. If C is
780: one of those letters, the expression should check that VALUE, an RTX
781: of code `const_double', is in the appropriate range and return 1 if
782: so, 0 otherwise. If C is not one of those letters, the value should
783: be 0 regardless of VALUE.
784:
785:
786: File: internals, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
787:
788: Describing Stack Layout
789: =======================
790:
791: `STACK_GROWS_DOWNWARD'
792: Define this macro if pushing a word onto the stack moves the stack
793: pointer to a smaller address.
794:
795: When we say, ``define this macro if ...,'' it means that the compiler
796: checks this macro only with `#ifdef' so the precise definition used
797: does not matter.
798:
799: `FRAME_GROWS_DOWNWARD'
800: Define this macro if the addresses of local variable slots are at
801: negative offsets from the frame pointer.
802:
803: `STARTING_FRAME_OFFSET'
804: Offset from the frame pointer to the first local variable slot to be
805: allocated.
806:
807: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
808: subtracting the length of the first slot from `STARTING_FRAME_OFFSET'.
809: Otherwise, it is found by adding the length of the first slot to the
810: value `STARTING_FRAME_OFFSET'.
811:
812: `PUSH_ROUNDING (NPUSHED)'
813: A C expression that is the number of bytes actually pushed onto the
814: stack when an instruction attempts to push NPUSHED bytes.
815:
816: If the target machine does not have a push instruction, do not define
817: this macro. That directs GNU CC to use an alternate strategy: to
818: allocate the entire argument block and then store the arguments into it.
819:
820: On some machines, the definition
821:
822: #define PUSH_ROUNDING(BYTES) (BYTES)
823:
824:
825: will suffice. But on other machines, instructions that appear to push
826: one byte actually push two bytes in an attempt to maintain alignment.
827: Then the definition should be
828:
829: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
830:
831:
832: `FIRST_PARM_OFFSET'
833: Offset from the argument pointer register to the first argument's
834: address.
835:
836: `RETURN_POPS_ARGS (FUNTYPE)'
837: A C expression that should be 1 if a function pops its own arguments
838: on returning, or 0 if the function pops no arguments and the caller
839: must therefore pop them all after the function returns.
840:
841: FUNTYPE is a C variable whose value is a tree node that describes the
842: function in question. Normally it is a node of type `FUNCTION_TYPE'
843: that describes the data type of the function. From this it is
844: possible to obtain the data types of the value and arguments (if known).
845:
846: When a call to a library function is being considered, FUNTYPE will
847: contain an identifier node for the library function. Thus, if you
848: need to distinguish among various library functions, you can do so by
849: their names. Note that ``library function'' in this context means a
850: function used to perform arithmetic, whose name is known specially in
851: the compiler and was not mentioned in the C code being compiled.
852:
853: On the Vax, all functions always pop their arguments, so the
854: definition of this macro is 1. On the 68000, using the standard
855: calling convention, no functions pop their arguments, so the value of
856: the macro is always 0 in this case. But an alternative calling
857: convention is available in which functions that take a fixed number of
858: arguments pop them but other functions (such as `printf') pop nothing
859: (the caller pops all). When this convention is in use, FUNTYPE is
860: examined to determine whether a function takes a fixed number of
861: arguments.
862:
863: `FUNCTION_VALUE (VALTYPE, FUNC)'
864: A C expression to create an RTX representing the place where a
865: function returns a value of data type VALTYPE. VALTYPE is a tree node
866: representing a data type. Write `TYPE_MODE (VALTYPE)' to get the
867: machine mode used to represent that type. On many machines, only the
868: mode is relevant. (Actually, on most machines, scalar values are
869: returned in the same place regardless of mode).
870:
871: If the precise function being called is known, FUNC is a tree node
872: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
873: makes it possible to use a different value-returning convention for
874: specific functions when all their calls are known.
875:
876: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
877: Define this macro if the target machine has ``register windows'' so
878: that the register in which a function returns its value is not the
879: same as the one in which the caller sees the value.
880:
881: For such machines, `FUNCTION_VALUE' computes the register in which the
882: caller will see the value, and `FUNCTION_OUTGOING_VALUE' should be
883: defined in a similar fashion to tell the function where to put the
884: value.
885:
886: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' serves
887: both purposes.
888:
889: `LIBCALL_VALUE (MODE)'
890: A C expression to create an RTX representing the place where a library
891: function returns a value of mode MODE. If the precise function being
892: called is known, FUNC is a tree node (`FUNCTION_DECL') for it;
893: otherwise, FUNC is a null pointer. This makes it possible to use a
894: different value-returning convention for specific functions when all
895: their calls are known.
896:
897: Note that ``library function'' in this context means a compiler
898: support routine, used to perform arithmetic, whose name is known
899: specially by the compiler and was not mentioned in the C code being
900: compiled.
901:
902: `FUNCTION_VALUE_REGNO_P (REGNO)'
903: A C expression that is nonzero if REGNO is the number of a hard
904: register in which function values are sometimes returned.
905:
906: A register whose use for returning values is limited to serving as the
907: second of a pair (for a value of type `double', say) need not be
908: recognized by this macro. So for most machines, this definition
909: suffices:
910:
911: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
912:
913:
914: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
915: A C expression that controls whether a function argument is passed in
916: a register, and which register.
917:
918: The arguments are CUM, which summarizes all the previous arguments;
919: MODE, the machine mode of the argument; TYPE, the data type of the
920: argument as a tree node or 0 if that is not known (which happens for C
921: support library functions); and NAMED, which is 1 for an ordinary
922: argument and 0 for nameless arguments that correspond to `...' in the
923: called function's prototype.
924:
925: The value of the expression should either be a `reg' RTX for the hard
926: register in which to pass the argument, or zero to pass the argument
927: on the stack.
928:
929: For the Vax and 68000, where normally all arguments are pushed, zero
930: suffices as a definition.
931:
932: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
933: Define this macro if the target machine has ``register windows'', so
934: that the register in which a function sees an arguments is not
935: necessarily the same as the one in which the caller passed the argument.
936:
937: For such machines, `FUNCTION_ARG' computes the register in which the
938: caller passes the value, and `FUNCTION_INCOMING_ARG' should be defined
939: in a similar fashion to tell the function being called where the
940: arguments will arrive.
941:
942: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves both
943: purposes.
944:
945: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
946: A C expression for the number of words, at the beginning of an
947: argument, must be put in registers. The value must be zero for
948: arguments that are passed entirely in registers or that are entirely
949: pushed on the stack.
950:
951: On some machines, certain arguments must be passed partially in
952: registers and partially in memory. On these machines, typically the
953: first N words of arguments are passed in registers, and the rest on
954: the stack. If a multi-word argument (a `double' or a structure)
955: crosses that boundary, its first few words must be passed in registers
956: and the rest must be pushed. This macro tells the compiler when this
957: occurs, and how many of the words should go in registers.
958:
959: `FUNCTION_ARG' for these arguments should return the first register to
960: be used by the caller for this argument; likewise
961: `FUNCTION_INCOMING_ARG', for the called function.
962:
963: `CUMULATIVE_ARGS'
964: A C type for declaring a variable that is used as the first argument
965: of `FUNCTION_ARG' and other related values. For some target machines,
966: the type `int' suffices and can hold the number of bytes of argument
967: so far.
968:
969: `INIT_CUMULATIVE_ARGS (CUM)'
970: A C statement (sans semicolon) for initializing the variable CUM for
971: the state at the beginning of the argument list. The variable has
972: type `CUMULATIVE_ARGS'.
973:
974: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
975: Update the summarizer variable CUM to advance past an argument in the
976: argument list. The values MODE, TYPE and NAMED describe that
977: argument. Once this is done, the variable CUM is suitable for
978: analyzing the *following* argument with `FUNCTION_ARG', etc.
979:
980: `FUNCTION_ARG_REGNO_P (REGNO)'
981: A C expression that is nonzero if REGNO is the number of a hard
982: register in which function arguments are sometimes passed. This does
983: *not* include implicit arguments such as the static chain and the
984: structure-value address. On many machines, no registers can be used
985: for this purpose since all function arguments are pushed on the stack.
986:
987: `FUNCTION_PROLOGUE (FILE, SIZE)'
988: A C compound statement that outputs the assembler code for entry to a
989: function. The prologue is responsible for setting up the stack frame,
990: initializing the frame pointer register, saving registers that must be
991: saved, and allocating SIZE additional bytes of storage for the local
992: variables. SIZE is an integer. FILE is a stdio stream to which the
993: assembler code should be output.
994:
995: The label for the beginning of the function need not be output by this
996: macro. That has already been done when the macro is run.
997:
998: To determine which registers to save, the macro can refer to the array
999: `regs_ever_live': element R is nonzero if hard register R is used
1000: anywhere within the function. This implies the function prologue
1001: should save register R, but not if it is one of the call-used registers.
1002:
1003: On machines where functions may or may not have frame-pointers, the
1004: function entry code must vary accordingly; it must set up the frame
1005: pointer if one is wanted, and not otherwise. To determine whether a
1006: frame pointer is in wanted, the macro can refer to the variable
1007: `frame_pointer_needed'. The variable's value will be 1 at run time in
1008: a function that needs a frame pointer.
1009:
1010: `FUNCTION_PROFILER (FILE, LABELNO)'
1011: A C statement or compound statement to output to FILE some assembler
1012: code to call the profiling subroutine `mcount'. Before calling, the
1013: assembler code must load the address of a counter variable into a
1014: register where `mcount' expects to find the address. The name of this
1015: variable is `LP' followed by the number LABELNO, so you would generate
1016: the name using `LP%d' in a `fprintf'.
1017:
1018: The details of how the address should be passed to `mcount' are
1019: determined by your operating system environment, not by GNU CC. To
1020: figure them out, compile a small program for profiling using the
1021: system's installed C compiler and look at the assembler code that
1022: results.
1023:
1024: `EXIT_IGNORES_STACK'
1025: Define this macro as a C expression that is nonzero if the return
1026: instruction or the function epilogue ignores the value of the stack
1027: pointer; in other words, if it is safe to delete an instruction to
1028: adjust the stack pointer before a return from the function.
1029:
1030: Note that this macro's value is relevant only for for which frame
1031: pointers are maintained. It is never possible to delete a final stack
1032: adjustment in a function that has no frame pointer, and the compiler
1033: knows this regardless of `EXIT_IGNORES_STACK'.
1034:
1035: `FUNCTION_EPILOGUE (FILE, SIZE)'
1036: A C compound statement that outputs the assembler code for exit from a
1037: function. The epilogue is responsible for restoring the saved
1038: registers and stack pointer to their values when the function was
1039: called, and returning control to the caller. This macro takes the
1040: same arguments as the macro `FUNCTION_PROLOGUE', and the registers to
1041: restore are determined from `regs_ever_live' and `CALL_USED_REGISTERS'
1042: in the same way.
1043:
1044: On some machines, there is a single instruction that does all the work
1045: of returning from the function. On these machines, give that
1046: instruction the name `return' and do not define the macro
1047: `FUNCTION_EPILOGUE' at all.
1048:
1049: On machines where functions may or may not have frame-pointers, the
1050: function exit code must vary accordingly. Sometimes the code for
1051: these two cases is completely different. To determine whether a frame
1052: pointer is in wanted, the macro can refer to the variable
1053: `frame_pointer_needed'. The variable's value will be 1 at run time in
1054: a function that needs a frame pointer.
1055:
1056: On some machines, some functions pop their arguments on exit while
1057: others leave that for the caller to do. For example, the 68020 when
1058: given `-mrtd' pops arguments in functions that take a fixed number of
1059: arguments.
1060:
1061: Your definition of the macro `RETURN_POPS_ARGS' decides which
1062: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to know
1063: what was decided. The variable `current_function_pops_args' is
1064: nonzero if the function should pop its own arguments. If so, use the
1065: variable `current_function_args_size' as the number of bytes to pop.
1066:
1067: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
1068: A C compound statement to alter a memory address that uses the frame
1069: pointer register so that it uses the stack pointer register instead.
1070: This must be done in the instructions that load parameter values into
1071: registers, when the reload pass determines that a frame pointer is not
1072: necessary for the function. ADDR will be a C variable name, and the
1073: updated address should be stored in that variable. DEPTH will be the
1074: current depth of stack temporaries (number of bytes of arguments
1075: currently pushed). The change in offset between a
1076: frame-pointer-relative address and a stack-pointer-relative address
1077: must include DEPTH.
1078:
1079: Even if your machine description specifies there will always be a
1080: frame pointer in the frame pointer register, you must still define
1081: `FIX_FRAME_POINTER_ADDRESS', but the definition will never be executed
1082: at run time, so it may be empty.
1083:
1084:
1085: File: internals, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
1086:
1087: Library Subroutine Names
1088: ========================
1089:
1090: `UDIVSI3_LIBCALL'
1091: A C string constant giving the name of the function to call for
1092: division of a full-word by a full-word. If you do not define this
1093: macro, the default name is used, which is `_udivsi3', a function
1094: defined in `gnulib'.
1095:
1096: `UMODSI3_LIBCALL'
1097: A C string constant giving the name of the function to call for the
1098: remainder in division of a full-word by a full-word. If you do not
1099: define this macro, the default name is used, which is `_umodsi3', a
1100: function defined in `gnulib'.
1101:
1102: `TARGET_MEM_FUNCTIONS'
1103: Define this macro if GNU CC should generate calls to the System V (and
1104: ANSI C) library functions `memcpy' and `memset' rather than the BSD
1105: functions `bcopy' and `bzero'.
1106:
1107:
1108: File: internals, Node: Addressing Modes, Next: Misc, Prev: Library Names, Up: Machine Macros
1109:
1110: Addressing Modes
1111: ================
1112:
1113: `HAVE_POST_INCREMENT'
1114: Define this macro if the machine supports post-increment addressing.
1115:
1116: `HAVE_PRE_INCREMENT'
1117: `HAVE_POST_DECREMENT'
1118: `HAVE_PRE_DECREMENT'
1119: Similar for other kinds of addressing.
1120:
1121: `CONSTANT_ADDRESS_P (X)'
1122: A C expression that is 1 if the RTX X is a constant whose value is an
1123: integer. This includes integers whose values are not explicitly
1124: known, such as `symbol_ref' and `label_ref' expressions and `const'
1125: arithmetic expressions.
1126:
1127: On most machines, this can be defined as `CONSTANT_P (X)', but a few
1128: machines are more restrictive in which constant addresses are supported.
1129:
1130: `MAX_REGS_PER_ADDRESS'
1131: A number, the maximum number of registers that can appear in a valid
1132: memory address.
1133:
1134: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
1135: A C compound statement with a conditional `goto LABEL;' executed if X
1136: (an RTX) is a legitimate memory address on the target machine for a
1137: memory operand of mode MODE.
1138:
1139: It usually pays to define several simpler macros to serve as
1140: subroutines for this one. Otherwise it may be too complicated to
1141: understand.
1142:
1143: This macro must exist in two variants: a strict variant and a
1144: non-strict one. The strict variant is used in the reload pass. It
1145: must be defined so that any pseudo-register that has not been
1146: allocated a hard register is considered a memory reference. In
1147: contexts where some kind of register is required, a pseudo-register
1148: with no hard register must be rejected.
1149:
1150: The non-strict variant is used in other passes. It must be defined to
1151: accept all pseudo-registers in every context where some kind of
1152: register is required.
1153:
1154: Compiler source files that want to use the strict variant of this
1155: macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
1156: REG_OK_STRICT' conditional to define the strict variant in that case
1157: and the non-strict variant otherwise.
1158:
1159: Typically among the subroutines used to define
1160: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for acceptable
1161: registers for various purposes (one for base registers, one for index
1162: registers, and so on). Then only these subroutine macros need have
1163: two variants; the higher levels of macros may be the same whether
1164: strict or not.
1165:
1166: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
1167: A C compound statement that attempts to replace X with a valid memory
1168: address for an operand of mode MODE. WIN will be a C statement label
1169: elsewhere in the code; the macro definition may use
1170:
1171: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
1172:
1173:
1174: to avoid further processing if the address has become legitimate.
1175:
1176: X will always be the result of a call to `break_out_memory_refs', and
1177: OLDX will be the operand that was given to that function to produce X.
1178:
1179: The code generated by this macro should not alter the substructure of
1180: X. If it transforms X into a more legitimate form, it should assign X
1181: (which will always be a C variable) a new value.
1182:
1183: It is not necessary for this macro to come up with a legitimate
1184: address. The compiler has standard ways of doing so in all cases. In
1185: fact, it is safe for this macro to do nothing. But often a
1186: machine-dependent strategy can generate better code.
1187:
1188: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
1189: A C statement or compound statement with a conditional `goto LABEL;'
1190: executed if memory address X (an RTX) can have different meanings
1191: depending on the machine mode of the memory reference it is used for.
1192:
1193: Autoincrement and autodecrement addresses typically have
1194: mode-dependent effects because the amount of the increment or
1195: decrement is the size of the operand being addressed. Some machines
1196: have other mode-dependent addresses. Many RISC machines have no
1197: mode-dependent addresses.
1198:
1199: You may assume that ADDR is a valid address for the machine.
1200:
1201: `LEGITIMATE_CONSTANT_P (X)'
1202: A C expression that is nonzero if X is a legitimate constant for an
1203: immediate operand on the target machine. You can assume that either X
1204: is a `const_double' or it satisfies `CONSTANT_P', so you need not
1205: check these things. In fact, `1' is a suitable definition for this
1206: macro on machines where any `const_double' is valid and anything
1207: `CONSTANT_P' is valid.
1208:
1209:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.