Re: [C++ patch] Reduce vtable alignment

[Jan Hubicka <hubicka@ucw.cz>]

> > 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