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

    <tr>
        <th>Summary</th>
        <td>
            Concerns about x86-64 `_BitInt(65-128)` alignment
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

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

<pre>
    It is my understanding that currently, for the System V AMD64 ABI specification of `_BitInt(65-128)`, it has an alignment of only 8, whereas `__int128` has an alignment of 16. If I remember correctly, since both are specified to be "as if a struct of 8bytes", this has no consequence for the raw by-value case for functions with a few parameters. However, in the presence of many arguments, this means that it will hit the stack, and that it will be passed differently than `__int128` on the stack. It also means that if an allocation attempts to align itself to `_BitInt(128)`, it is incorrectly aligned for `__int128`, whereas `__int128` is correctly (over)aligned for `_BitInt(128)` allocations.

I have a concern about cross-language, and even, to some extent, assembly-code interoperability. A lack of 16-byte alignment means the type is incorrectly aligned using as a target of CMPXCHG16B's all-important m128 operand which _must_ be 16-byte aligned (an indicator of a 128-bit value at a memory address, not to be confused with `__m128`, which only prefers it for VEX encodings, except for VMOVAPS, but also the legacy SSE encodings still exist). It also means that any other programming language must double-up on types in order to do C FFI for such 16-byte types, whereas in some cases they may already have such types (and may want to already be able to use it for `__int128`). Obviously, the C Standard doesn't guarantee other languages won't need them anyways, but it still seems preferable if more implementations choose the form which has the largest aligned integer type match `_BitInt(N)`, even if merely for principle-of-least-astonishment reasons, and to help other compiler implementers down the road.

Obviously, we still need a stopping point somewhere. I only suggest it here as it's already a specified large integer type. The stack is 16-byte-aligned anyways, too.

I am aware that this decision is ultimately also something that requires the attention of the people who specified the psABI, and I have [raised this as an issue with them](https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/11). I am mentioning it to you, here, because I wish to make sure this concern is factored in to the release of LLVM 16, and because Clang is the pioneer of this implementation.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJx8Vktv68YO_jXyhpBhK7ZjL7zIo7k10HNbIBcH3R1QM5Q1PfNQh6Po6N9fcCQndvrYJLDE4ZDfgxQym7MnOhbbx2L7vMA-tSEehxC_G3_-o6-NJVrUQY_HUwLD4EbovabICb02_gypxQSqj5F8smNRPUETIqSW4HXkRA6-wsOX590GHh5PwB0p0xiFyQQPoYFit_r2aNLJp6La77blutoX1aHYrSSRSdAiA3pAa87ekU9yJng7wl4ChpYiIecs34xPcnq3-ttD690STg2cIJIjV1MEFWIkNdfMxiuCOqQWMNKlTtKQAtQERVUhg2kAgVPsVU65r8dEXFSVJEit4XyxD6CCZ_qzJ0l5ASPiAPVYvqHtCRTy9KbpvRIoGAYjV0NDA3QY0VGiyEv4OQz0RjGj4XOiLhLnzKEBh34EjOdeuuT3Mhyh54kYk2Aw1kJrUj7NCdV3CUSvbyNqgg6ZSYM2TUMTnRLiP8Mb_EeqJZwSoOVwc2kzwW_DTDSmRK5LLGhmVsAkJtvI7xsFfKbfMBj_TtR0lnSG7raof1GD4Q-qoaj2IeN5-JzrrzVcdcDLYvVcrB6mvydo8Y0AhWhF0QPWoU-gYmAuLfpzj2e6gExv5DMzATg4AvqRSO55AkHb1XYsVdAExieKoaOItbEmjUt4AIvq-yTeUrR2pegL2gRp7OifcOpZHCpugITxTFm2T19--_3p5_-sd49Fdc_SZGlcF2JCybuu9pCr8BqG1qgWvrme0zfRx00ZpAVM9GC8FkOHKMkR1tW-rE2CSemYAMGRC3EE1DoSZ5n6kGZnqeCbXlSXDZCpc9eUSgXZ8F2khiKLKoSyrz_9DuRVkBmUU9IPRd387suvXx9-e5WndT_LU6CydEY1wuvrTx9HgZOon34YTkV1-Fs9i8tCailCF8M5onMC64VoEHxAh762VPZdtsfYkTACIWqK0qkO8AQvL6dcH_eqfQczx17L1_hJKDIkMsUjOBROI6EeJ-nlDNMtmQSdQwZhMFtsCq0JsLYkj3qmC3KfjXNYwq_1mwk9T6NQkHqCV5nvGDXoQOyL6j7BuceIPhHNYFwAYBjCFOFJJmZLTiAbcOQLBSbNODOR45nLXJtpwIVIYFxnSaQ9-Q1UGwJTLqYJ0c1KkAGbmRQ1c3pXopjnLEiLGRwm1d56-r8fU0X8mG-lSHbMiHTReGU6S2VoSkvIqUROwRtus9mEluD5fWwGaMl2MwoquM5Yih8diEp1GKYpGQPqm-Fxg_VAMy4ZOVkuoetEXF0wPmUdZFks4TS5gPtzblxWI0USb5s0-3giHa-WV4bpBpwl_O8yumVozCIsLzhe0ZZC-DT00AEOsh2zKfKm0aQMy4Q3DL1NxmGiPH94mnapff9EiPRnb-Kk6LwQ_OUbIG81Cp0lGNpwvXvlBT88ni7Iz4O32D5GNJwjDMO07Q1zT9MUEQUW2-ei2rcpdVzcPRTVS1G9nE2yWC9VcEX18mO_K3Nynn_sNmW-6qUsqpecTd6s19NUkO7dVLO0ZLLRxtBLacJEVjopFKOdYDDcSoDD72LWjFneQ9O-MAwNqhRilq4EZqmQaC8v9l9--foF1rtL35fET2I5OZ2RMcETxQlBWQA3Dlou9PFOH-4OuKDjend_vzocVptq0R6bw4bqzWG9bnSz0bt7vb-7O1TN3fqedk2j7xfmWK2qu1VVVdVqu9pUS7XWu-2-0Yf7Zq2oborNihwau7T2zS1DPC8yXMfd6lBtFxZrspw_KKvK0zAxI59J2-dFPMqZsu7PXGxW1nDijyzJJEvHpwkknrfqRM0_fyh-LMVFH-3xL4y3_YVxuWf-V3Yx_EEqXTOdq_9_AAAA__8DY8dS">