Next:Vectorization, Previous:Implicit Calls to Library Routines, Up:Target Description Macros and Functions [Contents][Index]
This is about addressing modes.
A C expression that is nonzero if the machine supports pre-increment,pre-decrement, post-increment, or post-decrement addressing respectively.
A C expression that is nonzero if the machine supports pre- orpost-address side-effect generation involving constants other thanthe size of the memory operand.
A C expression that is nonzero if the machine supports pre- orpost-address side-effect generation involving a register displacement.
A C expression that is 1 if the RTXx is a constant whichis a valid address. On most machines the default definition of(CONSTANT_P (x) && GET_CODE (x) != CONST_DOUBLE)is acceptable, but a few machines are more restrictive as to whichconstant addresses are supported.
CONSTANT_P, which is defined by target-independent code,accepts integer-values expressions whose values are not explicitlyknown, such assymbol_ref,label_ref, andhighexpressions andconst arithmetic expressions, in addition toconst_int andconst_double expressions.
A number, the maximum number of registers that can appear in a validmemory address. Note that it is up to you to specify a value equal tothe maximum number thatTARGET_LEGITIMATE_ADDRESS_P would everaccept.
boolTARGET_LEGITIMATE_ADDRESS_P(machine_modemode, rtxx, boolstrict, code_helperch) ¶A function that returns whetherx (an RTX) is a legitimate memoryaddress on the target machine for a memory operand of modemode.Ifch is notERROR_MARK, it can be called from middle-end todetermine if it is valid to usex as a memory operand for RTX insnwhich is generated for the given code_helperch. For example,assuming the givench is IFN_LEN_LOAD, on some target its underlyinghardware instructions support fewer addressing modes than what are for thenormal vector load and store, then with thisch target can know theactual use context and return more exact result.
Legitimate addresses are defined in two variants: a strict variant and anon-strict one. Thestrict parameter chooses which variant isdesired by the caller.
The strict variant is used in the reload pass. It must be defined sothat any pseudo-register that has not been allocated a hard register isconsidered a memory reference. This is because in contexts where somekind of register is required, a pseudo-register with no hard registermust be rejected. For non-hard registers, the strict variant should lookup thereg_renumber array; it should then proceed using the hardregister number in the array, or treat the pseudo as a memory referenceif the array holds-1.
The non-strict variant is used in other passes. It must be defined toaccept all pseudo-registers in every context where some kind ofregister is required.
Normally, constant addresses which are the sum of asymbol_refand an integer are stored inside aconst RTX to mark them asconstant. Therefore, there is no need to recognize such sumsspecifically as legitimate addresses. Normally you would simplyrecognize anyconst as legitimate.
UsuallyPRINT_OPERAND_ADDRESS is not prepared to handle constantsums that are not marked withconst. It assumes that a nakedplus indicates indexing. If so, then youmust reject suchnaked constant sums as illegitimate addresses, so that none of them willbe given toPRINT_OPERAND_ADDRESS.
On some machines, whether a symbolic address is legitimate depends onthe section that the address refers to. On these machines, define thetarget hookTARGET_ENCODE_SECTION_INFO to store the informationinto thesymbol_ref, and then check for it here. When you see aconst, you will have to look inside it to find thesymbol_ref in order to determine the section. SeeDefining the Output Assembler Language.
Some ports are still using a deprecated legacy substitute forthis hook, theGO_IF_LEGITIMATE_ADDRESS macro. This macrohas this syntax:
#define GO_IF_LEGITIMATE_ADDRESS (mode,x,label)
and shouldgotolabel if the addressx is a validaddress on the target machine for a memory operand of modemode.
Compiler source files that want to use the strict variant of thismacro define the macroREG_OK_STRICT. You should use an#ifdef REG_OK_STRICT conditional to define the strict variant inthat case and the non-strict variant otherwise.
Using the hook is usually simpler because it limits the number offiles that are recompiled when changes are made.
A single character to be used instead of the default'm'character for general memory addresses. This defines the constraintletter which matches the memory addresses accepted byTARGET_LEGITIMATE_ADDRESS_P. Define this macro if you want tosupport new address formats in your back end without changing thesemantics of the'm' constraint. This is necessary in order topreserve functionality of inline assembly constructs using the'm' constraint.
A C expression to determine the base term of addressx,or to provide a simplified version ofx from whichalias.cccan easily find the base term. This macro is used in only two places:find_base_value andfind_base_term inalias.cc.
It is always safe for this macro to not be defined. It exists sothat alias analysis can understand machine-dependent addresses.
The typical use of this macro is to handle addresses containinga label_ref or symbol_ref within an UNSPEC.
rtxTARGET_LEGITIMIZE_ADDRESS(rtxx, rtxoldx, machine_modemode) ¶This hook is given an invalid memory addressx for anoperand of modemode and should try to return a valid memoryaddress.
x will always be the result of a call tobreak_out_memory_refs,andoldx will be the operand that was given to that function to producex.
The code of the hook should not alter the substructure ofx. If it transformsx into a more legitimate form, itshould return the newx.
It is not necessary for this hook to come up with a legitimate address,with the exception of native TLS addresses (seeEmulating TLS).The compiler has standard ways of doing so in all cases. In fact, ifthe target supports only emulated TLS, itis safe to omit this hook or make it returnx if it cannot finda valid way to legitimize the address. But often a machine-dependentstrategy can generate better code.
A C compound statement that attempts to replacex, which is an addressthat needs reloading, with a valid memory address for an operand of modemode.win will be a C statement label elsewhere in the code.It is not necessary to define this macro, but it might be useful forperformance reasons.
For example, on the i386, it is sometimes possible to use a singlereload register instead of two by reloading a sum of two pseudoregisters into a register. On the other hand, for number of RISCprocessors offsets are limited so that often an intermediate addressneeds to be generated in order to address a stack slot. By definingLEGITIMIZE_RELOAD_ADDRESS appropriately, the intermediate addressesgenerated for adjacent some stack slots can be made identical, and thusbe shared.
Note: This macro should be used with caution. It is necessaryto know something of how reload works in order to effectively use this,and it is quite easy to produce macros that build in too much knowledgeof reload internals.
Note: This macro must be able to reload an address created by aprevious invocation of this macro. If it fails to handle such addressesthen the compiler may generate incorrect code or abort.
The macro definition should usepush_reload to indicate parts thatneed reloading;opnum,type andind_levels are usuallysuitable to be passed unaltered topush_reload.
The code generated by this macro must not alter the substructure ofx. If it transformsx into a more legitimate form, itshould assignx (which will always be a C variable) a new value.This also applies to parts that you change indirectly by callingpush_reload.
The macro definition may usestrict_memory_address_p to test ifthe address has become legitimate.
If you want to change only a part ofx, one standard way of doingthis is to usecopy_rtx. Note, however, that it unshares only asingle level of rtl. Thus, if the part to be changed is not at thetop level, you’ll need to replace first the top level.It is not necessary for this macro to come up with a legitimateaddress; but often a machine-dependent strategy can generate better code.
boolTARGET_MODE_DEPENDENT_ADDRESS_P(const_rtxaddr, addr_space_taddrspace) ¶This hook returnstrue if memory addressaddr in addressspaceaddrspace can havedifferent meanings depending on the machine mode of the memoryreference it is used for or if the address is valid for some modesbut not others.
Autoincrement and autodecrement addresses typically have mode-dependenteffects because the amount of the increment or decrement is the sizeof the operand being addressed. Some machines have other mode-dependentaddresses. Many RISC machines have no mode-dependent addresses.
You may assume thataddr is a valid address for the machine.
The default version of this hook returnsfalse.
boolTARGET_LEGITIMATE_CONSTANT_P(machine_modemode, rtxx) ¶This hook returns true ifx is a legitimate constant for amode-mode immediate operand on the target machine. You can assume thatx satisfiesCONSTANT_P, so you need not check this.
The default definition returns true.
boolTARGET_PRECOMPUTE_TLS_P(machine_modemode, rtxx) ¶This hook returns true ifx is a TLS operand on the targetmachine that should be pre-computed when used as the argument in a call.You can assume thatx satisfiesCONSTANT_P, so you need not check this.
The default definition returns false.
rtxTARGET_DELEGITIMIZE_ADDRESS(rtxx) ¶This hook is used to undo the possibly obfuscating effects of theLEGITIMIZE_ADDRESS andLEGITIMIZE_RELOAD_ADDRESS targetmacros. Some backend implementations of these macros wrap symbolreferences inside anUNSPEC rtx to represent PIC or similaraddressing modes. This target hook allows GCC’s optimizers to understandthe semantics of these opaqueUNSPECs by converting them backinto their original form.
boolTARGET_CONST_NOT_OK_FOR_DEBUG_P(rtxx) ¶This hook should return true ifx should not be emitted intodebug sections.
boolTARGET_CANNOT_FORCE_CONST_MEM(machine_modemode, rtxx) ¶This hook should return true ifx is of a form that cannot (orshould not) be spilled to the constant pool.mode is the modeofx.
The default version of this hook returns false.
The primary reason to define this hook is to prevent reload fromdeciding that a non-legitimate constant would be better reloadedfrom the constant pool instead of spilling and reloading a registerholding the constant. This restriction is often true of addressesof TLS symbols for various targets.
boolTARGET_USE_BLOCKS_FOR_CONSTANT_P(machine_modemode, const_rtxx) ¶This hook should return true if pool entries for constantx canbe placed in anobject_block structure.mode is the modeofx.
The default version returns false for all constants.
boolTARGET_USE_BLOCKS_FOR_DECL_P(const_treedecl) ¶This hook should return true if pool entries fordecl shouldbe placed in anobject_block structure.
The default version returns true for all decls.
treeTARGET_BUILTIN_RECIPROCAL(treefndecl) ¶This hook should return the DECL of a function that implements thereciprocal of the machine-specific builtin functionfndecl, orNULL_TREE if such a function is not available.
Next:Vectorization, Previous:Implicit Calls to Library Routines, Up:Target Description Macros and Functions [Contents][Index]