2013-10-02 05:51:38 +08:00
|
|
|
//===----- CGCXXABI.cpp - Interface to C++ ABIs ---------------------------===//
|
2010-11-29 01:46:52 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This provides an abstract class for C++ code generation. Concrete subclasses
|
|
|
|
// of this implement code generation for specific C++ ABIs.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CGCXXABI.h"
|
2015-09-17 04:15:55 +08:00
|
|
|
#include "CGCleanup.h"
|
2010-11-29 01:46:52 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
2010-11-29 01:49:03 +08:00
|
|
|
using namespace CodeGen;
|
2010-11-29 01:46:52 +08:00
|
|
|
|
2015-10-20 21:23:58 +08:00
|
|
|
CGCXXABI::~CGCXXABI() { }
|
2010-11-29 01:49:03 +08:00
|
|
|
|
2013-03-23 03:02:54 +08:00
|
|
|
void CGCXXABI::ErrorUnsupportedABI(CodeGenFunction &CGF, StringRef S) {
|
2011-09-26 07:23:43 +08:00
|
|
|
DiagnosticsEngine &Diags = CGF.CGM.getDiags();
|
|
|
|
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
|
2012-06-29 09:14:21 +08:00
|
|
|
"cannot yet compile %0 in this ABI");
|
2010-11-29 01:49:03 +08:00
|
|
|
Diags.Report(CGF.getContext().getFullLoc(CGF.CurCodeDecl->getLocation()),
|
|
|
|
DiagID)
|
|
|
|
<< S;
|
|
|
|
}
|
|
|
|
|
2014-05-15 00:02:09 +08:00
|
|
|
bool CGCXXABI::canCopyArgument(const CXXRecordDecl *RD) const {
|
|
|
|
// We can only copy the argument if there exists at least one trivial,
|
|
|
|
// non-deleted copy or move constructor.
|
PR19668, PR23034: Fix handling of move constructors and deleted copy
constructors when deciding whether classes should be passed indirectly.
This fixes ABI differences between Clang and GCC:
* Previously, Clang ignored the move constructor when making this
determination. It now takes the move constructor into account, per
https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
seem recent, but the ABI change was agreed on the Itanium C++ ABI
list a long time ago).
* Previously, Clang's behavior when the copy constructor was deleted
was unstable -- depending on whether the lazy declaration of the
copy constructor had been triggered, you might get different behavior.
We now eagerly declare the copy constructor whenever its deletedness
is unclear, and ignore deleted copy/move constructors when looking for
a trivial such constructor.
This also fixes an ABI difference between Clang and MSVC:
* If the copy constructor would be implicitly deleted (but has not been
lazily declared yet), for instance because the class has an rvalue
reference member, we would pass it directly. We now pass such a class
indirectly, matching MSVC.
Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
Schmidt, which was based on a patch by Reid Kleckner!
This is a re-commit of r310401, which was reverted in r310464 due to ARM
failures (which should now be fixed).
llvm-svn: 310983
2017-08-16 09:49:53 +08:00
|
|
|
return RD->canPassInRegisters();
|
2014-05-15 00:02:09 +08:00
|
|
|
}
|
|
|
|
|
2013-03-23 03:02:54 +08:00
|
|
|
llvm::Constant *CGCXXABI::GetBogusMemberPointer(QualType T) {
|
2010-11-29 01:49:03 +08:00
|
|
|
return llvm::Constant::getNullValue(CGM.getTypes().ConvertType(T));
|
|
|
|
}
|
|
|
|
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::Type *
|
2010-11-29 01:49:03 +08:00
|
|
|
CGCXXABI::ConvertMemberPointerType(const MemberPointerType *MPT) {
|
|
|
|
return CGM.getTypes().ConvertType(CGM.getContext().getPointerDiffType());
|
|
|
|
}
|
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee CGCXXABI::EmitLoadOfMemberFunctionPointer(
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CodeGenFunction &CGF, const Expr *E, Address This,
|
|
|
|
llvm::Value *&ThisPtrForCall,
|
2014-02-21 07:22:07 +08:00
|
|
|
llvm::Value *MemPtr, const MemberPointerType *MPT) {
|
2010-11-29 01:49:03 +08:00
|
|
|
ErrorUnsupportedABI(CGF, "calls through member pointers");
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
ThisPtrForCall = This.getPointer();
|
2010-11-29 01:49:03 +08:00
|
|
|
const FunctionProtoType *FPT =
|
|
|
|
MPT->getPointeeType()->getAs<FunctionProtoType>();
|
|
|
|
const CXXRecordDecl *RD =
|
|
|
|
cast<CXXRecordDecl>(MPT->getClass()->getAs<RecordType>()->getDecl());
|
2012-02-17 11:33:10 +08:00
|
|
|
llvm::FunctionType *FTy = CGM.getTypes().GetFunctionType(
|
2015-12-03 05:58:08 +08:00
|
|
|
CGM.getTypes().arrangeCXXMethodType(RD, FPT, /*FD=*/nullptr));
|
2016-10-27 07:46:34 +08:00
|
|
|
llvm::Constant *FnPtr = llvm::Constant::getNullValue(FTy->getPointerTo());
|
|
|
|
return CGCallee::forDirect(FnPtr, FPT);
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2014-02-21 07:22:07 +08:00
|
|
|
llvm::Value *
|
|
|
|
CGCXXABI::EmitMemberDataPointerAddress(CodeGenFunction &CGF, const Expr *E,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address Base, llvm::Value *MemPtr,
|
2014-02-21 07:22:07 +08:00
|
|
|
const MemberPointerType *MPT) {
|
2010-11-29 01:49:03 +08:00
|
|
|
ErrorUnsupportedABI(CGF, "loads of member pointers");
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Type *Ty = CGF.ConvertType(MPT->getPointeeType())
|
|
|
|
->getPointerTo(Base.getAddressSpace());
|
2010-11-29 01:49:03 +08:00
|
|
|
return llvm::Constant::getNullValue(Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *CGCXXABI::EmitMemberPointerConversion(CodeGenFunction &CGF,
|
|
|
|
const CastExpr *E,
|
|
|
|
llvm::Value *Src) {
|
|
|
|
ErrorUnsupportedABI(CGF, "member function pointer conversions");
|
2013-03-23 03:02:54 +08:00
|
|
|
return GetBogusMemberPointer(E->getType());
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
llvm::Constant *CGCXXABI::EmitMemberPointerConversion(const CastExpr *E,
|
|
|
|
llvm::Constant *Src) {
|
2013-03-23 03:02:54 +08:00
|
|
|
return GetBogusMemberPointer(E->getType());
|
2012-02-15 09:22:51 +08:00
|
|
|
}
|
|
|
|
|
2010-11-29 01:49:03 +08:00
|
|
|
llvm::Value *
|
|
|
|
CGCXXABI::EmitMemberPointerComparison(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *L,
|
|
|
|
llvm::Value *R,
|
|
|
|
const MemberPointerType *MPT,
|
|
|
|
bool Inequality) {
|
|
|
|
ErrorUnsupportedABI(CGF, "member function pointer comparison");
|
|
|
|
return CGF.Builder.getFalse();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *
|
|
|
|
CGCXXABI::EmitMemberPointerIsNotNull(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *MemPtr,
|
|
|
|
const MemberPointerType *MPT) {
|
|
|
|
ErrorUnsupportedABI(CGF, "member function pointer null testing");
|
|
|
|
return CGF.Builder.getFalse();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *
|
|
|
|
CGCXXABI::EmitNullMemberPointer(const MemberPointerType *MPT) {
|
2013-03-23 03:02:54 +08:00
|
|
|
return GetBogusMemberPointer(QualType(MPT, 0));
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2015-06-23 15:31:01 +08:00
|
|
|
llvm::Constant *CGCXXABI::EmitMemberFunctionPointer(const CXXMethodDecl *MD) {
|
|
|
|
return GetBogusMemberPointer(CGM.getContext().getMemberPointerType(
|
|
|
|
MD->getType(), MD->getParent()->getTypeForDecl()));
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2011-02-03 16:15:49 +08:00
|
|
|
llvm::Constant *CGCXXABI::EmitMemberDataPointer(const MemberPointerType *MPT,
|
|
|
|
CharUnits offset) {
|
2013-03-23 03:02:54 +08:00
|
|
|
return GetBogusMemberPointer(QualType(MPT, 0));
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2012-01-14 12:30:29 +08:00
|
|
|
llvm::Constant *CGCXXABI::EmitMemberPointer(const APValue &MP, QualType MPT) {
|
2013-03-23 03:02:54 +08:00
|
|
|
return GetBogusMemberPointer(MPT);
|
2012-01-14 12:30:29 +08:00
|
|
|
}
|
|
|
|
|
2010-11-29 01:49:03 +08:00
|
|
|
bool CGCXXABI::isZeroInitializable(const MemberPointerType *MPT) {
|
|
|
|
// Fake answer.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
void CGCXXABI::buildThisParam(CodeGenFunction &CGF, FunctionArgList ¶ms) {
|
2010-11-29 01:49:03 +08:00
|
|
|
const CXXMethodDecl *MD = cast<CXXMethodDecl>(CGF.CurGD.getDecl());
|
|
|
|
|
|
|
|
// FIXME: I'm not entirely sure I like using a fake decl just for code
|
|
|
|
// generation. Maybe we can come up with a better way?
|
2017-06-09 21:40:18 +08:00
|
|
|
auto *ThisDecl = ImplicitParamDecl::Create(
|
|
|
|
CGM.getContext(), nullptr, MD->getLocation(),
|
|
|
|
&CGM.getContext().Idents.get("this"), MD->getThisType(CGM.getContext()),
|
|
|
|
ImplicitParamDecl::CXXThis);
|
2011-03-09 12:27:21 +08:00
|
|
|
params.push_back(ThisDecl);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CGF.CXXABIThisDecl = ThisDecl;
|
|
|
|
|
|
|
|
// Compute the presumed alignment of 'this', which basically comes
|
|
|
|
// down to whether we know it's a complete object or not.
|
|
|
|
auto &Layout = CGF.getContext().getASTRecordLayout(MD->getParent());
|
|
|
|
if (MD->getParent()->getNumVBases() == 0 || // avoid vcall in common case
|
|
|
|
MD->getParent()->hasAttr<FinalAttr>() ||
|
|
|
|
!isThisCompleteObject(CGF.CurGD)) {
|
|
|
|
CGF.CXXABIThisAlignment = Layout.getAlignment();
|
|
|
|
} else {
|
|
|
|
CGF.CXXABIThisAlignment = Layout.getNonVirtualAlignment();
|
|
|
|
}
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
[MS] Apply adjustments after storing 'this'
Summary:
The MS ABI convention is that the 'this' pointer on entry is the address
of the vfptr that was used to make the virtual method call. In other
words, the pointer on entry always points to the base subobject that
introduced the virtual method. Consider this hierarchy:
struct A { virtual void f() = 0; };
struct B { virtual void g() = 0; };
struct C : A, B {
void f() override;
void g() override;
};
On entry to C::g, [ER]CX will contain the address of C's B subobject,
and C::g will have to subtract sizeof(A) to recover a pointer to C.
Before this change, we applied this adjustment in the prologue and
stored the new value into the "this" local variable alloca used for
debug info. However, MSVC does not do this, presumably because it is
often profitable to fold the adjustment into later field accesses. This
creates a problem, because the debugger expects the variable to be
unadjusted. Unfortunately, CodeView doesn't have anything like DWARF
expressions for computing variables that aren't in the program anymore,
so we have to declare 'this' to be the unadjusted value if we want the
debugger to see the right value.
This has the side benefit that, in optimized builds, the 'this' pointer
will usually be available on function entry because it doesn't require
any adjustment.
Reviewers: hans
Subscribers: aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D40109
llvm-svn: 318440
2017-11-17 03:09:36 +08:00
|
|
|
llvm::Value *CGCXXABI::loadIncomingCXXThis(CodeGenFunction &CGF) {
|
|
|
|
return CGF.Builder.CreateLoad(CGF.GetAddrOfLocalVar(getThisDecl(CGF)),
|
|
|
|
"this");
|
|
|
|
}
|
|
|
|
|
|
|
|
void CGCXXABI::setCXXABIThisValue(CodeGenFunction &CGF, llvm::Value *ThisPtr) {
|
2010-11-29 01:49:03 +08:00
|
|
|
/// Initialize the 'this' slot.
|
|
|
|
assert(getThisDecl(CGF) && "no 'this' variable for function");
|
[MS] Apply adjustments after storing 'this'
Summary:
The MS ABI convention is that the 'this' pointer on entry is the address
of the vfptr that was used to make the virtual method call. In other
words, the pointer on entry always points to the base subobject that
introduced the virtual method. Consider this hierarchy:
struct A { virtual void f() = 0; };
struct B { virtual void g() = 0; };
struct C : A, B {
void f() override;
void g() override;
};
On entry to C::g, [ER]CX will contain the address of C's B subobject,
and C::g will have to subtract sizeof(A) to recover a pointer to C.
Before this change, we applied this adjustment in the prologue and
stored the new value into the "this" local variable alloca used for
debug info. However, MSVC does not do this, presumably because it is
often profitable to fold the adjustment into later field accesses. This
creates a problem, because the debugger expects the variable to be
unadjusted. Unfortunately, CodeView doesn't have anything like DWARF
expressions for computing variables that aren't in the program anymore,
so we have to declare 'this' to be the unadjusted value if we want the
debugger to see the right value.
This has the side benefit that, in optimized builds, the 'this' pointer
will usually be available on function entry because it doesn't require
any adjustment.
Reviewers: hans
Subscribers: aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D40109
llvm-svn: 318440
2017-11-17 03:09:36 +08:00
|
|
|
CGF.CXXABIThisValue = ThisPtr;
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void CGCXXABI::EmitReturnFromThunk(CodeGenFunction &CGF,
|
|
|
|
RValue RV, QualType ResultType) {
|
|
|
|
CGF.EmitReturnOfRValue(RV, ResultType);
|
|
|
|
}
|
|
|
|
|
2011-01-27 17:37:56 +08:00
|
|
|
CharUnits CGCXXABI::GetArrayCookieSize(const CXXNewExpr *expr) {
|
2012-05-01 13:23:51 +08:00
|
|
|
if (!requiresArrayCookie(expr))
|
|
|
|
return CharUnits::Zero();
|
|
|
|
return getArrayCookieSizeImpl(expr->getAllocatedType());
|
|
|
|
}
|
|
|
|
|
|
|
|
CharUnits CGCXXABI::getArrayCookieSizeImpl(QualType elementType) {
|
|
|
|
// BOGUS
|
2010-11-29 01:49:03 +08:00
|
|
|
return CharUnits::Zero();
|
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address CGCXXABI::InitializeArrayCookie(CodeGenFunction &CGF,
|
|
|
|
Address NewPtr,
|
|
|
|
llvm::Value *NumElements,
|
|
|
|
const CXXNewExpr *expr,
|
|
|
|
QualType ElementType) {
|
2010-11-29 01:49:03 +08:00
|
|
|
// Should never be called.
|
|
|
|
ErrorUnsupportedABI(CGF, "array cookie initialization");
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return Address::invalid();
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
bool CGCXXABI::requiresArrayCookie(const CXXDeleteExpr *expr,
|
|
|
|
QualType elementType) {
|
|
|
|
// If the class's usual deallocation function takes two arguments,
|
|
|
|
// it needs a cookie.
|
|
|
|
if (expr->doesUsualArrayDeleteWantSize())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return elementType.isDestructedType();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool CGCXXABI::requiresArrayCookie(const CXXNewExpr *expr) {
|
|
|
|
// If the class's usual deallocation function takes two arguments,
|
|
|
|
// it needs a cookie.
|
|
|
|
if (expr->doesUsualArrayDeleteWantSize())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return expr->getAllocatedType().isDestructedType();
|
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void CGCXXABI::ReadArrayCookie(CodeGenFunction &CGF, Address ptr,
|
2012-05-01 13:23:51 +08:00
|
|
|
const CXXDeleteExpr *expr, QualType eltTy,
|
|
|
|
llvm::Value *&numElements,
|
|
|
|
llvm::Value *&allocPtr, CharUnits &cookieSize) {
|
|
|
|
// Derive a char* in the same address space as the pointer.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
ptr = CGF.Builder.CreateElementBitCast(ptr, CGF.Int8Ty);
|
2012-05-01 13:23:51 +08:00
|
|
|
|
|
|
|
// If we don't need an array cookie, bail out early.
|
|
|
|
if (!requiresArrayCookie(expr, eltTy)) {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
allocPtr = ptr.getPointer();
|
2014-05-21 13:09:00 +08:00
|
|
|
numElements = nullptr;
|
2012-05-01 13:23:51 +08:00
|
|
|
cookieSize = CharUnits::Zero();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
cookieSize = getArrayCookieSizeImpl(eltTy);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address allocAddr =
|
|
|
|
CGF.Builder.CreateConstInBoundsByteGEP(ptr, -cookieSize);
|
|
|
|
allocPtr = allocAddr.getPointer();
|
|
|
|
numElements = readArrayCookieImpl(CGF, allocAddr, cookieSize);
|
2012-05-01 13:23:51 +08:00
|
|
|
}
|
2010-11-29 01:49:03 +08:00
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
llvm::Value *CGCXXABI::readArrayCookieImpl(CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address ptr,
|
2012-05-01 13:23:51 +08:00
|
|
|
CharUnits cookieSize) {
|
|
|
|
ErrorUnsupportedABI(CGF, "reading a new[] cookie");
|
|
|
|
return llvm::ConstantInt::get(CGF.SizeTy, 0);
|
2010-11-29 01:49:03 +08:00
|
|
|
}
|
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
/// Returns the adjustment, in bytes, required for the given
|
|
|
|
/// member-pointer operation. Returns null if no adjustment is
|
|
|
|
/// required.
|
|
|
|
llvm::Constant *CGCXXABI::getMemberPointerAdjustment(const CastExpr *E) {
|
|
|
|
assert(E->getCastKind() == CK_DerivedToBaseMemberPointer ||
|
|
|
|
E->getCastKind() == CK_BaseToDerivedMemberPointer);
|
|
|
|
|
|
|
|
QualType derivedType;
|
|
|
|
if (E->getCastKind() == CK_DerivedToBaseMemberPointer)
|
|
|
|
derivedType = E->getSubExpr()->getType();
|
|
|
|
else
|
|
|
|
derivedType = E->getType();
|
|
|
|
|
|
|
|
const CXXRecordDecl *derivedClass =
|
|
|
|
derivedType->castAs<MemberPointerType>()->getClass()->getAsCXXRecordDecl();
|
|
|
|
|
|
|
|
return CGM.GetNonVirtualBaseClassOffset(derivedClass,
|
|
|
|
E->path_begin(),
|
|
|
|
E->path_end());
|
|
|
|
}
|
2013-02-27 21:46:31 +08:00
|
|
|
|
2013-05-10 05:01:17 +08:00
|
|
|
CharUnits CGCXXABI::getMemberPointerPathAdjustment(const APValue &MP) {
|
|
|
|
// TODO: Store base specifiers in APValue member pointer paths so we can
|
|
|
|
// easily reuse CGM.GetNonVirtualBaseClassOffset().
|
|
|
|
const ValueDecl *MPD = MP.getMemberPointerDecl();
|
|
|
|
CharUnits ThisAdjustment = CharUnits::Zero();
|
|
|
|
ArrayRef<const CXXRecordDecl*> Path = MP.getMemberPointerPath();
|
|
|
|
bool DerivedMember = MP.isMemberPointerToDerivedMember();
|
|
|
|
const CXXRecordDecl *RD = cast<CXXRecordDecl>(MPD->getDeclContext());
|
|
|
|
for (unsigned I = 0, N = Path.size(); I != N; ++I) {
|
|
|
|
const CXXRecordDecl *Base = RD;
|
|
|
|
const CXXRecordDecl *Derived = Path[I];
|
|
|
|
if (DerivedMember)
|
|
|
|
std::swap(Base, Derived);
|
|
|
|
ThisAdjustment +=
|
|
|
|
getContext().getASTRecordLayout(Derived).getBaseClassOffset(Base);
|
|
|
|
RD = Path[I];
|
|
|
|
}
|
|
|
|
if (DerivedMember)
|
|
|
|
ThisAdjustment = -ThisAdjustment;
|
|
|
|
return ThisAdjustment;
|
|
|
|
}
|
|
|
|
|
2013-06-19 23:20:38 +08:00
|
|
|
llvm::BasicBlock *
|
|
|
|
CGCXXABI::EmitCtorCompleteObjectHandler(CodeGenFunction &CGF,
|
|
|
|
const CXXRecordDecl *RD) {
|
2013-02-27 21:46:31 +08:00
|
|
|
if (CGM.getTarget().getCXXABI().hasConstructorVariants())
|
|
|
|
llvm_unreachable("shouldn't be called in this ABI");
|
|
|
|
|
|
|
|
ErrorUnsupportedABI(CGF, "complete object detection in ctor");
|
2014-05-21 13:09:00 +08:00
|
|
|
return nullptr;
|
2013-02-27 21:46:31 +08:00
|
|
|
}
|
2013-04-20 00:42:07 +08:00
|
|
|
|
2013-06-29 04:45:28 +08:00
|
|
|
bool CGCXXABI::NeedsVTTParameter(GlobalDecl GD) {
|
|
|
|
return false;
|
|
|
|
}
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
llvm::CallInst *
|
|
|
|
CGCXXABI::emitTerminateForUnexpectedException(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *Exn) {
|
|
|
|
// Just call std::terminate and ignore the violating exception.
|
|
|
|
return CGF.EmitNounwindRuntimeCall(CGF.CGM.getTerminateFn());
|
|
|
|
}
|
2015-09-17 04:15:55 +08:00
|
|
|
|
|
|
|
CatchTypeInfo CGCXXABI::getCatchAllTypeInfo() {
|
|
|
|
return CatchTypeInfo{nullptr, 0};
|
|
|
|
}
|
2015-11-02 17:01:44 +08:00
|
|
|
|
|
|
|
std::vector<CharUnits> CGCXXABI::getVBPtrOffsets(const CXXRecordDecl *RD) {
|
|
|
|
return std::vector<CharUnits>();
|
|
|
|
}
|