The relative vtable ABI will use a struct rather than an array as the type
of a vtable. LLVM only allows 32-bit integers as struct indices, so we need
to use 32-bit integers to get addresses of address points. In order to keep
the code simple, we might as well do that unconditionally.
It's probably a reasonable implementation limit to support no more than 2
billion virtual functions per class.
This change causes quite a bit of churn in the test suite, so I'm making
it separately.
Differential Revision: http://reviews.llvm.org/D18113
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263469 91177308-0d34-0410-b5e6-96231b3b80d8
We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of
the data being stored rather than on the pointer being stored to.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D5916
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223267 91177308-0d34-0410-b5e6-96231b3b80d8
optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the VTT.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131400 91177308-0d34-0410-b5e6-96231b3b80d8
that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.
Fixes PR9181.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131368 91177308-0d34-0410-b5e6-96231b3b80d8
Peter Collingbourne