aaron.ballman added a comment. 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). 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
