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