I'd like to propose this patch as an alternative to D17893 and D18199
that approaches the user interface to the relative C++ ABI feature from
a different angle. Instead of adding custom attributes and a whitelist,
we instead introduce a flag, -flto-relative-c++-abi-vtables, which enables
the relative ABI only for classes with hidden LTO visibility [0], which is
a concept we introduced for whole-program devirtualization that is based
on object file visibility. That concept also effectively controls where
the compiler is allowed to change the ABI arbitrarily. By using that very
similar concept, we can start off with a much simpler overall user interface,
at least for programs that are already using LTO.
It may seem strange to tie this feature to LTO visibility (and LTO), since
the feature of course does not intrinsically rely on LTO. However, I think
it seems reasonable for hidden LTO visibility to act as one possible source
of information for where the new ABI can be applied. At a later point we
can consider introducing other ways to enable the ABI (such as specific
attributes or whitelisting as proposed in D17893).
By requiring classes to have hidden visibility (a prerequisite for hidden
LTO visibility), we also avoid being blocked on the issues around non-hidden
visibility in ELF that were raised on the initial discussion thread for this
feature [1].
LTO also makes it a little easier to detect ABI mismatches in a platform
independent way using module flags. This patch introduces a module flag that
is used for that purpose.
[0] http://clang.llvm.org/docs/LTOVisibility.html
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-February/096146.html
It seems that the condition for treating a vtable component as an i32 vs i8* is slightly different here than in SetVTableInitializer. SetVTableInitializer checks
where GetVTableType just checks Component.isFunctionPointerKind().
Should this also check if the first or last component is a function pointer, and does this check in SetVTableInitializer have any importance with the FIXME below it?