This is an archive of the discontinued LLVM Phabricator instance.

Introduce support for relative C++ ABI gated on LTO visibility.
Needs ReviewPublic

Authored by pcc on May 27 2016, 1:55 PM.

Details

Summary

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

Diff Detail

Event Timeline

pcc updated this revision to Diff 58834.May 27 2016, 1:55 PM
pcc retitled this revision from to Introduce support for relative C++ ABI gated on LTO visibility..
pcc updated this object.
pcc added a subscriber: cfe-commits.
espindola edited reviewers, added: espindola; removed: rafael.Mar 15 2018, 10:09 AM

Hi @pcc , I'm working on revisiting this to see if this could help when building Fuchsia (D58321) and had a few questions I left inline.

lib/CodeGen/CGVTables.cpp
532

It seems that the condition for treating a vtable component as an i32 vs i8* is slightly different here than in SetVTableInitializer. SetVTableInitializer checks

Component.isFunctionPointerKind() && (I == 0 || !Components[I - 1].isFunctionPointerKind())

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?

test/CodeGenCXX/vtable-relative-abi.cpp
5

Should the second getelementptr access be i32 0, i32 3 instead since it’s for the 4th element in the struct?

If so, I think this is due to some referencing problem with the maybeMakeRelative lambda. I ran into this issue when I moved llvm::Type *VTableTy = VTable->getValueType(); into the following if block that initializes AddrPointInt. This also seems to occur for other test classes that contain more than one virtual function.

ormris added a subscriber: ormris.May 1 2019, 11:29 AM