[PATCH] Make thunk this/return adjustment ABI-specific. Also, fix the return adjustment when using -cxx-abi microsoft

[Reid Kleckner]

On Sun, Oct 27, 2013 at 11:11 AM, Timur Iskhodzhanov <timurrrr at google.com>wrote:

> 2013/10/26 Reid Kleckner <rnk at google.com>:
> >   I think we should have ABI-specific thunks, something like
> MSThunkInfo, MSThisAdjustment, MSReturnAdjustment.  With the change you've
> written here, CGVTables will no longer access fields of ThunkInfo, instead
> it will pass them through to the ABI code.
> >
> >   However, splitting apart the uses of ThunkInfoVectorTy + ThunkMapTy
> seems hard.  What do you think?  Is it worth spending a few hours on it to
> see if it can be done?
> >
> >   I probably wouldn't go so far as to add support for cast<> to these,
> because it would require space in ThunkInfo, and we allocate these things
> in arrays.
>
> I'm concerned about ThunkInfos being passed in arrays around.
>
> Fixing EmitThunks() (line 450) doesn't look hard.
> There's also CreateVTableInitializer() which takes
> VTableLayout::VTableThunkTy, which is an array of pair<index,
> ThunkInfo>.
>
> The codegen for thunks is very similar in both ABIs we support, other
> than applying the vbase offset, so I'm not sure we want to make
> different codegen codepaths for different ABIs. Yet we want the
> ThunkInfos we pass around to hold ABI-specific data... We can probably
> store ThunkInfo* in the vectors, but that'd require storing the
> ThunkInfo-derived objects in some ABI-specific storage which
> guarantees not to move around. That sounds like a not-very-small
> change.
> And I do believe we'll want casts<> there, be it static_cast or
> [dyn_]cast<>, the latter being less error-prone.
>
> What do you think?
>

I changed my mind, I don't think it's worth it.  The union seems fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131029/e3ec4bee/attachment.html>