[PATCH] D124998: [AArch64][SVE] Add aarch64_sve_pcs attribute to Clang

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu May 5 10:12:22 PDT 2022


erichkeane added a comment.

In D124998#3494388 <https://reviews.llvm.org/D124998#3494388>, @paulwalker-arm wrote:

> In D124998#3494127 <https://reviews.llvm.org/D124998#3494127>, @aaron.ballman wrote:
>
>> In D124998#3493791 <https://reviews.llvm.org/D124998#3493791>, @paulwalker-arm wrote:
>>
>>> Just wanted to say this is not a new calling convention as such, but rather an existing one that is generally auto-detected based on function signature.  The problem we're trying to solve here is that we need a way to allow a user to force the calling convention when the function signature would not normally choose it.
>>
>> Thanks for this information! It's still not clear to me whether there's sufficient need for this extension. From this description, it sounds like this will be rarely used because it's only necessary in one-off situations. If that's correct, can those users make use of inline assembly instead of a devoted named calling convention?
>
> It's hard to say how often this will be used but when used it will be fundamental to performance. I don't see inline assembly as a workable solution. It presents an unreasonable burden on a framework's user and will impact compiler optimisations.  The ACLE exists to stop developers from needing to use inline assembly.
>
> You have to forgive my naivety here but some of the calling conventions are target specific.  Is it possible for them to safely alias for the parts of the code where memory is constrained?  Or to put it another way, do the X86 and AArch64 calling conventions need to be uniquely identifiable?

This would alleviate my concerns if we were to do something like that. It _IS_ quite unfair how many calling convention bits we burn on old 32-bit-MSVC and X86/x86-64 calling conventions that don't seem particularly well used/valuable.

I looked into doing that at one point about 2 years ago, but it ended up being not possible/beneficial thanks to our multi-target-at-the-same-time compilation model for offload.  Basically: we need to identify TWO calling convention lists at the same time, and there are combos that result in us having more than 16 items, thus not saving any bits.  If you can come up with a way of doing this that I was unable to come up with at the time, I'm all for it!  At that point, it would be up to the individual targets to manage themselves in a way to stay sub-16.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124998



More information about the cfe-commits mailing list