[PATCH] D89490: Introduce __attribute__((darwin_abi))

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

In D89490#2514695 <https://reviews.llvm.org/D89490#2514695>, @aguinet wrote:

>> I may be over-reacting to the way the patch seemed to be touching on the C++ ABI in multiple places.  My understanding is that `ms_abi` is just a calling-convention attribute; it's basically "use the (default) calling convention that MSVC would use for this function".  If that's all you want, then this is reasonable, although I am worried about creating a new attribute for every system that Wine chooses to target.
>
> I literally based this patch on how ms_abi was implemented. It's unfortunately more than just teaching clang to change the calling convention on LLVM IR functions. The fact that ABI implementations are spread all over the place between various places in LLVM is, as far as I remember, a known problem discussed many times on llvm-dev, and looks like a hard one to fix.

Right, I understand that — I've even given an LLVM talk about it.  I was just confused about your intent because you made some effort to match other parts of the ABI besides what we might traditionally consider the calling convention.  I suppose some of those changes could be thought of as feature-specific calling conventions, but I don't usually think of them that way.

>> About "darwin": technically, every Apple platform has a different ABI.  Our current ARM64 platforms do all agree about things like the calling convention, at least if you count newer watches (which use a 32-on-64 ABI in userspace) as not ARM64.  That is not true of other architectures, most notably on ARM32, where the 32-bit iOS ABI is very different from the armv7k Apple Watch ABI; and it is certainly conceivable that Apple might release a new ARM64 platform in the future with a different calling convention.  The more technically correct and future-proof thing would be to use the OS name (or maybe even the triple!) in the attribute, probably as an argument to the attribute, like `__attribute__((target_abi("arm64-apple-ios")))`.
>
> I'm a bit afraid that `__attribute__((target_abi(XX)))` would conflict with the existing `__attribute__((ms_abi))`.

They don't *conflict*.  It's a more general scheme than the existing attribute, but the existing attribute can be thought of as a shorthand for one case of that more general scheme, so I don't see a problem here.  I would like to not have to add a new attribute for every OS that Wine decides to support.

> About Apple that would create as much ABIs as products, I guess we have a living example: is the ABI for OSX/ARM64 different than the ABI for iOS/ARM64? I can't seem find any official documentation about this :/ (only talking about arm64 here, but I get your points about armv7 targets).

No, we've used the same basic ABI on iOS, macOS, and tvOS for ARM64.  But that's not surprising because those products were all released within a relatively short period of time from each other, so we don't have much of a laundry list of things we'd like to improve about them.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89490/new/

https://reviews.llvm.org/D89490