rnk wrote: Looks good.
I did some digging into the history of how we got int64_t here at all, since all the MS intrinsics used to use LL before we did the builtins.def -> tablegen migration. An agent produced this history: | Date | Change | |---|---| | 2013–2014 | Early `Intrin.h` declarations and inline implementations used **`__int64`**, including [`_InterlockedIncrement64`](https://github.com/llvm/llvm-project/commit/d6ffae91d535402b240128467bbcc5b09bd948aa) and [`_xgetbv`](https://github.com/llvm/llvm-project/commit/854f7d34ec3d7c0559ffde536cfa88fad5419bf0). | | September–October 2016 | Interlocked builtins used **`LLi`**, the encoding for `long long`, including their [reintroduction as target builtins](https://github.com/llvm/llvm-project/commit/5e08df02668ede5bfe79874fad6c1f3ce0325ee5). | | January 16, 2019 | [`931779761e7e`](https://github.com/llvm/llvm-project/commit/931779761e7e8852d6cbdf7a5cd55b1ccf287be1) introduced the surviving `_xgetbv`/`_xsetbv` builtin declarations with **`UWi`**, meaning `uint64_t`. | | July 8, 2020 | [`82206e7fb49d`](https://github.com/llvm/llvm-project/commit/82206e7fb49d9593d946599b107e8a8ad29a7d22) moved the eight interlocked builtins from `BuiltinsX86_64.def` to `BuiltinsX86.def` to support 32-bit Windows, changing **`LLi` to `Wi`** (`int64_t`) along the way. | | January 2025 | The [TableGen migration](https://github.com/llvm/llvm-project/commit/2529a8df53af9bc6cecfd6c83404ffa5e89e3370) spelled these as `int64_t`/`uint64_t`, preserving the earlier semantics. | So we got the int64_t versions in 2019-2020, which are fine for Windows, just not LP64 platforms like Linux `-fms-extensions`. https://github.com/llvm/llvm-project/pull/154946 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
