On Sun, Oct 27, 2013 at 11:11 AM, Timur Iskhodzhanov <[email protected]>wrote:
> 2013/10/26 Reid Kleckner <[email protected]>: > > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
