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

[Adrien Guinet via Phabricator via llvm-commits]

aguinet added a comment.

In D89490#2516255 <https://reviews.llvm.org/D89490#2516255>, @rjmccall wrote:

> 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.

We could have a long discussion on what do we exactly call a "calling convention" :) IIRC I did implement a few C++ bits, but they could be removed from this patch for further implementation.

>>> 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.

You're right, let me rephrase what I wanted to say: with this, there will be two ways to target the windows ABI. I guess we can be fine with it, but that adds some kind of complexity that needs to be explained to the end user.

There is also the support the equivalent of the `__builtin_ms_va_list` type that needs to be considered, which would make a type that could look like `__builtin_abi_va_list_INSERT_TRIPLE_HERE`, with the fact that we can't have '-' in types. It might be better to do something similar than `ext_vector_type`, and have something like:

  typedef va_list __attribute__((target_abi("arm64-apple-ios"))) arm64_ios_abi_va_list; 

This means that `__builtin_ms_abi_va_list` would just be a typedef (and that might have some implication on legacy code?).

Another question I would have with that setup is how much this is "transposed" into the LLVM world. My feeling is that can be, at least as a first implementation, just a "frontend" to assign the darwin or MS ABI to functions.

>> 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.

Okay, thanks for the information!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89490