[clang] [llvm] [X86] Add WinCall Calling Convention and x86_64apx-windows(-gnu/-msvc) triplets (PR #215585)
via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 11 13:19:00 PDT 2026
================
@@ -0,0 +1,454 @@
+# The WinCall Calling Convention Draft
+
+## What WinCall is
+
+WinCall is an x86-64 **calling convention for Windows targets**. It is
+spelled ``x86_wincallcc`` in LLVM IR and corresponds to
+``CallingConv::X86_WinCall`` (CC ID 128).
+
+Its purpose is to exploit the 16 additional general-purpose registers
+(R16-R31) introduced by Intel APX. On a conventional Windows x64 ABI only
+four integer arguments can be passed in registers; WinCall doubles that to
+eight by using R16-R19 as argument registers. It also relaxes the aggregate
+passing and return rules of the Microsoft x64 ABI so that C++ types such as
+``std::span`` (a ``{pointer, size}`` pair) and other small aggregates can
+travel in registers.
+
+WinCall does **not** replace any existing ABI. Existing Windows APIs keep
+their ``stdcall``, ``cdecl`` and ``fastcall`` conventions; the convention is
+opt-in and only affects code that is explicitly built for it.
+
+## When WinCall is used
+
+WinCall applies in two situations:
+
+1. It is the **default calling convention** of the ``x86_64apx-windows-msvc``
+ and ``x86_64apx-windows-gnu`` target triples
+ (``X86_64TargetInfo::getDefaultCallingConv`` returns ``CC_WinCall`` for
+ ``getTriple().isWindowsAPX()``).
+
+2. It can be selected per-function with the ``wincall`` attribute
+ (``__attribute__((wincall))``, ``__wincall``, ``_wincall``), which maps to
+ ``CC_WinCall`` in the frontend.
+
+WinCall is **x86-64 only**. On 32-bit x86 or on any non-x86 target the
+attribute is ignored with a warning
+(``X86TargetInfo::checkCallingConvention`` does not accept it there).
+
+## The x86_64apx sub-architecture
+
+The ``x86_64apx`` triple component is a *sub-architecture* of ``x86_64``,
+modelled on how ``arm64ec`` is a sub-architecture of ``aarch64``:
----------------
trcrsired wrote:
> https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types
>
> Since arm64ec has different PE/COFF machine types, should we define a new one for x86_64apx as well?
i think no. x86_64apx is just x86_64 with better calling convention. arm64ec is pretty useless in reality
https://github.com/llvm/llvm-project/pull/215585
More information about the llvm-commits
mailing list