On Mon, 18 Mar 2024, Fangrui Song wrote:
LLVM has had an aarch64 mingw ABI support for a long time. Does this
patch series introduce a different ABI?
If yes, do you have a summary?
This patchset in itself does not reach ABI compatibility with the
preexisting aarch64 mingw ecosystem - but this is also just the first
patchset to lay out the groundwork for a new mingw target within GCC.
As far as I've understood, the divergence is not intended, and they are
working on converging towards compatibility - but such bits are to be
handled in later patchsets.
Off the top of my head, the major missing pieces wrt compatbility are the
variadic calling convention, and using 64 bit doubles for "long double"
(just like for Darwin).
Does the patch need any adaptation on the LLVM side, or should a
different target triple be picked?
No, I don't think a different target triple should be used - it is
intended to be the same, but compatibility is a work in progress.
I have always been wondering what "32" in "x86_x64-w64-mingw32" means.
(Nit, I presume you meant "x86_64-w64-mingw32".)
As Andrew replied, w32 stands for win32, which isn't so much about the
bitness as "the current windows API as of the last 30 years, as opposed to
win16". So it's more of a name than something indicating any form of
bitness.
Likewise, "w64" just indicates which vendor/fork is involved, so we also
have i686-w64-mingw32 and armv7-w64-mingw32, for the 32 bit ABIs with an
SDK from the same vendor.
https://github.com/llvm/llvm-project/pull/78908 even introduced the
first use of the triple "arm64ec-w64-mingw32" into llvm-project.
ARM64EC is a totally different thing though; that's an entirely separate
ABI on almost every single level.
// Martin
