In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.
Differential Revision: https://reviews.llvm.org/D22296
llvm-svn: 289584
I discovered a case where the old algorithm would crash. Instead of
trying to patch the algorithm, rewrite it. The new algorithm operates
in three phases:
1. Find all paths to the subobject with the vptr.
2. Remove paths which are subsets of other paths.
3. Select the best path where 'best' is defined as introducing the most
covariant overriders. If two paths introduce different overriders,
raise a diagnostic.
llvm-svn: 236444
A class might contain multiple ways of getting to a vbase, some of which
are virtual and other non-virtual. It may be the case that a
non-virtual base contains an override of a method in a vbase. This
means that we must carefully pick between a set of nvbases to determine
which is the best.
As a consequence, the findPathForVPtr algorithm is considerably simpler.
llvm-svn: 236353
There can be multiple virtual bases which are on the path to a vfptr
when one vbase virtually inherits from another. We should prefer the
most derived virtual base which covariantly overrides a method in the
vfptr class; if we do not lengthen the path this way, we will end up
with too few vftable entries.
This fixes PR21073.
llvm-svn: 236239
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
Most importantly, this makes our vtable layout match MSVC's. Previously
we would emit a return adjusting thunk whenever the return types
differed, even if the adjustment would have been trivial.
MSVC does emit some trivial return adjusting thunks, but only if there
was already an overridden method that required a return adjustment.
llvm-svn: 198080
Peter Collingbourne