<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/132570>132570</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [AArch64] Assembly syntax for relocation specifier in data directives
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            backend:AArch64,
            mc
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          MaskRay
      </td>
    </tr>
</table>

<pre>
    https://reviews.llvm.org/D81446 and https://github.com/llvm/llvm-project/pull/72584 , introduced the assembly syntax `.word sym@plt-.` and `.word sym@gotpcrel` for R_AARCH64_PLT32 and R_AARCH64_GOTPCREL32 relocations.
This syntax was chosen due to an existing quirk in LLVM's AsmParser, where `@plt` was universally accepted until my recent update (commit a067175) made it an opt-in parsing feature.

( https://reviews.llvm.org/D156505 introduced `@AUTH(ib, 1234, addr)`

The use of `@plt` as a specifier applied to every subexpression is considered awkward.
The reliance on `MCSymbolRefExpr::VariantKind for representing these relocations introduces complexity and inconsistencies within LLVM's internal representation.
As detailed in https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers#relocation-specifier-flavors , this approach highlights inelegance in how LLVM handles relocation specifiers.

As a more concrete example, https://reviews.llvm.org/D156505 , which introduced `@AUTH(ib, 1234, addr)`, had to reject all kinds of invalid syntax
**after** parsing time (e.g. `.quad _g9@AUTH(ia,42) - _g8@AUTH(ia,42)`), which is not ideal.

A more standard syntax like `.word :specifier: expr` would be more desirable (another specifier cannot appear in a subexpression), but there is a parsing ambiguity: `.word :plt:fun` would be parsed as labels, and not as a relocation specifier.
(RISC-V could use `.word %specifier(expr)`, which has no ambiguity. I have proposed https://github.com/llvm/llvm-project/pull/132569 )

This issue aims to record the current undesirable and inconsistent state. @smithp35
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJycVtFu2zoS_Rr6ZWBBpiTbevCDNqm3xabYIs32NRiRY4lrilRJyo7__oK0Ezu5Be7tBQxIEMmZM-fMGRq9V50h2rDqX6y6n-EUeus2X9HvH_E0a608bfoQRs-KhvEt41tHB0VHn2l9GDLrOsa39-tFWS4BjYT3ezsV-qnNhB0Y38YDl8d8dPb_JALj23HSmvHtilfrEhi_A2WCs3ISJCH0BOg9Da0-gT-ZgC_Alnl2tE6CPw2szEcd5hlb5in5h7XOhlE40nF5Zx08PjfN493nZfn87eGp4OnI9du___v07e7x00PBwZG2AoOyxmcsb5565V_TH9GD6K0nA3IiCBbQAL0oH5Tp4Oek3B6UgYeHH18ZX3lo_PANnScXSzv25CiiPAOPuGK8yagDOY9anwCFoDGQhMkEpWE4gSNBJsA0SgwEjK-FHQYVAPPlarGqGK9hQEkQPxmwY5grAyM6HwHtCMPkKFYRf3wNfy3molpWeXWrwxlx87-nz4yvVRtLWfCijE-U0jFexx0pxVNPMHkCu3tfJ3pA8CMJtVPkAMdRq6iwBTqQO4GfWnoZHXmvrAHlQVjjlSRHEvC4P6KT2SW8I63QCAJrYo6vd99PQ2v1I-0-vYwullY0P9ApNOE_ysgkvaMYm0xSKfTk6Vbka60x7zBqelHhlPpDmQTEBzJCkYejCv2tvsoEcgb1NUMKGbE2HiQFVJpimA_ED-j3Dk_ZQIxvW20j8zzn1Twv5ovl_Apu3pEhd35VZn6xAznPeHGz643a-U7jwTqfvBRi5-I4Oouih151vVZdHyJs0tQlFiM0e0wVQY9GavI33Fw185cmaqKSg3UUJRKOAgG9YCQtZvzb7XX2gxL97zdaTIOpdxzFKQKoNeyVkT62nTIH1EpeDJu6Pv5wF6IJ4-ubO4IakqMo67I0PH5OKOG5q29AION3JY8um8Nzt_7VSsJU3xTkwdgAShLqV9LOjPmARqJ7BQda7ek6tVjRvLHNigaiIdKMsJOW0NI5hiSvHLY6IUdjQ0_uxlkCTUyO40joorj43lsXpO0Uog8cRbT4xggOreomFU4x_y2waOOi2U3mHaB4LBrUg8aWtE9CGZnKT47_VSNl50n0-OX73fwHiBQrjoxrOl5deeDrRMOb8meKe4wcX-Fm8AV6PBCMzo42YvqnF9Gi4NWyhpjwMtCUB-X9RIBq8OeuExFmvJ3E5FyazuYqy4exEaLqgTJgZe4HFfqxqGZyU8i6qHFGm8Wq5Mt1US4Ws36zlFWer3Z1XlLN1-syXwu5qCux5HXJq52cqU2cEnnBOedlUSyymu-KVlQLrOvdetWuWJnTgEq_eW6WwG9iXat8dtYp3factyj2ZCQrmqZxol-WjHPG7xjng4iv1f3MbRJN7dR5VuZa-XB18yyooNM_h9fj1T00H-7r8_T9cxfE1pQYEKRyJII6kJ9NTm9-W7dUnr8ot8pnhw3_IwAA__8CbOeu">