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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to