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- or post-address side-effect generation involving constants other than the size of the memory operand.
A C expression that is nonzero if the machine supports pre- or post-address side-effect generation involving a register displacement.
A C expression that is 1 if the RTX x is a constant which
is 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 which
constant addresses are supported.
CONSTANT_P, which is defined by target-independent code,
accepts integer-values expressions whose values are not explicitly
known, such as symbol_ref, label_ref, and high
expressions and const arithmetic expressions, in addition to
const_int and const_double expressions.
A number, the maximum number of registers that can appear in a valid
memory address. Note that it is up to you to specify a value equal to
the maximum number that TARGET_LEGITIMATE_ADDRESS_P would ever
accept.
bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode mode, rtx x, bool strict, code_helper ch) ¶A function that returns whether x (an RTX) is a legitimate memory
address on the target machine for a memory operand of mode mode.
If ch is not ERROR_MARK, it can be called from middle-end to
determine if it is valid to use x as a memory operand for RTX insn
which is generated for the given code_helper ch. For example,
assuming the given ch is IFN_LEN_LOAD, on some target its underlying
hardware instructions support fewer addressing modes than what are for the
normal vector load and store, then with this ch target can know the
actual use context and return more exact result.
Legitimate addresses are defined in two variants: a strict variant and a non-strict one. The strict parameter chooses which variant is desired by the caller.
The strict variant is used in the reload pass. It must be defined so
that any pseudo-register that has not been allocated a hard register is
considered a memory reference. This is because in contexts where some
kind of register is required, a pseudo-register with no hard register
must be rejected. For non-hard registers, the strict variant should look
up the reg_renumber array; it should then proceed using the hard
register number in the array, or treat the pseudo as a memory reference
if the array holds -1.
The non-strict variant is used in other passes. It must be defined to accept all pseudo-registers in every context where some kind of register is required.
Normally, constant addresses which are the sum of a symbol_ref
and an integer are stored inside a const RTX to mark them as
constant. Therefore, there is no need to recognize such sums
specifically as legitimate addresses. Normally you would simply
recognize any const as legitimate.
Usually PRINT_OPERAND_ADDRESS is not prepared to handle constant
sums that are not marked with const. It assumes that a naked
plus indicates indexing. If so, then you must reject such
naked constant sums as illegitimate addresses, so that none of them will
be given to PRINT_OPERAND_ADDRESS.
On some machines, whether a symbolic address is legitimate depends on
the section that the address refers to. On these machines, define the
target hook TARGET_ENCODE_SECTION_INFO to store the information
into the symbol_ref, and then check for it here. When you see a
const, you will have to look inside it to find the
symbol_ref in order to determine the section. See Defining the Output Assembler Language.
Some ports are still using a deprecated legacy substitute for
this hook, the GO_IF_LEGITIMATE_ADDRESS macro. This macro
has this syntax:
#define GO_IF_LEGITIMATE_ADDRESS (mode, x, label)
and should goto label if the address x is a valid
address on the target machine for a memory operand of mode mode.
Compiler source files that want to use the strict variant of this
macro define the macro REG_OK_STRICT. You should use an
#ifdef REG_OK_STRICT conditional to define the strict variant in
that case and the non-strict variant otherwise.
Using the hook is usually simpler because it limits the number of files 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 constraint
letter which matches the memory addresses accepted by
TARGET_LEGITIMATE_ADDRESS_P. Define this macro if you want to
support new address formats in your back end without changing the
semantics of the 'm' constraint. This is necessary in order to
preserve functionality of inline assembly constructs using the
'm' constraint.
A C expression to determine the base term of address x,
or to provide a simplified version of x from which alias.cc
can easily find the base term. This macro is used in only two places:
find_base_value and find_base_term in alias.cc.
It is always safe for this macro to not be defined. It exists so that alias analysis can understand machine-dependent addresses.
The typical use of this macro is to handle addresses containing a label_ref or symbol_ref within an UNSPEC.
rtx TARGET_LEGITIMIZE_ADDRESS (rtx x, rtx oldx, machine_mode mode) ¶This hook is given an invalid memory address x for an operand of mode mode and should try to return a valid memory address.
x will always be the result of a call to break_out_memory_refs,
and oldx will be the operand that was given to that function to produce
x.
The code of the hook should not alter the substructure of x. If it transforms x into a more legitimate form, it should return the new x.
It is not necessary for this hook to come up with a legitimate address, with the exception of native TLS addresses (see Emulating TLS). The compiler has standard ways of doing so in all cases. In fact, if the target supports only emulated TLS, it is safe to omit this hook or make it return x if it cannot find a valid way to legitimize the address. But often a machine-dependent strategy can generate better code.
A C compound statement that attempts to replace x, which is an address that needs reloading, with a valid memory address for an operand of mode mode. win will be a C statement label elsewhere in the code. It is not necessary to define this macro, but it might be useful for performance reasons.
For example, on the i386, it is sometimes possible to use a single
reload register instead of two by reloading a sum of two pseudo
registers into a register. On the other hand, for number of RISC
processors offsets are limited so that often an intermediate address
needs to be generated in order to address a stack slot. By defining
LEGITIMIZE_RELOAD_ADDRESS appropriately, the intermediate addresses
generated for adjacent some stack slots can be made identical, and thus
be shared.
Note: This macro should be used with caution. It is necessary to 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 knowledge of reload internals.
Note: This macro must be able to reload an address created by a previous invocation of this macro. If it fails to handle such addresses then the compiler may generate incorrect code or abort.
The macro definition should use push_reload to indicate parts that
need reloading; opnum, type and ind_levels are usually
suitable to be passed unaltered to push_reload.
The code generated by this macro must not alter the substructure of
x. If it transforms x into a more legitimate form, it
should assign x (which will always be a C variable) a new value.
This also applies to parts that you change indirectly by calling
push_reload.
The macro definition may use strict_memory_address_p to test if
the address has become legitimate.
If you want to change only a part of x, one standard way of doing
this is to use copy_rtx. Note, however, that it unshares only a
single level of rtl. Thus, if the part to be changed is not at the
top level, you’ll need to replace first the top level.
It is not necessary for this macro to come up with a legitimate
address; but often a machine-dependent strategy can generate better code.
bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx addr, addr_space_t addrspace) ¶This hook returns true if memory address addr in address
space addrspace can have
different meanings depending on the machine mode of the memory
reference it is used for or if the address is valid for some modes
but not others.
Autoincrement and autodecrement addresses typically have mode-dependent effects because the amount of the increment or decrement is the size of the operand being addressed. Some machines have other mode-dependent addresses. Many RISC machines have no mode-dependent addresses.
You may assume that addr is a valid address for the machine.
The default version of this hook returns false.
bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode mode, rtx x) ¶This hook returns true if x is a legitimate constant for a
mode-mode immediate operand on the target machine. You can assume that
x satisfies CONSTANT_P, so you need not check this.
The default definition returns true.
bool TARGET_PRECOMPUTE_TLS_P (machine_mode mode, rtx x) ¶This hook returns true if x is a TLS operand on the target
machine that should be pre-computed when used as the argument in a call.
You can assume that x satisfies CONSTANT_P, so you need not
check this.
The default definition returns false.
rtx TARGET_DELEGITIMIZE_ADDRESS (rtx x) ¶This hook is used to undo the possibly obfuscating effects of the
LEGITIMIZE_ADDRESS and LEGITIMIZE_RELOAD_ADDRESS target
macros. Some backend implementations of these macros wrap symbol
references inside an UNSPEC rtx to represent PIC or similar
addressing modes. This target hook allows GCC’s optimizers to understand
the semantics of these opaque UNSPECs by converting them back
into their original form.
bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx x) ¶This hook should return true if x should not be emitted into debug sections.
bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode mode, rtx x) ¶This hook should return true if x is of a form that cannot (or should not) be spilled to the constant pool. mode is the mode of x.
The default version of this hook returns false.
The primary reason to define this hook is to prevent reload from deciding that a non-legitimate constant would be better reloaded from the constant pool instead of spilling and reloading a register holding the constant. This restriction is often true of addresses of TLS symbols for various targets.
bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode mode, const_rtx x) ¶This hook should return true if pool entries for constant x can
be placed in an object_block structure. mode is the mode
of x.
The default version returns false for all constants.
bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree decl) ¶This hook should return true if pool entries for decl should
be placed in an object_block structure.
The default version returns true for all decls.
tree TARGET_BUILTIN_RECIPROCAL (tree fndecl) ¶This hook should return the DECL of a function that implements the
reciprocal of the machine-specific builtin function fndecl, or
NULL_TREE if such a function is not available.