gccint: Insns
1
1 14.19 Insns
1 ===========
1
1 The RTL representation of the code for a function is a doubly-linked
1 chain of objects called "insns". Insns are expressions with special
1 codes that are used for no other purpose. Some insns are actual
1 instructions; others represent dispatch tables for 'switch' statements;
1 others represent labels to jump to or various sorts of declarative
1 information.
1
1 In addition to its own specific data, each insn must have a unique
1 id-number that distinguishes it from all other insns in the current
1 function (after delayed branch scheduling, copies of an insn with the
1 same id-number may be present in multiple places in a function, but
1 these copies will always be identical and will only appear inside a
1 'sequence'), and chain pointers to the preceding and following insns.
1 These three fields occupy the same position in every insn, independent
1 of the expression code of the insn. They could be accessed with 'XEXP'
1 and 'XINT', but instead three special macros are always used:
1
1 'INSN_UID (I)'
1 Accesses the unique id of insn I.
1
1 'PREV_INSN (I)'
1 Accesses the chain pointer to the insn preceding I. If I is the
1 first insn, this is a null pointer.
1
1 'NEXT_INSN (I)'
1 Accesses the chain pointer to the insn following I. If I is the
1 last insn, this is a null pointer.
1
1 The first insn in the chain is obtained by calling 'get_insns'; the
1 last insn is the result of calling 'get_last_insn'. Within the chain
1 delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must
1 always correspond: if INSN is not the first insn,
1
1 NEXT_INSN (PREV_INSN (INSN)) == INSN
1
1 is always true and if INSN is not the last insn,
1
1 PREV_INSN (NEXT_INSN (INSN)) == INSN
1
1 is always true.
1
1 After delay slot scheduling, some of the insns in the chain might be
1 'sequence' expressions, which contain a vector of insns. The value of
1 'NEXT_INSN' in all but the last of these insns is the next insn in the
1 vector; the value of 'NEXT_INSN' of the last insn in the vector is the
1 same as the value of 'NEXT_INSN' for the 'sequence' in which it is
1 contained. Similar rules apply for 'PREV_INSN'.
1
1 This means that the above invariants are not necessarily true for insns
1 inside 'sequence' expressions. Specifically, if INSN is the first insn
1 in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing
1 the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN
1 (INSN))' if INSN is the last insn in the 'sequence' expression. You can
1 use these expressions to find the containing 'sequence' expression.
1
1 Every insn has one of the following expression codes:
1
1 'insn'
1 The expression code 'insn' is used for instructions that do not
1 jump and do not do function calls. 'sequence' expressions are
1 always contained in insns with code 'insn' even if one of those
1 insns should jump or do function calls.
1
1 Insns with code 'insn' have four additional fields beyond the three
1 mandatory ones listed above. These four are described in a table
1 below.
1
1 'jump_insn'
1 The expression code 'jump_insn' is used for instructions that may
1 jump (or, more generally, may contain 'label_ref' expressions to
1 which 'pc' can be set in that instruction). If there is an
1 instruction to return from the current function, it is recorded as
1 a 'jump_insn'.
1
1 'jump_insn' insns have the same extra fields as 'insn' insns,
1 accessed in the same way and in addition contain a field
1 'JUMP_LABEL' which is defined once jump optimization has completed.
1
1 For simple conditional and unconditional jumps, this field contains
1 the 'code_label' to which this insn will (possibly conditionally)
1 branch. In a more complex jump, 'JUMP_LABEL' records one of the
1 labels that the insn refers to; other jump target labels are
1 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec'
1 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only
1 way to find the labels is to scan the entire body of the insn.
1
1 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or
1 'SIMPLE_RETURN'.
1
1 'call_insn'
1 The expression code 'call_insn' is used for instructions that may
1 do function calls. It is important to distinguish these
1 instructions because they imply that certain registers and memory
1 locations may be altered unpredictably.
1
1 'call_insn' insns have the same extra fields as 'insn' insns,
1 accessed in the same way and in addition contain a field
1 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
1 'expr_list' expressions) containing 'use', 'clobber' and sometimes
1 'set' expressions that denote hard registers and 'mem's used or
1 clobbered by the called function.
1
1 A 'mem' generally points to a stack slot in which arguments passed
11 to the libcall by reference (⇒TARGET_PASS_BY_REFERENCE
Register Arguments.) are stored. If the argument is caller-copied
1 (⇒TARGET_CALLEE_COPIES Register Arguments.), the stack slot
1 will be mentioned in 'clobber' and 'use' entries; if it's
1 callee-copied, only a 'use' will appear, and the 'mem' may point to
1 addresses that are not stack slots.
1
1 Registers occurring inside a 'clobber' in this list augment
11 registers specified in 'CALL_USED_REGISTERS' (⇒Register
Basics).
1
1 If the list contains a 'set' involving two registers, it indicates
1 that the function returns one of its arguments. Such a 'set' may
1 look like a no-op if the same register holds the argument and the
1 return value.
1
1 'code_label'
1 A 'code_label' insn represents a label that a jump insn can jump
1 to. It contains two special fields of data in addition to the
1 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the
1 "label number", a number that identifies this label uniquely among
1 all the labels in the compilation (not just in the current
1 function). Ultimately, the label is represented in the assembler
1 output as an assembler label, usually of the form 'LN' where N is
1 the label number.
1
1 When a 'code_label' appears in an RTL expression, it normally
1 appears within a 'label_ref' which represents the address of the
1 label, as a number.
1
1 Besides as a 'code_label', a label can also be represented as a
1 'note' of type 'NOTE_INSN_DELETED_LABEL'.
1
1 The field 'LABEL_NUSES' is only defined once the jump optimization
1 phase is completed. It contains the number of times this label is
1 referenced in the current function.
1
1 The field 'LABEL_KIND' differentiates four different types of
1 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY',
1 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type
1 'LABEL_NORMAL' are "alternate entry points" to the current
1 function. These may be static (visible only in the containing
1 translation unit), global (exposed to all translation units), or
1 weak (global, but can be overridden by another symbol with the same
1 name).
1
1 Much of the compiler treats all four kinds of label identically.
1 Some of it needs to know whether or not a label is an alternate
1 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is
1 provided. It is equivalent to testing whether 'LABEL_KIND (label)
1 == LABEL_NORMAL'. The only place that cares about the distinction
1 between static, global, and weak alternate entry points, besides
1 the front-end code that creates them, is the function
1 'output_alternate_entry_point', in 'final.c'.
1
1 To set the kind of a label, use the 'SET_LABEL_KIND' macro.
1
1 'jump_table_data'
1 A 'jump_table_data' insn is a placeholder for the jump-table data
1 of a 'casesi' or 'tablejump' insn. They are placed after a
1 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic
1 blockm but it is associated with the basic block that ends with the
1 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always
1 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data'
1 insn is always preceded by a 'code_label'. The 'tablejump_p' insn
1 refers to that 'code_label' via its 'JUMP_LABEL'.
1
1 'barrier'
1 Barriers are placed in the instruction stream when control cannot
1 flow past them. They are placed after unconditional jump
1 instructions to indicate that the jumps are unconditional and after
1 calls to 'volatile' functions, which do not return (e.g., 'exit').
1 They contain no information beyond the three standard fields.
1
1 'note'
1 'note' insns are used to represent additional debugging and
1 declarative information. They contain two nonstandard fields, an
1 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a
1 string accessed with 'NOTE_SOURCE_FILE'.
1
1 If 'NOTE_LINE_NUMBER' is positive, the note represents the position
1 of a source line and 'NOTE_SOURCE_FILE' is the source file name
1 that the line came from. These notes control generation of line
1 number data in the assembler output.
1
1 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a
1 code with one of the following values (and 'NOTE_SOURCE_FILE' must
1 contain a null pointer):
1
1 'NOTE_INSN_DELETED'
1 Such a note is completely ignorable. Some passes of the
1 compiler delete insns by altering them into notes of this
1 kind.
1
1 'NOTE_INSN_DELETED_LABEL'
1 This marks what used to be a 'code_label', but was not used
1 for other purposes than taking its address and was transformed
1 to mark that no code jumps to it.
1
1 'NOTE_INSN_BLOCK_BEG'
1 'NOTE_INSN_BLOCK_END'
1 These types of notes indicate the position of the beginning
1 and end of a level of scoping of variable names. They control
1 the output of debugging information.
1
1 'NOTE_INSN_EH_REGION_BEG'
1 'NOTE_INSN_EH_REGION_END'
1 These types of notes indicate the position of the beginning
1 and end of a level of scoping for exception handling.
1 'NOTE_EH_HANDLER' identifies which region is associated with
1 these notes.
1
1 'NOTE_INSN_FUNCTION_BEG'
1 Appears at the start of the function body, after the function
1 prologue.
1
1 'NOTE_INSN_VAR_LOCATION'
1 This note is used to generate variable location debugging
1 information. It indicates that the user variable in its
1 'VAR_LOCATION' operand is at the location given in the RTL
1 expression, or holds a value that can be computed by
1 evaluating the RTL expression from that static point in the
1 program up to the next such note for the same user variable.
1
1 'NOTE_INSN_BEGIN_STMT'
1 This note is used to generate 'is_stmt' markers in line number
1 debuggign information. It indicates the beginning of a user
1 statement.
1
1 'NOTE_INSN_INLINE_ENTRY'
1 This note is used to generate 'entry_pc' for inlined
1 subroutines in debugging information. It indicates an
1 inspection point at which all arguments for the inlined
1 function have been bound, and before its first statement.
1
1 These codes are printed symbolically when they appear in debugging
1 dumps.
1
1 'debug_insn'
1 The expression code 'debug_insn' is used for pseudo-instructions
1 that hold debugging information for variable tracking at
1 assignments (see '-fvar-tracking-assignments' option). They are
11 the RTL representation of 'GIMPLE_DEBUG' statements (⇒
GIMPLE_DEBUG), with a 'VAR_LOCATION' operand that binds a user
1 variable tree to an RTL representation of the 'value' in the
1 corresponding statement. A 'DEBUG_EXPR' in it stands for the value
1 bound to the corresponding 'DEBUG_EXPR_DECL'.
1
1 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are
1 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN';
1 the difference is the RTL mode: the former's 'DEBUG_MARKER' is
1 'VOIDmode', whereas the latter is 'BLKmode'; information about the
1 inlined function can be taken from the lexical block encoded in the
1 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry
1 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected
1 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be
1 recognized as 'DEBUG_BIND_INSN_P'.
1
1 Throughout optimization passes, 'DEBUG_INSN's are not reordered
1 with respect to each other, particularly during scheduling.
1 Binding information is kept in pseudo-instruction form, so that,
1 unlike notes, it gets the same treatment and adjustments that
1 regular instructions would. It is the variable tracking pass that
1 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION',
1 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes,
1 analyzing control flow, value equivalences and changes to registers
1 and memory referenced in value expressions, propagating the values
1 of debug temporaries and determining expressions that can be used
1 to compute the value of each user variable at as many points
1 (ranges, actually) in the program as possible.
1
1 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an
1 'INSN_VAR_LOCATION' denotes a value at that specific point in the
1 program, rather than an expression that can be evaluated at any
1 later point before an overriding 'VAR_LOCATION' is encountered.
1 E.g., if a user variable is bound to a 'REG' and then a subsequent
1 insn modifies the 'REG', the note location would keep mapping the
1 user variable to the register across the insn, whereas the insn
1 location would keep the variable bound to the value, so that the
1 variable tracking pass would emit another location note for the
1 variable at the point in which the register is modified.
1
1 The machine mode of an insn is normally 'VOIDmode', but some phases use
1 the mode for various purposes.
1
1 The common subexpression elimination pass sets the mode of an insn to
1 'QImode' when it is the first insn in a block that has already been
1 processed.
1
1 The second Haifa scheduling pass, for targets that can multiple issue,
1 sets the mode of an insn to 'TImode' when it is believed that the
1 instruction begins an issue group. That is, when the instruction cannot
1 issue simultaneously with the previous. This may be relied on by later
1 passes, in particular machine-dependent reorg.
1
1 Here is a table of the extra fields of 'insn', 'jump_insn' and
1 'call_insn' insns:
1
1 'PATTERN (I)'
1 An expression for the side effect performed by this insn. This
1 must be one of the following codes: 'set', 'call', 'use',
1 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output',
1 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec',
1 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it
1 is a 'parallel', each element of the 'parallel' must be one these
1 codes, except that 'parallel' expressions cannot be nested and
1 'addr_vec' and 'addr_diff_vec' are not permitted inside a
1 'parallel' expression.
1
1 'INSN_CODE (I)'
1 An integer that says which pattern in the machine description
1 matches this insn, or -1 if the matching has not yet been
1 attempted.
1
1 Such matching is never attempted and this field remains -1 on an
1 insn whose pattern consists of a single 'use', 'clobber',
1 'asm_input', 'addr_vec' or 'addr_diff_vec' expression.
1
1 Matching is also never attempted on insns that result from an 'asm'
1 statement. These contain at least one 'asm_operands' expression.
1 The function 'asm_noperands' returns a non-negative value for such
1 insns.
1
1 In the debugging output, this field is printed as a number followed
1 by a symbolic representation that locates the pattern in the 'md'
1 file as some small positive or negative offset from a named
1 pattern.
1
1 'LOG_LINKS (I)'
1 A list (chain of 'insn_list' expressions) giving information about
1 dependencies between instructions within a basic block. Neither a
1 jump nor a label may come between the related insns. These are
1 only used by the schedulers and by combine. This is a deprecated
1 data structure. Def-use and use-def chains are now preferred.
1
1 'REG_NOTES (I)'
1 A list (chain of 'expr_list', 'insn_list' and 'int_list'
1 expressions) giving miscellaneous information about the insn. It
1 is often information pertaining to the registers used in this insn.
1
1 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions.
1 Each of these has two operands: the first is an insn, and the second is
1 another 'insn_list' expression (the next one in the chain). The last
1 'insn_list' in the chain has a null pointer as second operand. The
1 significant thing about the chain is which insns appear in it (as first
1 operands of 'insn_list' expressions). Their order is not significant.
1
1 This list is originally set up by the flow analysis pass; it is a null
1 pointer until then. Flow only adds links for those data dependencies
1 which can be used for instruction combination. For each insn, the flow
1 analysis pass adds a link to insns which store into registers values
1 that are used for the first time in this insn.
1
1 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS'
1 field but it includes 'expr_list' and 'int_list' expressions in addition
1 to 'insn_list' expressions. There are several kinds of register notes,
1 which are distinguished by the machine mode, which in a register note is
1 really understood as being an 'enum reg_note'. The first operand OP of
1 the note is data whose meaning depends on the kind of note.
1
1 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its
1 counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
1 register note type of X to be NEWKIND.
1
1 Register notes are of three classes: They may say something about an
1 input to an insn, they may say something about an output of an insn, or
1 they may create a linkage between two insns. There are also a set of
1 values that are only used in 'LOG_LINKS'.
1
1 These register notes annotate inputs to an insn:
1
1 'REG_DEAD'
1 The value in OP dies in this insn; that is to say, altering the
1 value immediately after this insn would not affect the future
1 behavior of the program.
1
1 It does not follow that the register OP has no useful value after
1 this insn since OP is not necessarily modified by this insn.
1 Rather, no subsequent instruction uses the contents of OP.
1
1 'REG_UNUSED'
1 The register OP being set by this insn will not be used in a
1 subsequent insn. This differs from a 'REG_DEAD' note, which
1 indicates that the value in an input will not be used subsequently.
1 These two notes are independent; both may be present for the same
1 register.
1
1 'REG_INC'
1 The register OP is incremented (or decremented; at this level there
1 is no distinction) by an embedded side effect inside this insn.
1 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or
1 'pre_dec' expression.
1
1 'REG_NONNEG'
1 The register OP is known to have a nonnegative value when this insn
1 is reached. This is used so that decrement and branch until zero
1 instructions, such as the m68k dbra, can be matched.
1
1 The 'REG_NONNEG' note is added to insns only if the machine
1 description has a 'decrement_and_branch_until_zero' pattern.
1
1 'REG_LABEL_OPERAND'
1 This insn uses OP, a 'code_label' or a 'note' of type
1 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a
1 'jump_insn' that refers to the operand as an ordinary operand. The
1 label may still eventually be a jump target, but if so in an
1 indirect jump in a subsequent insn. The presence of this note
1 allows jump optimization to be aware that OP is, in fact, being
1 used, and flow optimization to build an accurate flow graph.
1
1 'REG_LABEL_TARGET'
1 This insn is a 'jump_insn' but not an 'addr_vec' or
1 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or
1 indirect jump target. Its purpose is similar to that of
1 'REG_LABEL_OPERAND'. This note is only present if the insn has
1 multiple targets; the last label in the insn (in the highest
1 numbered insn-field) goes into the 'JUMP_LABEL' field and does not
1 have a 'REG_LABEL_TARGET' note. ⇒JUMP_LABEL Insns.
1
1 'REG_SETJMP'
1 Appears attached to each 'CALL_INSN' to 'setjmp' or a related
1 function.
1
1 The following notes describe attributes of outputs of an insn:
1
1 'REG_EQUIV'
1 'REG_EQUAL'
1 This note is only valid on an insn that sets only one register and
1 indicates that that register will be equal to OP at run time; the
1 scope of this equivalence differs between the two types of notes.
1 The value which the insn explicitly copies into the register may
1 look different from OP, but they will be equal at run time. If the
1 output of the single 'set' is a 'strict_low_part' or 'zero_extract'
1 expression, the note refers to the register that is contained in
1 its first operand.
1
1 For 'REG_EQUIV', the register is equivalent to OP throughout the
1 entire function, and could validly be replaced in all its
1 occurrences by OP. ("Validly" here refers to the data flow of the
1 program; simple replacement may make some insns invalid.) For
1 example, when a constant is loaded into a register that is never
1 assigned any other value, this kind of note is used.
1
1 When a parameter is copied into a pseudo-register at entry to a
1 function, a note of this kind records that the register is
1 equivalent to the stack slot where the parameter was passed.
1 Although in this case the register may be set by other insns, it is
1 still valid to replace the register by the stack slot throughout
1 the function.
1
1 A 'REG_EQUIV' note is also used on an instruction which copies a
1 register parameter into a pseudo-register at entry to a function,
1 if there is a stack slot where that parameter could be stored.
1 Although other insns may set the pseudo-register, it is valid for
1 the compiler to replace the pseudo-register by stack slot
1 throughout the function, provided the compiler ensures that the
1 stack slot is properly initialized by making the replacement in the
1 initial copy instruction as well. This is used on machines for
1 which the calling convention allocates stack space for register
1 parameters. See 'REG_PARM_STACK_SPACE' in ⇒Stack Arguments.
1
1 In the case of 'REG_EQUAL', the register that is set by this insn
1 will be equal to OP at run time at the end of this insn but not
1 necessarily elsewhere in the function. In this case, OP is
1 typically an arithmetic expression. For example, when a sequence
1 of insns such as a library call is used to perform an arithmetic
1 operation, this kind of note is attached to the insn that produces
1 or copies the final value.
1
1 These two notes are used in different ways by the compiler passes.
1 'REG_EQUAL' is used by passes prior to register allocation (such as
1 common subexpression elimination and loop optimization) to tell
1 them how to think of that value. 'REG_EQUIV' notes are used by
1 register allocation to indicate that there is an available
1 substitute expression (either a constant or a 'mem' expression for
1 the location of a parameter on the stack) that may be used in place
1 of a register if insufficient registers are available.
1
1 Except for stack homes for parameters, which are indicated by a
1 'REG_EQUIV' note and are not useful to the early optimization
1 passes and pseudo registers that are equivalent to a memory
1 location throughout their entire life, which is not detected until
1 later in the compilation, all equivalences are initially indicated
1 by an attached 'REG_EQUAL' note. In the early stages of register
1 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note
1 if OP is a constant and the insn represents the only set of its
1 destination register.
1
1 Thus, compiler passes prior to register allocation need only check
1 for 'REG_EQUAL' notes and passes subsequent to register allocation
1 need only check for 'REG_EQUIV' notes.
1
1 These notes describe linkages between insns. They occur in pairs: one
1 insn has one of a pair of notes that points to a second insn, which has
1 the inverse note pointing back to the first insn.
1
1 'REG_CC_SETTER'
1 'REG_CC_USER'
1 On machines that use 'cc0', the insns which set and use 'cc0' set
1 and use 'cc0' are adjacent. However, when branch delay slot
1 filling is done, this may no longer be true. In this case a
1 'REG_CC_USER' note will be placed on the insn setting 'cc0' to
1 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be
1 placed on the insn using 'cc0' to point to the insn setting 'cc0'.
1
1 These values are only used in the 'LOG_LINKS' field, and indicate the
1 type of dependency that each link represents. Links which indicate a
1 data dependence (a read after write dependence) do not use any code,
1 they simply have mode 'VOIDmode', and are printed without any
1 descriptive text.
1
1 'REG_DEP_TRUE'
1 This indicates a true dependence (a read after write dependence).
1
1 'REG_DEP_OUTPUT'
1 This indicates an output dependence (a write after write
1 dependence).
1
1 'REG_DEP_ANTI'
1 This indicates an anti dependence (a write after read dependence).
1
1 These notes describe information gathered from gcov profile data. They
1 are stored in the 'REG_NOTES' field of an insn.
1
1 'REG_BR_PROB'
1 This is used to specify the ratio of branches to non-branches of a
1 branch insn according to the profile data. The note is represented
1 as an 'int_list' expression whose integer value is an encoding of
1 'profile_probability' type. 'profile_probability' provide member
1 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to
1 extract and store the probability into the RTL encoding.
1
1 'REG_BR_PRED'
1 These notes are found in JUMP insns after delayed branch scheduling
1 has taken place. They indicate both the direction and the
1 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_*
1 values.
1
1 'REG_FRAME_RELATED_EXPR'
1 This is used on an RTX_FRAME_RELATED_P insn wherein the attached
1 expression is used in place of the actual insn pattern. This is
1 done in cases where the pattern is either complex or misleading.
1
1 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the
1 '-fcf-protection=branch' option. The note is set if a 'nocf_check'
1 attribute is specified for a function type or a pointer to function
1 type. The note is stored in the 'REG_NOTES' field of an insn.
1
1 'REG_CALL_NOCF_CHECK'
1 Users have control through the 'nocf_check' attribute to identify
1 which calls to a function should be skipped from control-flow
1 instrumentation when the option '-fcf-protection=branch' is
1 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each
1 'CALL_INSN' instruction that has a function type marked with a
1 'nocf_check' attribute.
1
1 For convenience, the machine mode in an 'insn_list' or 'expr_list' is
1 printed using these symbolic codes in debugging dumps.
1
1 The only difference between the expression codes 'insn_list' and
1 'expr_list' is that the first operand of an 'insn_list' is assumed to be
1 an insn and is printed in debugging dumps as the insn's unique id; the
1 first operand of an 'expr_list' is printed in the ordinary way as an
1 expression.
1