> > Hmm, but if the optimizers or the target can rely on DATA_ABI_ALIGNMENT > > then we can't really lower it. Because we can make the vtable escape > > to another unit that sees it as just an array of pointers? > > Sure, they can rely on DATA_ABI_ALIGNMENT (if that macro is defined), but > anything beyond that (such as what DATA_ALIGNMENT returns) is optimization > only. So, Honza's patch looks good for me.
Yep, DATA_ALIGNMENT is computed when type is finalized, so I think this should be safe. > > > So this looks unsafe to me. (same may apply to the idea of > > having TARGET_VTABLE_ENTRY_ALIGN at all, if that possibly > > conflicts with ABI alignment requirements present otherwise). > > Right now the intersection of targets overriding TARGET_VTABLE_ENTRY_ALIGN and > targets defining DATA_ABI_ALIGNMENT is empty. In any case, even in that > case one should (if DATA_ABI_ALIGNMENT is defined) apply DATA_ABI_ALIGNMENT > (on top of TARGET_VTABLE_ENTRY_ALIGN and/or TYPE_ALIGN, dunno how those two > exactly mix together) and not DATA_ALIGNMENT. But this patch is about > tinfo, not vtable. There are two patches, one is for RTTI and other is for vtables. Vtables are fully compiler controlled structures, as such I think we do not need to align them as usual arrays. C++ ABI does not really speak about alignment of these, but I believe it is safe to stop aligning them, since all we do is random accesses at given offset of the symbol - nothing where we can use the alignment. We can bump it down to DATA_ALIGNMENT boundary like I do for RTTI, but it would still waste several percent of the data segment. (Clang indeed aligns to 16 byte boundary here) Honza
