rjmccall added a comment. In https://reviews.llvm.org/D48589#1144976, @rogfer01 wrote:
> @rjmccall because we do not want to impact the clients of `ABIArgInfo` I > thought of two possible approaches > > 1. extend `CGFunctionInfo` with a third trailing array (now it has two), with > as many elements as `ABIArgInfo` (call it `ABIArgExtraInfo`) then during the > creation of `CGFunctionInfo` link (somehow, see discussion below) each > `ABIArgInfo`to its corresponding `ABIArgExtraInfo`. > 2. add a dynamic container like a `SmallVector<ABIArgExtraInfo, 2>` in > `CGFunctionInfo` and allocate `ABIArgExtraInfo` as needed. > > In both cases during `getFOO`, `ABIArgInfo` would put the extra (less > commonly used) data into the corresponding `ABIArgExtraInfo` (overflowing > object). > > In both cases too, we need a way to navigate to our enclosing > `CGFunctionInfo` but strictly only during the `getFOO` that fills the > `ABIArgInfo`. Getting it from the users is not possible, so we would need a > pointer to `CGFunctionInfo` in `ABIArgInfo` (set up during the creation of > `CGFunctionInfo`). That said, there is no need of its value all the time, > only at the beginning of `getFOO`. We could reuse its storage to point the > overflowing object (if needed, and set it to null otherwise). > > Do any of the approaches look any close to what you had in mind? Perhaps > I'm missing the point. Well, there's no point in having a trailing array that's always got the same number of elements as there are `ABIArgInfo`s, because then we're not actually saving any memory. What I was thinking was that the representation of `ABIArgInfo` doesn't really change when it's being passed around as an independent value, but when it's stored in a `CGFunctionInfo`, we break it up into two components: one that stores all the stuff that frequently appears in `ABIArgInfo`s (which can go in a trailing array indexed by argument index) and one for all the uncommon information (which can go in a condensed trailing array indexed by nothing externally meaningful). When you ask a `CGFunctionInfo` for the `ABIArgInfo` for the kth argument, it has to reassemble it, which it does by getting the common-subset `ABIArgInfo`, asking whether it needs any extra information, and (if so) pulling that out of the second array. Storing the common-subset data together with an index into the trailing array (actually, this could reasonably just be a 32-bit byte offset from the address point of the CGFunctionInfo, which would be more efficient when recreating the `ABIArgInfo` and would also let us use the zero offset to mean there's no extra information) should be doable in 64 bits, vs. 192 bits in the current representation, so it's a significant savings even before we start adding new fields to `ABIArgInfo`. https://reviews.llvm.org/D48589 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
