[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[John McCall via Phabricator via cfe-commits]

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