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? _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
