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

Thu May 5 12:51:47 PDT 2022

erichkeane added a comment.

In D124998#3494785 <https://reviews.llvm.org/D124998#3494785>, @aaron.ballman wrote:

> In D124998#3494500 <https://reviews.llvm.org/D124998#3494500>, @erichkeane wrote:
>
>> In D124998#3494442 <https://reviews.llvm.org/D124998#3494442>, @efriedma wrote:
>>
>>> In D124998#3494426 <https://reviews.llvm.org/D124998#3494426>, @erichkeane wrote:
>>>
>>>> In D124998#3494424 <https://reviews.llvm.org/D124998#3494424>, @efriedma wrote:
>>>>
>>>>> If you're really concerned about the size of FunctionProtoType increasing, can we just shove the infrequently used calling convention bits into TrailingObjects?
>>>>
>>>> I don't believe so.  These are parts of the bitfield and are intrinsic to the type.
>>>
>>> I don't follow. Everything stored in FunctionProtoType, including information stored in TrailingObjects, is "intrinsic to the type".  It's just stored differently.  (FunctionTypeExtraBitfields already exists, even...)
>>
>> Ah, I see what you mean.  I misread and thought you meant on the FunctionDecl itself, so mea culpa.
>>
>> I was unaware of `FunctionTypeExtraBitfields`!  We perhaps should consider what of the `ExtInfo` we can move over to the `FunctionTypeExtraBitfields`.  In that list, there are MAYBE 5 bits of the 13 that are used with any level of commonness (though I have no idea what CmseNSCall means). If most of those moved, I'd be pretty ok with having even EXTRA bits added for calling convention (though, if we go over 32, we probably need to have a discussion as to whether they are valuable).
>
> Not to be a party pooper, but that only works for `FunctionProtoType` and users can write calling conventions on functions without prototypes too, which has no trailing objects currently. However, functions without prototypes aren't a worry for deep template instantiations or the like (because they don't exist in C++), and if users are making heavy use of functions without prototypes (never been a feature in any ISO C standard), I don't particularly mind if their compilation goes slower because we now need to tail allocate data for each non-prototype function. However, we should be careful not to duplicate code as I'm pretty sure that's why `ExtInfo` is in `FunctionType` in the first place (there's no way to add a trailing object to `FunctionType` because it's subclassed).

First: I care very little about `FunctionNoProtoType`.  Second, it is used only in "C" afaik, where our memory pressure isn't that big of a deal.  I'd be OK with having the `FunctionTypeExtraBits` be just added to `FunctionNoProtoType`, but stay in `FunctionProtoType` trailing storage.

It WOULD be more work, but I would wonder if we could combine all 3 classes into `FunctionType` and replace the `NoProtoType`-ness with a single bit to differentiate.  The result is the non-prototyped versions needing to carry around extra information, but since:
a- our C implementation has low memory pressure
b- prototypeless functions were a mistake

I would think the extra memory they end up carrying might be ok?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124998