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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
