Misc (GNU Compiler Collection (GCC) Internals)

### 19.35 Miscellaneous Parameters ¶

Here are several miscellaneous parameters.

Macro: HAS_LONG_COND_BRANCH ¶

  Define this boolean macro to indicate whether or not your architecture has conditional branches that can span all of memory. It is used in conjunction with an optimization that partitions hot and cold basic blocks into separate sections of the executable. If this macro is set to false, gcc will convert any conditional branches that attempt to cross between sections into unconditional branches or indirect jumps.

Macro: HAS_LONG_UNCOND_BRANCH ¶

  Define this boolean macro to indicate whether or not your architecture has unconditional branches that can span all of memory. It is used in conjunction with an optimization that partitions hot and cold basic blocks into separate sections of the executable. If this macro is set to false, gcc will convert any unconditional branches that attempt to cross between sections into indirect jumps.

Macro: CASE_VECTOR_MODE ¶

  An alias for a machine mode name. This is the machine mode that elements of a jump-table should have.

Macro: CASE_VECTOR_SHORTEN_MODE (min_offset, max_offset, body) ¶

  Optional: return the preferred mode for an `addr_diff_vec` when the minimum and maximum offset are known. If you define this, it enables extra code in branch shortening to deal with `addr_diff_vec`. To make this work, you also have to define `INSN_ALIGN` and make the alignment for `addr_diff_vec` explicit. The body argument is provided so that the offset_unsigned and scale flags can be updated.

Macro: CASE_VECTOR_PC_RELATIVE ¶

  Define this macro to be a C expression to indicate when jump-tables should contain relative addresses. You need not define this macro if jump-tables never contain relative addresses, or jump-tables should contain relative addresses only when `-fPIC` or `-fPIC` is in effect.

Target Hook: `unsigned int` TARGET_CASE_VALUES_THRESHOLD `(void)` ¶

  This function return the smallest number of different values for which it is best to use a jump-table instead of a tree of conditional branches. The default is four for machines with a `casesi` instruction and five otherwise. This is best for most machines.

Macro: WORD_REGISTER_OPERATIONS ¶

  Define this macro to 1 if operations between registers with integral mode smaller than a word are always performed on the entire register. To be more explicit, if you start with a pair of `word_mode` registers with known values and you do a subword, for example `QImode`, addition on the low part of the registers, then the compiler may consider that the result has a known value in `word_mode` too if the macro is defined to 1. Most RISC machines have this property and most CISC machines do not.

Target Hook: `unsigned int` TARGET_MIN_ARITHMETIC_PRECISION `(void)` ¶

  On some RISC architectures with 64-bit registers, the processor also maintains 32-bit condition codes that make it possible to do real 32-bit arithmetic, although the operations are performed on the full registers.

  On such architectures, defining this hook to 32 tells the compiler to try using 32-bit arithmetical operations setting the condition codes instead of doing full 64-bit arithmetic.

  More generally, define this hook on RISC architectures if you want the compiler to try using arithmetical operations setting the condition codes with a precision lower than the word precision.

  You need not define this hook if `WORD_REGISTER_OPERATIONS` is not defined to 1.

Macro: LOAD_EXTEND_OP (mem_mode) ¶

  Define this macro to be a C expression indicating when insns that read memory in mem_mode, an integral mode narrower than a word, set the bits outside of mem_mode to be either the sign-extension or the zero-extension of the data read. Return `SIGN_EXTEND` for values of mem_mode for which the insn sign-extends, `ZERO_EXTEND` for which it zero-extends, and `UNKNOWN` for other modes.

  This macro is not called with mem_mode non-integral or with a width greater than or equal to `BITS_PER_WORD`, so you may return any value in this case. Do not define this macro if it would always return `UNKNOWN`. On machines where this macro is defined, you will normally define it as the constant `SIGN_EXTEND` or `ZERO_EXTEND`.

  You may return a non-`UNKNOWN` value even if for some hard registers the sign extension is not performed, if for the `REGNO_REG_CLASS` of these hard registers `TARGET_CAN_CHANGE_MODE_CLASS` returns false when the from mode is mem_mode and the to mode is any integral mode larger than this but not larger than `word_mode`.

  You must return `UNKNOWN` if for some hard registers that allow this mode, `TARGET_CAN_CHANGE_MODE_CLASS` says that they cannot change to `word_mode`, but that they can change to another integral mode that is larger then mem_mode but still smaller than `word_mode`.

Macro: SHORT_IMMEDIATES_SIGN_EXTEND ¶

  Define this macro to 1 if loading short immediate values into registers sign extends.

Target Hook: `unsigned int` TARGET_MIN_DIVISIONS_FOR_RECIP_MUL `(machine_mode mode)` ¶

  When `-ffast-math` is in effect, GCC tries to optimize divisions by the same divisor, by turning them into multiplications by the reciprocal. This target hook specifies the minimum number of divisions that should be there for GCC to perform the optimization for a variable of mode mode. The default implementation returns 3 if the machine has an instruction for the division, and 2 if it does not.

Macro: MOVE_MAX ¶

  The maximum number of bytes that a single instruction can move quickly between memory and registers or between two memory locations.

Macro: MAX_MOVE_MAX ¶

  The maximum number of bytes that a single instruction can move quickly between memory and registers or between two memory locations. If this is undefined, the default is `MOVE_MAX`. Otherwise, it is the constant value that is the largest value that `MOVE_MAX` can have at run-time.

Macro: SHIFT_COUNT_TRUNCATED ¶

  A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object being shifted. When this macro is nonzero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise ‘and’ instructions that truncates the count of a shift operation. On machines that have instructions that act on bit-fields at variable positions, which may include ‘bit test’ instructions, a nonzero `SHIFT_COUNT_TRUNCATED` also enables deletion of truncations of the values that serve as arguments to bit-field instructions.

  If both types of instructions truncate the count (for shifts) and position (for bit-field operations), or if no variable-position bit-field instructions exist, you should define this macro.

  However, on some machines, such as the 80386 and the 680x0, truncation only applies to shift operations and not the (real or pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED` to be zero on such machines. Instead, add patterns to the `md` file that include the implied truncation of the shift instructions.

  You need not define this macro if it would always have the value of zero.

Target Hook: `unsigned HOST_WIDE_INT` TARGET_SHIFT_TRUNCATION_MASK `(machine_mode mode)` ¶

  This function describes how the standard shift patterns for mode deal with shifts by negative amounts or by more than the width of the mode. See shift patterns.

  On many machines, the shift patterns will apply a mask m to the shift count, meaning that a fixed-width shift of x by y is equivalent to an arbitrary-width shift of x by y & m. If this is true for mode mode, the function should return m, otherwise it should return 0. A return value of 0 indicates that no particular behavior is guaranteed.

  Note that, unlike `SHIFT_COUNT_TRUNCATED`, this function does not apply to general shift rtxes; it applies only to instructions that are generated by the named shift patterns.

  The default implementation of this function returns `GET_MODE_BITSIZE (mode) - 1` if `SHIFT_COUNT_TRUNCATED` and 0 otherwise. This definition is always safe, but if `SHIFT_COUNT_TRUNCATED` is false, and some shift patterns nevertheless truncate the shift count, you may get better code by overriding it.

Target Hook: `bool` TARGET_TRULY_NOOP_TRUNCATION `(poly_uint64 outprec, poly_uint64 inprec)` ¶

  This hook returns true if it is safe to “convert” a value of inprec bits to one of outprec bits (where outprec is smaller than inprec) by merely operating on it as if it had only outprec bits. The default returns true unconditionally, which is correct for most machines. When `TARGET_TRULY_NOOP_TRUNCATION` returns false, the machine description should provide a `trunc` optab to specify the RTL that performs the required truncation.

  If `TARGET_MODES_TIEABLE_P` returns false for a pair of modes, suboptimal code can result if this hook returns true for the corresponding mode sizes. Making this hook return false in such cases may improve things.

Target Hook: `int` TARGET_MODE_REP_EXTENDED `(scalar_int_mode mode, scalar_int_mode rep_mode)` ¶

  The representation of an integral mode can be such that the values are always extended to a wider integral mode. Return `SIGN_EXTEND` if values of mode are represented in sign-extended form to rep_mode. Return `UNKNOWN` otherwise. (Currently, none of the targets use zero-extended representation this way so unlike `LOAD_EXTEND_OP`, `TARGET_MODE_REP_EXTENDED` is expected to return either `SIGN_EXTEND` or `UNKNOWN`. Also no target extends mode to rep_mode so that rep_mode is not the next widest integral mode and currently we take advantage of this fact.)

  Similarly to `LOAD_EXTEND_OP` you may return a non-`UNKNOWN` value even if the extension is not performed on certain hard registers as long as for the `REGNO_REG_CLASS` of these hard registers `TARGET_CAN_CHANGE_MODE_CLASS` returns false.

  Note that `TARGET_MODE_REP_EXTENDED` and `LOAD_EXTEND_OP` describe two related properties. If you define `TARGET_MODE_REP_EXTENDED (mode, word_mode)` you probably also want to define `LOAD_EXTEND_OP (mode)` to return the same type of extension.

  In order to enforce the representation of `mode`, `TARGET_TRULY_NOOP_TRUNCATION` should return false when truncating to `mode`.

Target Hook: `bool` TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P `(void)` ¶

  On some targets, it is assumed that the compiler will spill all pseudos that are live across a call to `setjmp`, while other targets treat `setjmp` calls as normal function calls.

  This hook returns false if `setjmp` calls do not preserve all non-volatile registers so that gcc that must spill all pseudos that are live across `setjmp` calls. Define this to return true if the target does not need to spill all pseudos live across `setjmp` calls. The default implementation conservatively assumes all pseudos must be spilled across `setjmp` calls.

Macro: STORE_FLAG_VALUE ¶

  A C expression describing the value returned by a comparison operator with an integral mode and stored by a store-flag instruction (‘`cstoremode4`’) when the condition is true. This description must apply to all the ‘`cstoremode4`’ patterns and all the comparison operators whose results have a `MODE_INT` mode.

  A value of 1 or −1 means that the instruction implementing the comparison operator returns exactly 1 or −1 when the comparison is true and 0 when the comparison is false. Otherwise, the value indicates which bits of the result are guaranteed to be 1 when the comparison is true. This value is interpreted in the mode of the comparison operation, which is given by the mode of the first operand in the ‘`cstoremode4`’ pattern. Either the low bit or the sign bit of `STORE_FLAG_VALUE` be on. Presently, only those bits are used by the compiler.

  If `STORE_FLAG_VALUE` is neither 1 or −1, the compiler will generate code that depends only on the specified bits. It can also replace comparison operators with equivalent operations if they cause the required bits to be set, even if the remaining bits are undefined. For example, on a machine whose comparison operators return an `SImode` value and where `STORE_FLAG_VALUE` is defined as ‘`0x80000000`’, saying that just the sign bit is relevant, the expression

      (ne:SI (and:SI x (const_int power-of-2)) (const_int 0))

  can be converted to

      (ashift:SI x (const_int n))

  where n is the appropriate shift count to move the bit being tested into the sign bit.

  There is no way to describe a machine that always sets the low-order bit for a true value, but does not guarantee the value of any other bits, but we do not know of any machine that has such an instruction. If you are trying to port GCC to such a machine, include an instruction to perform a logical-and of the result with 1 in the pattern for the comparison operators and let us know at gcc@gcc.gnu.org.

  Often, a machine will have multiple instructions that obtain a value from a comparison (or the condition codes). Here are rules to guide the choice of value for `STORE_FLAG_VALUE`, and hence the instructions to be used:

  - Use the shortest sequence that yields a valid definition for `STORE_FLAG_VALUE`. It is more efficient for the compiler to “normalize” the value (convert it to, e.g., 1 or 0) than for the comparison operators to do so because there may be opportunities to combine the normalization with other operations.
  - For equal-length sequences, use a value of 1 or −1, with −1 being slightly preferred on machines with expensive jumps and 1 preferred on other machines.
  - As a second choice, choose a value of ‘`0x80000001`’ if instructions exist that set both the sign and low-order bits but do not define the others.
  - Otherwise, use a value of ‘`0x80000000`’.

  Many machines can produce both the value chosen for `STORE_FLAG_VALUE` and its negation in the same number of instructions. On those machines, you should also define a pattern for those cases, e.g., one matching

      (set A (neg:m (ne:m B C)))

  Some machines can also perform `and` or `plus` operations on condition code values with less instructions than the corresponding ‘`cstoremode4`’ insn followed by `and` or `plus`. On those machines, define the appropriate patterns. Use the names `incscc` and `decscc`, respectively, for the patterns which perform `plus` or `minus` operations on condition code values. See `rs6000.md` for some examples. The GNU Superoptimizer can be used to find such instruction sequences on other machines.

  If this macro is not defined, the default value, 1, is used. You need not define `STORE_FLAG_VALUE` if the machine has no store-flag instructions, or if the value generated by these instructions is 1.

Macro: FLOAT_STORE_FLAG_VALUE (mode) ¶

  A C expression that gives a nonzero `REAL_VALUE_TYPE` value that is returned when comparison operators with floating-point results are true. Define this macro on machines that have comparison operations that return floating-point values. If there are no such operations, do not define this macro.

Macro: VECTOR_STORE_FLAG_VALUE (mode) ¶

  A C expression that gives an rtx representing the nonzero true element for vector comparisons. The returned rtx should be valid for the inner mode of mode which is guaranteed to be a vector mode. Define this macro on machines that have vector comparison operations that return a vector result. If there are no such operations, do not define this macro. Typically, this macro is defined as `const1_rtx` or `constm1_rtx`. This macro may return `NULL_RTX` to prevent the compiler optimizing such vector comparison operations for the given mode.

Macro: CLZ_DEFINED_VALUE_AT_ZERO (mode, value) ¶
Macro: CTZ_DEFINED_VALUE_AT_ZERO (mode, value) ¶

  A C expression that indicates whether the architecture defines a value for `clz` or `ctz` with a zero operand. A result of `0` indicates the value is undefined. If the value is defined for only the RTL expression, the macro should evaluate to `1`; if the value applies also to the corresponding optab entry (which is normally the case if it expands directly into the corresponding RTL), then the macro should evaluate to `2`. In the cases where the value is defined, value should be set to this value.

  If this macro is not defined, the value of `clz` or `ctz` at zero is assumed to be undefined.

  This macro must be defined if the target’s expansion for `ffs` relies on a particular value to get correct results. Otherwise it is not necessary, though it may be used to optimize some corner cases, and to provide a default expansion for the `ffs` optab.

  Note that regardless of this macro the “definedness” of `clz` and `ctz` at zero do not extend to the builtin functions visible to the user. Thus one may be free to adjust the value at will to match the target expansion of these operations without fear of breaking the API.

Macro: Pmode ¶

  An alias for the machine mode for pointers. On most machines, define this to be the integer mode corresponding to the width of a hardware pointer; `SImode` on 32-bit machine or `DImode` on 64-bit machines. On some machines you must define this to be one of the partial integer modes, such as `PSImode`.

  The width of `Pmode` must be at least as large as the value of `POINTER_SIZE`. If it is not equal, you must define the macro `POINTERS_EXTEND_UNSIGNED` to specify how pointers are extended to `Pmode`.

Macro: FUNCTION_MODE ¶

  An alias for the machine mode used for memory references to functions being called, in `call` RTL expressions. On most CISC machines, where an instruction can begin at any byte address, this should be `QImode`. On most RISC machines, where all instructions have fixed size and alignment, this should be a mode with the same size and alignment as the machine instruction words - typically `SImode` or `HImode`.

Macro: STDC_0_IN_SYSTEM_HEADERS ¶

  In normal operation, the preprocessor expands `__STDC__` to the constant 1, to signify that GCC conforms to ISO Standard C. On some hosts, like Solaris, the system compiler uses a different convention, where `__STDC__` is normally 0, but is 1 if the user specifies strict conformance to the C Standard.

  Defining `STDC_0_IN_SYSTEM_HEADERS` makes GNU CPP follows the host convention when processing system header files, but when processing user files `__STDC__` will always expand to 1.

C Target Hook: `const char *` TARGET_C_PREINCLUDE `(void)` ¶

  Define this hook to return the name of a header file to be included at the start of all compilations, as if it had been included with `#include <file>`. If this hook returns `NULL`, or is not defined, or the header is not found, or if the user specifies `-ffreestanding` or `-nostdinc`, no header is included.

  This hook can be used together with a header provided by the system C library to implement ISO C requirements for certain macros to be predefined that describe properties of the whole implementation rather than just the compiler.

C Target Hook: `bool` TARGET_CXX_IMPLICIT_EXTERN_C `(const char*)` ¶

  Define this hook to add target-specific C++ implicit extern C functions. If this function returns true for the name of a file-scope function, that function implicitly gets extern "C" linkage rather than whatever language linkage the declaration would normally have. An example of such function is WinMain on Win32 targets.

Macro: SYSTEM_IMPLICIT_EXTERN_C ¶

  Define this macro if the system header files do not support C++. This macro handles system header files by pretending that system header files are enclosed in ‘`extern "C" {…}`’.

Macro: REGISTER_TARGET_PRAGMAS () ¶

  Define this macro if you want to implement any target-specific pragmas. If defined, it is a C expression which makes a series of calls to `c_register_pragma` or `c_register_pragma_with_expansion` for each pragma. The macro may also do any setup required for the pragmas.

  The primary reason to define this macro is to provide compatibility with other compilers for the same target. In general, we discourage definition of target-specific pragmas for GCC.

  If the pragma can be implemented by attributes then you should consider defining the target hook ‘`TARGET_INSERT_ATTRIBUTES`’ as well.

  Preprocessor macros that appear on pragma lines are not expanded. All ‘`#pragma`’ directives that do not match any registered pragma are silently ignored, unless the user specifies `-Wunknown-pragmas`.

Function: `void` c_register_pragma `(const char *space, const char *name, void (*callback) (struct cpp_reader *))` ¶
Function: `void` c_register_pragma_with_expansion `(const char *space, const char *name, void (*callback) (struct cpp_reader *))` ¶

  Each call to `c_register_pragma` or `c_register_pragma_with_expansion` establishes one pragma. The callback routine will be called when the preprocessor encounters a pragma of the form

      #pragma [space] name ...

  space is the case-sensitive namespace of the pragma, or `NULL` to put the pragma in the global namespace. The callback routine receives pfile as its first argument, which can be passed on to cpplib’s functions if necessary. You can lex tokens after the name by calling `pragma_lex`. Tokens that are not read by the callback will be silently ignored. The end of the line is indicated by a token of type `CPP_EOF`. Macro expansion occurs on the arguments of pragmas registered with `c_register_pragma_with_expansion` but not on the arguments of pragmas registered with `c_register_pragma`.

  Note that the use of `pragma_lex` is specific to the C and C++ compilers. It will not work in the Java or Fortran compilers, or any other language compilers for that matter. Thus if `pragma_lex` is going to be called from target-specific code, it must only be done so when building the C and C++ compilers. This can be done by defining the variables `c_target_objs` and `cxx_target_objs` in the target entry in the `config.gcc` file. These variables should name the target-specific, language-specific object file which contains the code that uses `pragma_lex`. Note it will also be necessary to add a rule to the makefile fragment pointed to by `tmake_file` that shows how to build this object file.

Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION ¶

  Define this macro if macros should be expanded in the arguments of ‘`#pragma pack`’.

Macro: TARGET_DEFAULT_PACK_STRUCT ¶

  If your target requires a structure packing default other than 0 (meaning the machine default), define this macro to the necessary value (in bytes). This must be a value that would also be valid to use with ‘`#pragma pack()`’ (that is, a small power of two).

Macro: DOLLARS_IN_IDENTIFIERS ¶

  Define this macro to control use of the character ‘`$`’ in identifier names for the C family of languages. 0 means ‘`$`’ is not allowed by default; 1 means it is allowed. 1 is the default; there is no need to define this macro in that case.

Macro: INSN_SETS_ARE_DELAYED (insn) ¶

  Define this macro as a C expression that is nonzero if it is safe for the delay slot scheduler to place instructions in the delay slot of insn, even if they appear to use a resource set or clobbered in insn. insn is always a `jump_insn` or an `insn`; GCC knows that every `call_insn` has this behavior. On machines where some `insn` or `jump_insn` is really a function call and hence has this behavior, you should define this macro.

  You need not define this macro if it would always return zero.

Macro: INSN_REFERENCES_ARE_DELAYED (insn) ¶

  Define this macro as a C expression that is nonzero if it is safe for the delay slot scheduler to place instructions in the delay slot of insn, even if they appear to set or clobber a resource referenced in insn. insn is always a `jump_insn` or an `insn`. On machines where some `insn` or `jump_insn` is really a function call and its operands are registers whose use is actually in the subroutine it calls, you should define this macro. Doing so allows the delay slot scheduler to move instructions which copy arguments into the argument registers into the delay slot of insn.

  You need not define this macro if it would always return zero.

Macro: MULTIPLE_SYMBOL_SPACES ¶

  Define this macro as a C expression that is nonzero if, in some cases, global symbols from one translation unit may not be bound to undefined symbols in another translation unit without user intervention. For instance, under Microsoft Windows symbols must be explicitly imported from shared libraries (DLLs).

  You need not define this macro if it would always evaluate to zero.

Target Hook: `rtx_insn *` TARGET_MD_ASM_ADJUST `(vec<rtx>& outputs, vec<rtx>& inputs, vec<machine_mode>& input_modes, vec<const char *>& constraints, vec<rtx>& usess, vec<rtx>& clobbers, HARD_REG_SET& clobbered_regs, location_t loc)` ¶

  This target hook may add clobbers to clobbers and clobbered_regs for any hard regs the port wishes to automatically clobber for an asm. It can also add hard registers that are used by the asm to uses. The outputs and inputs may be inspected to avoid clobbering a register that is already used by the asm. loc is the source location of the asm.

  It may modify the outputs, inputs, input_modes, and constraints as necessary for other pre-processing. In this case the return value is a sequence of insns to emit after the asm. Note that changes to inputs must be accompanied by the corresponding changes to input_modes.

Macro: MATH_LIBRARY ¶

  Define this macro as a C string constant for the linker argument to link in the system math library, minus the initial ‘`"-l"`’, or ‘`""`’ if the target does not have a separate math library.

  You need only define this macro if the default of ‘`"m"`’ is wrong.

Macro: LIBRARY_PATH_ENV ¶

  Define this macro as a C string constant for the environment variable that specifies where the linker should look for libraries.

  You need only define this macro if the default of ‘`"LIBRARY_PATH"`’ is wrong.

Macro: TARGET_POSIX_IO ¶

  Define this macro if the target supports the following POSIX file functions, access, mkdir and file locking with fcntl / F_SETLKW. Defining `TARGET_POSIX_IO` will enable the test coverage code to use file locking when exiting a program, which avoids race conditions if the program has forked. It will also create directories at run-time for cross-profiling.

Macro: MAX_CONDITIONAL_EXECUTE ¶

  A C expression for the maximum number of instructions to execute via conditional execution instructions instead of a branch. A value of `BRANCH_COST`+1 is the default.

Macro: IFCVT_MODIFY_TESTS (ce_info, true_expr, false_expr) ¶

  Used if the target needs to perform machine-dependent modifications on the conditionals used for turning basic blocks into conditionally executed code. ce_info points to a data structure, `struct ce_if_block`, which contains information about the currently processed blocks. true_expr and false_expr are the tests that are used for converting the then-block and the else-block, respectively. Set either true_expr or false_expr to a null pointer if the tests cannot be converted.

Macro: IFCVT_MODIFY_MULTIPLE_TESTS (ce_info, bb, true_expr, false_expr) ¶

  Like `IFCVT_MODIFY_TESTS`, but used when converting more complicated if-statements into conditions combined by `and` and `or` operations. bb contains the basic block that contains the test that is currently being processed and about to be turned into a condition.

Macro: IFCVT_MODIFY_INSN (ce_info, pattern, insn) ¶

  A C expression to modify the PATTERN of an INSN that is to be converted to conditional execution format. ce_info points to a data structure, `struct ce_if_block`, which contains information about the currently processed blocks.

Macro: IFCVT_MODIFY_FINAL (ce_info) ¶

  A C expression to perform any final machine dependent modifications in converting code to conditional execution. The involved basic blocks can be found in the `struct ce_if_block` structure that is pointed to by ce_info.

Macro: IFCVT_MODIFY_CANCEL (ce_info) ¶

  A C expression to cancel any machine dependent modifications in converting code to conditional execution. The involved basic blocks can be found in the `struct ce_if_block` structure that is pointed to by ce_info.

Macro: IFCVT_MACHDEP_INIT (ce_info) ¶

  A C expression to initialize any machine specific data for if-conversion of the if-block in the `struct ce_if_block` structure that is pointed to by ce_info.

Target Hook: `bool` TARGET_USE_LATE_PROLOGUE_EPILOGUE `()` ¶

  Return true if the current function’s prologue and epilogue should be emitted late in the pass pipeline, instead of at the usual point.

  Normally, the prologue and epilogue sequences are introduced soon after register allocation is complete. The advantage of this approach is that it allows the prologue and epilogue instructions to be optimized and scheduled with other code in the function. However, some targets require the prologue and epilogue to be the first and last sequences executed by the function, with no variation allowed. This hook should return true on such targets.

  The default implementation returns false, which is correct for most targets. The hook should only return true if there is a specific target limitation that cannot be described in RTL. For example, the hook might return true if the prologue and epilogue need to switch between instruction sets.

Target Hook: `void` TARGET_EMIT_EPILOGUE_FOR_SIBCALL `(rtx_call_insn *call)` ¶

  If defined, this hook emits an epilogue sequence for sibling (tail) call instruction call. Another way of providing epilogues for sibling calls is to define the `sibcall_epilogue` instruction pattern; the main advantage of this hook over the pattern is that it has access to the call instruction.

Target Hook: `void` TARGET_MACHINE_DEPENDENT_REORG `(void)` ¶

  If non-null, this hook performs a target-specific pass over the instruction stream. The compiler will run it at all optimization levels, just before the point at which it normally does delayed-branch scheduling.

  The exact purpose of the hook varies from target to target. Some use it to do transformations that are necessary for correctness, such as laying out in-function constant pools or avoiding hardware hazards. Others use it as an opportunity to do some machine-dependent optimizations.

  You need not implement the hook if it has nothing to do. The default definition is null.

Target Hook: `void` TARGET_INIT_BUILTINS `(void)` ¶

  Define this hook if you have any machine-specific built-in functions that need to be defined. It should be a function that performs the necessary setup.

  Machine specific built-in functions can be useful to expand special machine instructions that would otherwise not normally be generated because they have no equivalent in the source language (for example, SIMD vector instructions or prefetch instructions).

  To create a built-in function, call the function `lang_hooks.builtin_function` which is defined by the language front end. You can use any type nodes set up by `build_common_tree_nodes`; only language front ends that use those two functions will call ‘`TARGET_INIT_BUILTINS`’.

Target Hook: `tree` TARGET_BUILTIN_DECL `(unsigned code, bool initialize_p)` ¶

  Define this hook if you have any machine-specific built-in functions that need to be defined. It should be a function that returns the builtin function declaration for the builtin function code code. If there is no such builtin and it cannot be initialized at this time if initialize_p is true the function should return `NULL_TREE`. If code is out of range the function should return `error_mark_node`.

Target Hook: `rtx` TARGET_EXPAND_BUILTIN `(tree exp, rtx target, rtx subtarget, machine_mode mode, int ignore)` ¶

  Expand a call to a machine specific built-in function that was set up by ‘`TARGET_INIT_BUILTINS`’. exp is the expression for the function call; the result should go to target if that is convenient, and have mode mode if that is convenient. subtarget may be used as the target for computing one of exp’s operands. ignore is nonzero if the value is to be ignored. This function should return the result of the call to the built-in function.

Target Hook: `tree` TARGET_RESOLVE_OVERLOADED_BUILTIN `(location_t loc, tree fndecl, void *arglist, bool complain)` ¶

  Select a replacement for a machine specific built-in function that was set up by ‘`TARGET_INIT_BUILTINS`’. This is done before regular type checking, and so allows the target to implement a crude form of function overloading. fndecl is the declaration of the built-in function. arglist is the list of arguments passed to the built-in function. The result is a complete expression that implements the operation, usually another `CALL_EXPR`. arglist really has type ‘`VEC(tree,gc)*`’ complain is a boolean indicating whether invalid operations should emit errors. This is set to `false` when the C++ templating context expects that errors should not be emitted (i.e. SFINAE).

Target Hook: `bool` TARGET_CHECK_BUILTIN_CALL `(location_t loc, vec<location_t> arg_loc, tree fndecl, tree orig_fndecl, unsigned int nargs, tree *args, bool complain)` ¶

  Perform semantic checking on a call to a machine-specific built-in function after its arguments have been constrained to the function signature. Return true if the call is valid, otherwise report an error and return false.

  This hook is called after `TARGET_RESOLVE_OVERLOADED_BUILTIN`. The call was originally to built-in function orig_fndecl, but after the optional `TARGET_RESOLVE_OVERLOADED_BUILTIN` step is now to built-in function fndecl. loc is the location of the call and args is an array of function arguments, of which there are nargs. arg_loc specifies the location of each argument. complain is a boolean indicating whether invalid arguments should emitm errors. This is set to `false` when the C++ templating context expects that errors should not be emitted (i.e. SFINAE).

Target Hook: `tree` TARGET_FOLD_BUILTIN `(tree fndecl, int n_args, tree *argp, bool ignore)` ¶

  Fold a call to a machine specific built-in function that was set up by ‘`TARGET_INIT_BUILTINS`’. fndecl is the declaration of the built-in function. n_args is the number of arguments passed to the function; the arguments themselves are pointed to by argp. The result is another tree, valid for both GIMPLE and GENERIC, containing a simplified expression for the call’s result. If ignore is true the value will be ignored.

Target Hook: `bool` TARGET_GIMPLE_FOLD_BUILTIN `(gimple_stmt_iterator *gsi)` ¶

  Fold a call to a machine specific built-in function that was set up by ‘`TARGET_INIT_BUILTINS`’. gsi points to the gimple statement holding the function call. Returns true if any change was made to the GIMPLE stream.

Target Hook: `int` TARGET_COMPARE_VERSION_PRIORITY `(tree decl1, tree decl2)` ¶

  This hook is used to compare the target attributes in two functions to determine which function’s features get higher priority. This is used during function multi-versioning to figure out the order in which two versions must be dispatched. A function version with a higher priority is checked for dispatching earlier. decl1 and decl2 are the two function decls that will be compared.

Target Hook: `tree` TARGET_GET_FUNCTION_VERSIONS_DISPATCHER `(void *decl)` ¶

  This hook is used to get the dispatcher function for a set of function versions. The dispatcher function is called to invoke the right function version at run-time. decl is one version from a set of semantically identical versions.

Target Hook: `tree` TARGET_GENERATE_VERSION_DISPATCHER_BODY `(void *arg)` ¶

  This hook is used to generate the dispatcher logic to invoke the right function version at run-time for a given set of function versions. arg points to the callgraph node of the dispatcher function whose body must be generated.

Target Hook: `bool` TARGET_CHECK_TARGET_CLONE_VERSION `(string_slice str, location_t *loc)` ¶

  This hook is used to check if a version specified in a `target_clones` annotation is valid. str is the version to be considered. If loc is not `NULL` then emit warnings for invalid versions at that location. Otherwise emit no diagnostics. Returns `true` if str is a valid version string, and `false` otherwise

Target Hook: `bool` TARGET_PREDICT_DOLOOP_P `(class loop *loop)` ¶

  Return true if we can predict it is possible to use a low-overhead loop for a particular loop. The parameter loop is a pointer to the loop. This target hook is required only when the target supports low-overhead loops, and will help ivopts to make some decisions. The default version of this hook returns false.

Target Hook: `bool` TARGET_HAVE_COUNT_REG_DECR_P ¶

  Return true if the target supports hardware count register for decrement and branch. The default value is false.

Target Hook: `int64_t` TARGET_DOLOOP_COST_FOR_GENERIC ¶

  One IV candidate dedicated for doloop is introduced in IVOPTs, we can calculate the computation cost of adopting it to any generic IV use by function get_computation_cost as before. But for targets which have hardware count register support for decrement and branch, it may have to move IV value from hardware count register to general purpose register while doloop IV candidate is used for generic IV uses. It probably takes expensive penalty. This hook allows target owners to define the cost for this especially for generic IV uses. The default value is zero.

Target Hook: `int64_t` TARGET_DOLOOP_COST_FOR_ADDRESS ¶

  One IV candidate dedicated for doloop is introduced in IVOPTs, we can calculate the computation cost of adopting it to any address IV use by function get_computation_cost as before. But for targets which have hardware count register support for decrement and branch, it may have to move IV value from hardware count register to general purpose register while doloop IV candidate is used for address IV uses. It probably takes expensive penalty. This hook allows target owners to define the cost for this especially for address IV uses. The default value is zero.

Target Hook: `bool` TARGET_CAN_USE_DOLOOP_P `(const widest_int &iterations, const widest_int &iterations_max, unsigned int loop_depth, bool entered_at_top)` ¶

  Return true if it is possible to use low-overhead loops (`doloop_end` and `doloop_begin`) for a particular loop. iterations gives the exact number of iterations, or 0 if not known. iterations_max gives the maximum number of iterations, or 0 if not known. loop_depth is the nesting depth of the loop, with 1 for innermost loops, 2 for loops that contain innermost loops, and so on. entered_at_top is true if the loop is only entered from the top.

  This hook is only used if `doloop_end` is available. The default implementation returns true. You can use `can_use_doloop_if_innermost` if the loop must be the innermost, and if there are no other restrictions.

Target Hook: `const char *` TARGET_INVALID_WITHIN_DOLOOP `(const rtx_insn *insn)` ¶

  Take an instruction in insn and return NULL if it is valid within a low-overhead loop, otherwise return a string explaining why doloop could not be applied.

  Many targets use special registers for low-overhead looping. For any instruction that clobbers these this function should return a string indicating the reason why the doloop could not be applied. By default, the RTL loop optimizer does not use a present doloop pattern for loops containing function calls or branch on table instructions.

Target Hook: `machine_mode` TARGET_PREFERRED_DOLOOP_MODE `(machine_mode mode)` ¶

  This hook takes a mode for a doloop IV, where `mode` is the original mode for the operation. If the target prefers an alternate `mode` for the operation, then this hook should return that mode; otherwise the original `mode` should be returned. For example, on a 64-bit target, `DImode` might be preferred over `SImode`. Both the original and the returned modes should be `MODE_INT`.

Target Hook: `bool` TARGET_LEGITIMATE_COMBINED_INSN `(rtx_insn *insn)` ¶

  Take an instruction in insn and return `false` if the instruction is not appropriate as a combination of two or more instructions. The default is to accept all instructions.

Target Hook: `bool` TARGET_CAN_FOLLOW_JUMP `(const rtx_insn *follower, const rtx_insn *followee)` ¶

  FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if FOLLOWER may be modified to follow FOLLOWEE; false, if it can’t. For example, on some targets, certain kinds of branches can’t be made to follow through a hot/cold partitioning.

Target Hook: `bool` TARGET_COMMUTATIVE_P `(const_rtx x, int outer_code)` ¶

  This target hook returns `true` if x is considered to be commutative. Usually, this is just COMMUTATIVE_P (x), but the HP PA doesn’t consider PLUS to be commutative inside a MEM. outer_code is the rtx code of the enclosing rtl, if known, otherwise it is UNKNOWN.

Target Hook: `rtx` TARGET_ALLOCATE_INITIAL_VALUE `(rtx hard_reg)` ¶

  When the initial value of a hard register has been copied in a pseudo register, it is often not necessary to actually allocate another register to this pseudo register, because the original hard register or a stack slot it has been saved into can be used. `TARGET_ALLOCATE_INITIAL_VALUE` is called at the start of register allocation once for each hard register that had its initial value copied by using `get_func_hard_reg_initial_val` or `get_hard_reg_initial_val`. Possible values are `NULL_RTX`, if you don’t want to do any special allocation, a `REG` rtx—that would typically be the hard register itself, if it is known not to be clobbered—or a `MEM`. If you are returning a `MEM`, this is only a hint for the allocator; it might decide to use another register anyways. You may use `current_function_is_leaf` or `REG_N_SETS` in the hook to determine if the hard register in question will not be clobbered. The default value of this hook is `NULL`, which disables any special allocation.

Target Hook: `int` TARGET_UNSPEC_MAY_TRAP_P `(const_rtx x, unsigned flags)` ¶

  This target hook returns nonzero if x, an `unspec` might cause a trap. Targets can use this hook to enhance precision of analysis for `unspec` operations. You may call `may_trap_p_1` to analyze inner elements of x in which case flags should be passed along.

Target Hook: `void` TARGET_SET_CURRENT_FUNCTION `(tree decl)` ¶

  The compiler invokes this hook whenever it changes its current function context (`cfun`). You can define this function if the back end needs to perform any initialization or reset actions on a per-function basis. For example, it may be used to implement function attributes that affect register usage or code generation patterns. The argument decl is the declaration for the new function context, and may be null to indicate that the compiler has left a function context and is returning to processing at the top level. The default hook function does nothing.

  GCC sets `cfun` to a dummy function context during initialization of some parts of the back end. The hook function is not invoked in this situation; you need not worry about the hook being invoked recursively, or when the back end is in a partially-initialized state. `cfun` might be `NULL` to indicate processing at top level, outside of any function scope.

Macro: TARGET_OBJECT_SUFFIX ¶

  Define this macro to be a C string representing the suffix for object files on your target machine. If you do not define this macro, GCC will use ‘`.o`’ as the suffix for object files.

Macro: TARGET_EXECUTABLE_SUFFIX ¶

  Define this macro to be a C string representing the suffix to be automatically added to executable files on your target machine. If you do not define this macro, GCC will use the null string as the suffix for executable files.

Macro: COLLECT_EXPORT_LIST ¶

  If defined, `collect2` will scan the individual object files specified on its command line and create an export list for the linker. Define this macro for systems like AIX, where the linker discards object files that are not referenced from `main` and uses export lists.

Target Hook: `bool` TARGET_CANNOT_MODIFY_JUMPS_P `(void)` ¶

  This target hook returns `true` past the point in which new jump instructions could be created. On machines that require a register for every jump such as the SHmedia ISA of SH5, this point would typically be reload, so this target hook should be defined to a function such as:

      static bool
      cannot_modify_jumps_past_reload_p ()
      {
        return (reload_completed || reload_in_progress);
      }

Target Hook: `bool` TARGET_HAVE_CONDITIONAL_EXECUTION `(void)` ¶

  This target hook returns true if the target supports conditional execution. This target hook is required only when the target has several different modes and they have different conditional execution capability, such as ARM.

Target Hook: `rtx` TARGET_GEN_CCMP_FIRST `(rtx_insn **prep_seq, rtx_insn **gen_seq, rtx_code code, tree op0, tree op1)` ¶

  This function prepares to emit a comparison insn for the first compare in a sequence of conditional comparisons. It returns an appropriate comparison with `CC` for passing to `gen_ccmp_next` or `cbranch_optab`. The insns to prepare the compare are saved in prep_seq and the compare insns are saved in gen_seq. They will be emitted when all the compares in the conditional comparison are generated without error. code is the `rtx_code` of the compare for op0 and op1.

Target Hook: `rtx` TARGET_GEN_CCMP_NEXT `(rtx_insn **prep_seq, rtx_insn **gen_seq, rtx prev, rtx_code cmp_code, tree op0, tree op1, rtx_code bit_code)` ¶

  This function prepares to emit a conditional comparison within a sequence of conditional comparisons. It returns an appropriate comparison with `CC` for passing to `gen_ccmp_next` or `cbranch_optab`. The insns to prepare the compare are saved in prep_seq and the compare insns are saved in gen_seq. They will be emitted when all the compares in the conditional comparison are generated without error. The prev expression is the result of a prior call to `gen_ccmp_first` or `gen_ccmp_next`. It may return `NULL` if the combination of prev and this comparison is not supported, otherwise the result must be appropriate for passing to `gen_ccmp_next` or `cbranch_optab`. code is the `rtx_code` of the compare for op0 and op1. bit_code is `AND` or `IOR`, which is the op on the compares.

Target Hook: `bool` TARGET_HAVE_CCMP `(void)` ¶

  This target hook returns true if the target supports conditional compare. This target hook is required only when the ccmp support is conditionally enabled, such as in response to command-line flags. The default implementation returns true iff `TARGET_GEN_CCMP_FIRST` is defined.

Target Hook: `unsigned` TARGET_LOOP_UNROLL_ADJUST `(unsigned nunroll, class loop *loop)` ¶

  This target hook returns a new value for the number of times loop should be unrolled. The parameter nunroll is the number of times the loop is to be unrolled. The parameter loop is a pointer to the loop, which is going to be checked for unrolling. This target hook is required only when the target has special constraints like maximum number of memory accesses.

Macro: POWI_MAX_MULTS ¶

  If defined, this macro is interpreted as a signed integer C expression that specifies the maximum number of floating point multiplications that should be emitted when expanding exponentiation by an integer constant inline. When this value is defined, exponentiation requiring more than this number of multiplications is implemented by calling the system library’s `pow`, `powf` or `powl` routines. The default value places no upper bound on the multiplication count.

Macro: `void` TARGET_EXTRA_INCLUDES `(const char *sysroot, const char *iprefix, int stdinc)` ¶

  This target hook should register any extra include files for the target. The parameter stdinc indicates if normal include files are present. The parameter sysroot is the system root directory. The parameter iprefix is the prefix for the gcc directory.

Macro: `void` TARGET_EXTRA_PRE_INCLUDES `(const char *sysroot, const char *iprefix, int stdinc)` ¶

  This target hook should register any extra include files for the target before any standard headers. The parameter stdinc indicates if normal include files are present. The parameter sysroot is the system root directory. The parameter iprefix is the prefix for the gcc directory.

Macro: `void` TARGET_OPTF `(char *path)` ¶

  This target hook should register special include paths for the target. The parameter path is the include to register. On Darwin systems, this is used for Framework includes, which have semantics that are different from `-I`.

Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree fndecl) ¶

  This target macro returns `true` if it is safe to use a local alias for a virtual function fndecl when constructing thunks, `false` otherwise. By default, the macro returns `true` for all functions, if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF`), `false` otherwise,

Macro: TARGET_FORMAT_TYPES ¶

  If defined, this macro is the name of a global variable containing target-specific format checking information for the `-Wformat` option. The default is to have no target-specific format checks.

Macro: TARGET_N_FORMAT_TYPES ¶

  If defined, this macro is the number of entries in `TARGET_FORMAT_TYPES`.

Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES ¶

  If defined, this macro is the name of a global variable containing target-specific format overrides for the `-Wformat` option. The default is to have no target-specific format overrides. If defined, `TARGET_FORMAT_TYPES` and `TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT` must be defined, too.

Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT ¶

  If defined, this macro specifies the number of entries in `TARGET_OVERRIDES_FORMAT_ATTRIBUTES`.

Macro: TARGET_OVERRIDES_FORMAT_INIT ¶

  If defined, this macro specifies the optional initialization routine for target specific customizations of the system printf and scanf formatter settings.

Target Hook: `const char *` TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN `(const_tree typelist, const_tree funcdecl, const_tree val)` ¶

  If defined, this macro returns the diagnostic message when it is illegal to pass argument val to function funcdecl with prototype typelist.

Target Hook: `const char *` TARGET_INVALID_CONVERSION `(const_tree fromtype, const_tree totype)` ¶

  If defined, this macro returns the diagnostic message when it is invalid to convert from fromtype to totype, or `NULL` if validity should be determined by the front end.

Target Hook: `const char *` TARGET_INVALID_UNARY_OP `(int op, const_tree type)` ¶

  If defined, this macro returns the diagnostic message when it is invalid to apply operation op (where unary plus is denoted by `CONVERT_EXPR`) to an operand of type type, or `NULL` if validity should be determined by the front end.

Target Hook: `const char *` TARGET_INVALID_BINARY_OP `(int op, const_tree type1, const_tree type2)` ¶

  If defined, this macro returns the diagnostic message when it is invalid to apply operation op to operands of types type1 and type2, or `NULL` if validity should be determined by the front end.

Target Hook: `tree` TARGET_PROMOTED_TYPE `(const_tree type)` ¶

  If defined, this target hook returns the type to which values of type should be promoted when they appear in expressions, analogous to the integer promotions, or `NULL_TREE` to use the front end’s normal promotion rules. This hook is useful when there are target-specific types with special promotion rules. This is currently used only by the C and C++ front ends.

Target Hook: `tree` TARGET_CONVERT_TO_TYPE `(tree type, tree expr)` ¶

  If defined, this hook returns the result of converting expr to type. It should return the converted expression, or `NULL_TREE` to apply the front end’s normal conversion rules. This hook is useful when there are target-specific types with special conversion rules. This is currently used only by the C and C++ front ends.

Target Hook: `bool` TARGET_VERIFY_TYPE_CONTEXT `(location_t loc, type_context_kind context, const_tree type, bool silent_p)` ¶

  If defined, this hook returns false if there is a target-specific reason why type type cannot be used in the source language context described by context. When silent_p is false, the hook also reports an error against loc for invalid uses of type.

  Calls to this hook should be made through the global function `verify_type_context`, which makes the silent_p parameter default to false and also handles `error_mark_node`.

  The default implementation always returns true.

Macro: OBJC_JBLEN ¶

  This macro determines the size of the objective C jump buffer for the NeXT runtime. By default, OBJC_JBLEN is defined to an innocuous value.

Macro: LIBGCC2_UNWIND_ATTRIBUTE ¶

  Define this macro if any target-specific attributes need to be attached to the functions in `libgcc` that provide low-level support for call stack unwinding. It is used in declarations in `unwind-generic.h` and the associated definitions of those functions.

Target Hook: `void` TARGET_UPDATE_STACK_BOUNDARY `(void)` ¶

  Define this macro to update the current function stack boundary if necessary.

Target Hook: `rtx` TARGET_GET_DRAP_RTX `(void)` ¶

  This hook should return an rtx for Dynamic Realign Argument Pointer (DRAP) if a different argument pointer register is needed to access the function’s argument list due to stack realignment. Return `NULL` if no DRAP is needed.

Target Hook: `HARD_REG_SET` TARGET_ZERO_CALL_USED_REGS `(HARD_REG_SET selected_regs)` ¶

  This target hook emits instructions to zero the subset of selected_regs that could conceivably contain values that are useful to an attacker. Return the set of registers that were actually cleared.

  For most targets, the returned set of registers is a subset of selected_regs, however, for some of the targets (for example MIPS), clearing some registers that are in the selected_regs requires clearing other call used registers that are not in the selected_regs, under such situation, the returned set of registers must be a subset of all call used registers.

  The default implementation uses normal move instructions to zero all the registers in selected_regs. Define this hook if the target has more efficient ways of zeroing certain registers, or if you believe that certain registers would never contain values that are useful to an attacker.

Target Hook: `bool` TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS `(void)` ¶

  When optimization is disabled, this hook indicates whether or not arguments should be allocated to stack slots. Normally, GCC allocates stacks slots for arguments when not optimizing in order to make debugging easier. However, when a function is declared with `__attribute__((naked))`, there is no stack frame, and the compiler cannot safely move arguments from the registers in which they are passed to the stack. Therefore, this hook should return true in general, but false for naked functions. The default implementation always returns true.

Target Hook: `unsigned HOST_WIDE_INT` TARGET_CONST_ANCHOR ¶

  On some architectures it can take multiple instructions to synthesize a constant. If there is another constant already in a register that is close enough in value then it is preferable that the new constant is computed from this register using immediate addition or subtraction. We accomplish this through CSE. Besides the value of the constant we also add a lower and an upper constant anchor to the available expressions. These are then queried when encountering new constants. The anchors are computed by rounding the constant up and down to a multiple of the value of `TARGET_CONST_ANCHOR`. `TARGET_CONST_ANCHOR` should be the maximum positive value accepted by immediate-add plus one. We currently assume that the value of `TARGET_CONST_ANCHOR` is a power of 2. For example, on MIPS, where add-immediate takes a 16-bit signed value, `TARGET_CONST_ANCHOR` is set to ‘`0x8000`’. The default value is zero, which disables this optimization.

Target Hook: `unsigned HOST_WIDE_INT` TARGET_ASAN_SHADOW_OFFSET `(void)` ¶

  Return the offset bitwise ored into shifted address to get corresponding Address Sanitizer shadow memory address. NULL if Address Sanitizer is not supported by the target. May return 0 if Address Sanitizer is not supported or using dynamic shadow offset by a subtarget.

Target Hook: `bool` TARGET_ASAN_DYNAMIC_SHADOW_OFFSET_P `(void)` ¶

  Return true if asan should use dynamic shadow offset.

Target Hook: `unsigned HOST_WIDE_INT` TARGET_MEMMODEL_CHECK `(unsigned HOST_WIDE_INT val)` ¶

  Validate target specific memory model mask bits. When NULL no target specific memory model bits are allowed.

Target Hook: `unsigned char` TARGET_ATOMIC_TEST_AND_SET_TRUEVAL ¶

  This value should be set if the result written by `atomic_test_and_set` is not exactly 1, i.e. the `bool` `true`.

Target Hook: `bool` TARGET_HAS_IFUNC_P `(void)` ¶

  It returns true if the target supports GNU indirect functions. The support includes the assembler, linker and dynamic linker. The default value of this hook is based on target’s libc.

Target Hook: `bool` TARGET_IFUNC_REF_LOCAL_OK `(void)` ¶

  Return true if it is OK to reference indirect function resolvers locally. The default is to return false.

Target Hook: `unsigned int` TARGET_ATOMIC_ALIGN_FOR_MODE `(machine_mode mode)` ¶

  If defined, this function returns an appropriate alignment in bits for an atomic object of machine_mode mode. If 0 is returned then the default alignment for the specified mode is used.

Target Hook: `void` TARGET_ATOMIC_ASSIGN_EXPAND_FENV `(tree *hold, tree *clear, tree *update)` ¶

  ISO C11 requires atomic compound assignments that may raise floating-point exceptions to raise exceptions corresponding to the arithmetic operation whose result was successfully stored in a compare-and-exchange sequence. This requires code equivalent to calls to `feholdexcept`, `feclearexcept` and `feupdateenv` to be generated at appropriate points in the compare-and-exchange sequence. This hook should set `*hold` to an expression equivalent to the call to `feholdexcept`, `*clear` to an expression equivalent to the call to `feclearexcept` and `*update` to an expression equivalent to the call to `feupdateenv`. The three expressions are `NULL_TREE` on entry to the hook and may be left as `NULL_TREE` if no code is required in a particular place. The default implementation leaves all three expressions as `NULL_TREE`. The `__atomic_feraiseexcept` function from `libatomic` may be of use as part of the code generated in `*update`.

Target Hook: `void` TARGET_RECORD_OFFLOAD_SYMBOL `(tree)` ¶

  Used when offloaded functions are seen in the compilation unit and no named sections are available. It is called once for each symbol that must be recorded in the offload function and variable table.

Target Hook: `char *` TARGET_OFFLOAD_OPTIONS `(void)` ¶

  Used when writing out the list of options into an LTO file. It should translate any relevant target-specific options (such as the ABI in use) into one of the `-foffload` options that exist as a common interface to express such options. It should return a string containing these options, separated by spaces, which the caller will free.

Macro: TARGET_SUPPORTS_WIDE_INT ¶

  On older ports, large integers are stored in `CONST_DOUBLE` rtl objects. Newer ports define `TARGET_SUPPORTS_WIDE_INT` to be nonzero to indicate that large integers are stored in `CONST_WIDE_INT` rtl objects. The `CONST_WIDE_INT` allows very large integer constants to be represented. `CONST_DOUBLE` is limited to twice the size of the host’s `HOST_WIDE_INT` representation.

  Converting a port mostly requires looking for the places where `CONST_DOUBLE`s are used with `VOIDmode` and replacing that code with code that accesses `CONST_WIDE_INT`s. ‘`"grep -i const_double"`’ at the port level gets you to 95% of the changes that need to be made. There are a few places that require a deeper look.

  - There is no equivalent to `hval` and `lval` for `CONST_WIDE_INT`s. This would be difficult to express in the md language since there are a variable number of elements.

    Most ports only check that `hval` is either 0 or -1 to see if the value is small. As mentioned above, this will no longer be necessary since small constants are always `CONST_INT`. Of course there are still a few exceptions, the alpha’s constraint used by the zap instruction certainly requires careful examination by C code. However, all the current code does is pass the hval and lval to C code, so evolving the c code to look at the `CONST_WIDE_INT` is not really a large change.

  - Because there is no standard template that ports use to materialize constants, there is likely to be some futzing that is unique to each port in this code.
  - The rtx costs may have to be adjusted to properly account for larger constants that are represented as `CONST_WIDE_INT`.

  All and all it does not take long to convert ports that the maintainer is familiar with.

Target Hook: `bool` TARGET_HAVE_SPECULATION_SAFE_VALUE `(bool active)` ¶

  This hook is used to determine the level of target support for `__builtin_speculation_safe_value`. If called with an argument of false, it returns true if the target has been modified to support this builtin. If called with an argument of true, it returns true if the target requires active mitigation execution might be speculative.

  The default implementation returns false if the target does not define a pattern named `speculation_barrier`. Else it returns true for the first case and whether the pattern is enabled for the current compilation for the second case.

  For targets that have no processors that can execute instructions speculatively an alternative implementation of this hook is available: simply redefine this hook to `speculation_safe_value_not_needed` along with your other target hooks.

Target Hook: `rtx` TARGET_SPECULATION_SAFE_VALUE `(machine_mode mode, rtx result, rtx val, rtx failval)` ¶

  This target hook can be used to generate a target-specific code sequence that implements the `__builtin_speculation_safe_value` built-in function. The function must always return val in result in mode mode when the cpu is not executing speculatively, but must never return that when speculating until it is known that the speculation will not be unwound. The hook supports two primary mechanisms for implementing the requirements. The first is to emit a speculation barrier which forces the processor to wait until all prior speculative operations have been resolved; the second is to use a target-specific mechanism that can track the speculation state and to return failval if it can determine that speculation must be unwound at a later time.

  The default implementation simply copies val to result and emits a `speculation_barrier` instruction if that is defined.

Target Hook: `void` TARGET_RUN_TARGET_SELFTESTS `(void)` ¶

  If selftests are enabled, run any selftests for this target.

Target Hook: `bool` TARGET_MEMTAG_CAN_TAG_ADDRESSES `()` ¶

  True if the backend architecture naturally supports ignoring some region of pointers. This feature means that `-fsanitize=hwaddress` can work.

  At preset, this feature does not support address spaces. It also requires `Pmode` to be the same as `ptr_mode`.

Target Hook: `uint8_t` TARGET_MEMTAG_TAG_BITSIZE `()` ¶

  Return the size of a tag (in bits) for this platform.

  The default returns 8.

Target Hook: `uint8_t` TARGET_MEMTAG_GRANULE_SIZE `()` ¶

  Return the size in real memory that each byte in shadow memory refers to. I.e. if a variable is X bytes long in memory, then this hook should return the value Y such that the tag in shadow memory spans X/Y bytes.

  Most variables will need to be aligned to this amount since two variables that are neighbors in memory and share a tag granule would need to share the same tag.

  The default returns 16.

Target Hook: `rtx` TARGET_MEMTAG_INSERT_RANDOM_TAG `(rtx untagged, rtx target)` ¶

  Return an RTX representing the value of untagged but with a (possibly) random tag in it. Put that value into target if it is convenient to do so. This function is used to generate a tagged base for the current stack frame. It is also used by memtag-stack sanitizer to emit specific memory tagging instructions.

Target Hook: `rtx` TARGET_MEMTAG_ADD_TAG `(rtx base, poly_int64 addr_offset, uint8_t tag_offset)` ¶

  Return an RTX that represents the result of adding addr_offset to the address in pointer base and tag_offset to the tag in pointer base. The resulting RTX must either be a valid memory address or be able to get put into an operand with `force_operand`.

  Unlike other memtag hooks, this must return an expression and not emit any RTL. In the case of memtag-stack sanitizer, this constraint is not enforced.

Target Hook: `rtx` TARGET_MEMTAG_SET_TAG `(rtx untagged_base, rtx tag, rtx target)` ¶

  Return an RTX representing untagged_base but with the tag tag. Try and store this in target if convenient. untagged_base is required to have a zero tag when this hook is called. The default of this hook is to set the top byte of untagged_base to tag.

Target Hook: `rtx` TARGET_MEMTAG_EXTRACT_TAG `(rtx tagged_pointer, rtx target)` ¶

  Return an RTX representing the tag stored in tagged_pointer. Store the result in target if it is convenient. The default represents the top byte of the original pointer. In the case of memtag-stack sanitizer for targets that can process tagged pointers (i.e. AArch64), this hook can return a tagged pointer.

Target Hook: `rtx` TARGET_MEMTAG_UNTAGGED_POINTER `(rtx tagged_pointer, rtx target)` ¶

  Return an RTX representing tagged_pointer with its tag set to zero. Store the result in target if convenient. The default clears the top byte of the original pointer.

Target Hook: `bool` TARGET_HAVE_SHADOW_CALL_STACK ¶

  This value is true if the target platform supports `-fsanitize=shadow-call-stack`. The default value is false.

Target Hook: `bool` TARGET_HAVE_LIBATOMIC ¶

  This value is true if the target platform supports libatomic. The default value is false.

Target Hook: `const char *` TARGET_DOCUMENTATION_NAME ¶

  If non-NULL, this value is a string used for locating target-specific documentation for this target. The default value is NULL.