AArch64 Attributes (Using the GNU Compiler Collection (GCC))

#### 6.4.2.1 AArch64 Attributes ¶

The following target-specific function attributes are available for the AArch64 target.

`target (options)` ¶

  This attribute applies to functions.

  As discussed in Common Attributes, the `target` function attribute allows you to specify target-specific compilation options on a per-function basis. For the most part, these options mirror the behavior of similar command-line options (see AArch64 Options).

  The target attributes can be specified as follows:

      __attribute__((target("attr-string")))
      int
      f (int a)
      {
        return a + 5;
      }

  where `attr-string` is one of the option name strings specified below.

  Additionally, the architectural extension string may be specified on its own. This can be used to turn on and off particular architectural extensions without having to specify a particular architecture version or core. Example:

      __attribute__((target("+crc+nocrypto")))
      int
      foo (int a)
      {
        return a + 5;
      }

  In this example `target("+crc+nocrypto")` enables the `crc` extension and disables the `crypto` extension for the function `foo` without modifying an existing `-march=` or `-mcpu` option.

  Multiple options can be specified in the same attribute by separating them with a comma. For example:

      __attribute__((target("arch=armv8-a+crc+crypto,tune=cortex-a53")))
      int
      foo (int a)
      {
        return a + 5;
      }

  is valid; this compiles function `foo` for ARMv8-A with `crc` and `crypto` extensions, and tunes it for `cortex-a53`.

  These are the permitted options:

  ‘`general-regs-only`’ ¶

    Indicates that no floating-point or Advanced SIMD registers should be used when generating code for this function. If the function explicitly uses floating-point code, then the compiler gives an error. This is the same behavior as that of the command-line option `-mgeneral-regs-only`.

  ‘`fix-cortex-a53-835769`’ ¶

    Indicates that the workaround for the Cortex-A53 erratum 835769 should be applied to this function. To explicitly disable the workaround for this function specify the negated form: `no-fix-cortex-a53-835769`. This corresponds to the behavior of the command-line options `-mfix-cortex-a53-835769` and `-mno-fix-cortex-a53-835769`.

  ‘`cmodel=`’ ¶

    Indicates that code should be generated for a particular code model for this function. The behavior and permissible arguments are the same as for the command-line option `-mcmodel=`.

  ‘`strict-align`’ ¶
  ‘`no-strict-align`’

    `strict-align` indicates that the compiler should not assume that unaligned memory references are handled by the system. To allow the compiler to assume that aligned memory references are handled by the system, the inverse attribute `no-strict-align` can be specified. The behavior is same as for the command-line option `-mstrict-align` and `-mno-strict-align`.

  ‘`omit-leaf-frame-pointer`’ ¶

    Indicates that the frame pointer should be omitted for a leaf function call. To keep the frame pointer, the inverse attribute `no-omit-leaf-frame-pointer` can be specified. These attributes have the same behavior as the command-line options `-momit-leaf-frame-pointer` and `-mno-omit-leaf-frame-pointer`.

  ‘`tls-dialect=`’ ¶

    Specifies the TLS dialect to use for this function. The behavior and permissible arguments are the same as for the command-line option `-mtls-dialect=`.

  ‘`arch=`’ ¶

    Specifies the architecture version and architectural extensions to use for this function. The behavior and permissible arguments are the same as for the `-march=` command-line option.

  ‘`tune=`’ ¶

    Specifies the core for which to tune the performance of this function. The behavior and permissible arguments are the same as for the `-mtune=` command-line option.

  ‘`cpu=`’ ¶

    Specifies the core for which to tune the performance of this function and also whose architectural features to use. The behavior and valid arguments are the same as for the `-mcpu=` command-line option.

  ‘`sign-return-address`’ ¶

    Select the function scope on which return address signing will be applied. The behavior and permissible arguments are the same as for the command-line option `-msign-return-address=`. The default value is `none`. This attribute is deprecated. The `branch-protection` attribute should be used instead.

  ‘`branch-protection`’ ¶

    Select the function scope on which branch protection will be applied. The behavior and permissible arguments are the same as for the command-line option `-mbranch-protection=`. The default value is `none`.

  ‘`outline-atomics`’ ¶
  ‘`no-outline-atomics`’

    Enable or disable calls to out-of-line helpers to implement atomic operations. This corresponds to the behavior of the command-line options `-moutline-atomics` and `-mno-outline-atomics`.

  ‘`max-vectorization`’ ¶
  ‘`no-max-vectorization`’

    `max-vectorization` tells GCC’s vectorizer to treat all vector loops as being more profitable than the original scalar loops when optimizing the current function. `no-max-vectorization` disables this behavior. This corresponds to the behavior of the command-line options `-mmax-vectorization` and `-mno-max-vectorization`.

  ‘`indirect_return`’ ¶

    The `indirect_return` attribute can be applied to a function type to indicate that the function may return via an indirect branch instead of via a normal return instruction. For example, this can be true of functions that implement manual context switching between user space threads, such as the POSIX `swapcontext` function. This attribute adds a `BTI J` instruction when BTI is enabled e.g. via `-mbranch-protection`.

  ‘`preserve_none`’ ¶

    Use this attribute to change the procedure call standard of the specified function to the preserve-none variant.

    The preserve-none ABI variant modifies the AAPCS such that it has no callee-saved registers (including SIMD and floating-point registers). That is, with the exception of the stack register, link register (r30), and frame pointer (r29), all registers are changed to caller saved, and can be used as scratch registers by the callee.

    Additionally, registers r20–r28, r0–r7, r10–r14, r9 and r15 are used for argument passing, in that order. For Microsoft Windows targets r15 is not used for argument passing.

    The return value registers remain r0 and r1 in both cases.

    All other details are the same as for the AAPCS ABI.

    This ABI has not been stabilized, and may be subject to change in future versions.

  Specifying `target` attributes on individual functions or performing link-time optimization across translation units compiled with different target options can affect function inlining rules.

  In particular, a caller function can inline a callee function only if the architectural features available to the callee are a subset of the features available to the caller. For example: A function `foo` compiled with `-march=armv8-a+crc`, or tagged with the equivalent `arch=armv8-a+crc` attribute, can inline a function `bar` compiled with `-march=armv8-a+nocrc` because the all the architectural features that function `bar` requires are available to function `foo`. Conversely, function `bar` cannot inline function `foo`.

  Additionally inlining a function compiled with `-mstrict-align` into a function compiled without `-mstrict-align` is not allowed. However, inlining a function compiled without `-mstrict-align` into a function compiled with `-mstrict-align` is allowed.

  Note that CPU tuning options and attributes such as the `-mcpu=`, `-mtune=` do not inhibit inlining unless the CPU specified by the `-mcpu=` option or the `cpu=` attribute conflicts with the architectural feature rules specified above.