This reverts commit 86dbcafd0cdc88ae85896c6f12ecaa6006aeba54.
Reverting since this depends on db288184765c0b4010060ebea1f6de3ac1f66445
which broke our lto builders reported by fxbug.dev/12380.
This way, C++ relative-vtables can also participate in GlobalDCE. This
depends on some TypeMetadataUtils.cpp bits in D134320, but that
dependency can be removed and included here if necessary.
Differential Revision: https://reviews.llvm.org/D135928
The script mangled both virtual-functions-base-pointer-call.ll and
virtual-functions-derived-pointer-call.ll pretty badly, deleting the
run line and most of the block comment.
Replaced the bitcast with and addrspacecast in 2002-07-17-CastRef.ll,
based on the apparent intent of the test.
For 2003-07-01-SelfReference.ll, the script produced "call ptr ()
@getfunc" which surprisingly parses as valid.
This is for Swift VFE support. In some vtable forms that Swift emits, the "base" of a relative pointer is not the global symbol itself directly, but a GEP into it -- so the pointer is relative to a particular field in the global. So getPointerAtOffset() needs to be able to see through the GEP and allow it in a SUB expression, to correctly recognize the offset as a vtable slot.
Differential Revision: https://reviews.llvm.org/D109169
