2010-05-26 03:52:27 +08:00
|
|
|
//===------- ItaniumCXXABI.cpp - Emit LLVM Code from ASTs for a Module ----===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-05-26 03:52:27 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2011-04-15 13:22:18 +08:00
|
|
|
// This provides C++ code generation targeting the Itanium C++ ABI. The class
|
2010-05-26 03:52:27 +08:00
|
|
|
// in this file generates structures that follow the Itanium C++ ABI, which is
|
|
|
|
// documented at:
|
|
|
|
// http://www.codesourcery.com/public/cxx-abi/abi.html
|
|
|
|
// http://www.codesourcery.com/public/cxx-abi/abi-eh.html
|
2010-08-22 06:46:04 +08:00
|
|
|
//
|
|
|
|
// It also supports the closely-related ARM ABI, documented at:
|
|
|
|
// http://infocenter.arm.com/help/topic/com.arm.doc.ihi0041c/IHI0041C_cppabi.pdf
|
|
|
|
//
|
2010-05-26 03:52:27 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CGCXXABI.h"
|
2015-03-04 03:21:04 +08:00
|
|
|
#include "CGCleanup.h"
|
2010-08-23 09:21:21 +08:00
|
|
|
#include "CGRecordLayout.h"
|
2012-06-24 07:44:00 +08:00
|
|
|
#include "CGVTables.h"
|
2010-08-22 08:05:51 +08:00
|
|
|
#include "CodeGenFunction.h"
|
2010-05-26 03:52:27 +08:00
|
|
|
#include "CodeGenModule.h"
|
2015-03-04 03:21:04 +08:00
|
|
|
#include "TargetInfo.h"
|
2019-12-10 08:11:56 +08:00
|
|
|
#include "clang/AST/Attr.h"
|
2012-09-16 02:47:51 +08:00
|
|
|
#include "clang/AST/Mangle.h"
|
2015-03-04 03:21:04 +08:00
|
|
|
#include "clang/AST/StmtCXX.h"
|
2019-12-10 08:11:56 +08:00
|
|
|
#include "clang/AST/Type.h"
|
|
|
|
#include "clang/CodeGen/ConstantInitBuilder.h"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2018-07-24 08:43:47 +08:00
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2015-03-04 03:21:04 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
2018-04-18 02:41:52 +08:00
|
|
|
#include "llvm/Support/ScopedPrinter.h"
|
2010-05-26 03:52:27 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
2010-08-22 08:05:51 +08:00
|
|
|
using namespace CodeGen;
|
2010-05-26 03:52:27 +08:00
|
|
|
|
|
|
|
namespace {
|
2010-08-16 11:33:14 +08:00
|
|
|
class ItaniumCXXABI : public CodeGen::CGCXXABI {
|
2013-09-27 22:48:01 +08:00
|
|
|
/// VTables - All the vtables which have been defined.
|
|
|
|
llvm::DenseMap<const CXXRecordDecl *, llvm::GlobalVariable *> VTables;
|
|
|
|
|
2019-09-13 04:00:24 +08:00
|
|
|
/// All the thread wrapper functions that have been used.
|
|
|
|
llvm::SmallVector<std::pair<const VarDecl *, llvm::Function *>, 8>
|
|
|
|
ThreadWrappers;
|
|
|
|
|
2010-08-22 08:05:51 +08:00
|
|
|
protected:
|
2013-07-25 00:25:13 +08:00
|
|
|
bool UseARMMethodPtrABI;
|
|
|
|
bool UseARMGuardVarABI;
|
2016-09-16 10:40:45 +08:00
|
|
|
bool Use32BitVTableOffsetABI;
|
2010-08-23 09:21:21 +08:00
|
|
|
|
2013-10-03 14:26:13 +08:00
|
|
|
ItaniumMangleContext &getMangleContext() {
|
|
|
|
return cast<ItaniumMangleContext>(CodeGen::CGCXXABI::getMangleContext());
|
|
|
|
}
|
|
|
|
|
2010-05-26 03:52:27 +08:00
|
|
|
public:
|
2013-07-25 00:25:13 +08:00
|
|
|
ItaniumCXXABI(CodeGen::CodeGenModule &CGM,
|
|
|
|
bool UseARMMethodPtrABI = false,
|
|
|
|
bool UseARMGuardVarABI = false) :
|
|
|
|
CGCXXABI(CGM), UseARMMethodPtrABI(UseARMMethodPtrABI),
|
2016-09-16 10:40:45 +08:00
|
|
|
UseARMGuardVarABI(UseARMGuardVarABI),
|
2016-12-01 11:04:07 +08:00
|
|
|
Use32BitVTableOffsetABI(false) { }
|
2010-08-22 08:05:51 +08:00
|
|
|
|
2014-05-14 06:05:45 +08:00
|
|
|
bool classifyReturnType(CGFunctionInfo &FI) const override;
|
2013-04-17 20:54:10 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
RecordArgABI getRecordArgABI(const CXXRecordDecl *RD) const override {
|
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
|
|
|
// If C++ prohibits us from making a copy, pass by address.
|
2019-05-01 06:23:20 +08:00
|
|
|
if (!RD->canPassInRegisters())
|
2013-04-17 20:54:10 +08:00
|
|
|
return RAA_Indirect;
|
|
|
|
return RAA_Default;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
bool isThisCompleteObject(GlobalDecl GD) const override {
|
|
|
|
// The Itanium ABI has separate complete-object vs. base-object
|
|
|
|
// variants of both constructors and destructors.
|
|
|
|
if (isa<CXXDestructorDecl>(GD.getDecl())) {
|
|
|
|
switch (GD.getDtorType()) {
|
|
|
|
case Dtor_Complete:
|
|
|
|
case Dtor_Deleting:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case Dtor_Base:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
case Dtor_Comdat:
|
|
|
|
llvm_unreachable("emitting dtor comdat as function?");
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad dtor kind");
|
|
|
|
}
|
|
|
|
if (isa<CXXConstructorDecl>(GD.getDecl())) {
|
|
|
|
switch (GD.getCtorType()) {
|
|
|
|
case Ctor_Complete:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case Ctor_Base:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
case Ctor_CopyingClosure:
|
|
|
|
case Ctor_DefaultClosure:
|
|
|
|
llvm_unreachable("closure ctors in Itanium ABI?");
|
|
|
|
|
|
|
|
case Ctor_Comdat:
|
|
|
|
llvm_unreachable("emitting ctor comdat as function?");
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad dtor kind");
|
|
|
|
}
|
|
|
|
|
|
|
|
// No other kinds.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
bool isZeroInitializable(const MemberPointerType *MPT) override;
|
2010-08-22 12:16:24 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Type *ConvertMemberPointerType(const MemberPointerType *MPT) override;
|
2010-08-23 09:21:21 +08:00
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee
|
2014-03-12 14:41:41 +08:00
|
|
|
EmitLoadOfMemberFunctionPointer(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 This,
|
|
|
|
llvm::Value *&ThisPtrForCall,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *MemFnPtr,
|
|
|
|
const MemberPointerType *MPT) override;
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *
|
|
|
|
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,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *MemPtr,
|
|
|
|
const MemberPointerType *MPT) override;
|
2010-09-01 05:07:20 +08:00
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
llvm::Value *EmitMemberPointerConversion(CodeGenFunction &CGF,
|
|
|
|
const CastExpr *E,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *Src) override;
|
2012-02-15 09:22:51 +08:00
|
|
|
llvm::Constant *EmitMemberPointerConversion(const CastExpr *E,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Constant *Src) override;
|
2010-08-22 12:16:24 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Constant *EmitNullMemberPointer(const MemberPointerType *MPT) override;
|
2010-08-22 12:16:24 +08:00
|
|
|
|
2015-06-23 15:31:01 +08:00
|
|
|
llvm::Constant *EmitMemberFunctionPointer(const CXXMethodDecl *MD) override;
|
2011-02-03 16:15:49 +08:00
|
|
|
llvm::Constant *EmitMemberDataPointer(const MemberPointerType *MPT,
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits offset) override;
|
|
|
|
llvm::Constant *EmitMemberPointer(const APValue &MP, QualType MPT) override;
|
2012-01-14 12:30:29 +08:00
|
|
|
llvm::Constant *BuildMemberPointer(const CXXMethodDecl *MD,
|
|
|
|
CharUnits ThisAdjustment);
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
llvm::Value *EmitMemberPointerComparison(CodeGenFunction &CGF,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *L, llvm::Value *R,
|
2010-08-23 09:21:21 +08:00
|
|
|
const MemberPointerType *MPT,
|
2014-03-12 14:41:41 +08:00
|
|
|
bool Inequality) override;
|
2010-08-22 16:30:07 +08:00
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
llvm::Value *EmitMemberPointerIsNotNull(CodeGenFunction &CGF,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *Addr,
|
|
|
|
const MemberPointerType *MPT) override;
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-11-01 15:37:17 +08:00
|
|
|
void emitVirtualObjectDelete(CodeGenFunction &CGF, const CXXDeleteExpr *DE,
|
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, QualType ElementType,
|
2014-11-01 04:09:12 +08:00
|
|
|
const CXXDestructorDecl *Dtor) override;
|
2012-09-25 18:10:39 +08:00
|
|
|
|
2014-11-25 15:20:20 +08:00
|
|
|
void emitRethrow(CodeGenFunction &CGF, bool isNoReturn) override;
|
2015-03-05 08:46:22 +08:00
|
|
|
void emitThrow(CodeGenFunction &CGF, const CXXThrowExpr *E) override;
|
2014-11-25 15:20:20 +08:00
|
|
|
|
2015-03-04 03:21:04 +08:00
|
|
|
void emitBeginCatch(CodeGenFunction &CGF, const CXXCatchStmt *C) override;
|
|
|
|
|
|
|
|
llvm::CallInst *
|
|
|
|
emitTerminateForUnexpectedException(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *Exn) override;
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
void EmitFundamentalRTTIDescriptors(const CXXRecordDecl *RD);
|
2015-03-18 04:35:00 +08:00
|
|
|
llvm::Constant *getAddrOfRTTIDescriptor(QualType Ty) override;
|
2015-09-17 04:15:55 +08:00
|
|
|
CatchTypeInfo
|
2015-03-30 05:55:10 +08:00
|
|
|
getAddrOfCXXCatchHandlerType(QualType Ty,
|
|
|
|
QualType CatchHandlerType) override {
|
2015-09-17 04:15:55 +08:00
|
|
|
return CatchTypeInfo{getAddrOfRTTIDescriptor(Ty), 0};
|
2015-03-18 04:35:00 +08:00
|
|
|
}
|
2014-07-07 14:20:47 +08:00
|
|
|
|
2014-06-23 03:05:33 +08:00
|
|
|
bool shouldTypeidBeNullChecked(bool IsDeref, QualType SrcRecordTy) override;
|
|
|
|
void EmitBadTypeidCall(CodeGenFunction &CGF) override;
|
|
|
|
llvm::Value *EmitTypeid(CodeGenFunction &CGF, QualType SrcRecordTy,
|
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 ThisPtr,
|
2014-06-23 03:05:33 +08:00
|
|
|
llvm::Type *StdTypeInfoPtrTy) override;
|
|
|
|
|
|
|
|
bool shouldDynamicCastCallBeNullChecked(bool SrcIsPtr,
|
|
|
|
QualType SrcRecordTy) override;
|
|
|
|
|
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::Value *EmitDynamicCastCall(CodeGenFunction &CGF, Address Value,
|
2014-06-23 03:05:33 +08:00
|
|
|
QualType SrcRecordTy, QualType DestTy,
|
|
|
|
QualType DestRecordTy,
|
|
|
|
llvm::BasicBlock *CastEnd) override;
|
|
|
|
|
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::Value *EmitDynamicCastToVoid(CodeGenFunction &CGF, Address Value,
|
2014-06-23 03:05:33 +08:00
|
|
|
QualType SrcRecordTy,
|
|
|
|
QualType DestTy) override;
|
|
|
|
|
|
|
|
bool EmitBadCastCall(CodeGenFunction &CGF) override;
|
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::Value *
|
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
|
|
|
GetVirtualBaseClassOffset(CodeGenFunction &CGF, Address This,
|
2014-03-12 14:41:41 +08:00
|
|
|
const CXXRecordDecl *ClassDecl,
|
|
|
|
const CXXRecordDecl *BaseClassDecl) override;
|
2013-05-30 02:02:47 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void EmitCXXConstructors(const CXXConstructorDecl *D) override;
|
2013-08-05 01:30:04 +08:00
|
|
|
|
2017-02-23 04:28:02 +08:00
|
|
|
AddedStructorArgs
|
2019-03-23 07:05:10 +08:00
|
|
|
buildStructorSignature(GlobalDecl GD,
|
2017-02-23 04:28:02 +08:00
|
|
|
SmallVectorImpl<CanQualType> &ArgTys) override;
|
2010-08-31 15:33:07 +08:00
|
|
|
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
bool useThunkForDtorVariant(const CXXDestructorDecl *Dtor,
|
2014-03-12 14:41:41 +08:00
|
|
|
CXXDtorType DT) const override {
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
// Itanium does not emit any destructor variant as an inline thunk.
|
|
|
|
// Delegating may occur as an optimization, but all variants are either
|
|
|
|
// emitted with external linkage or as linkonce if they are inline and used.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void EmitCXXDestructors(const CXXDestructorDecl *D) override;
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
void addImplicitStructorParams(CodeGenFunction &CGF, QualType &ResTy,
|
2014-03-12 14:41:41 +08:00
|
|
|
FunctionArgList &Params) override;
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void EmitInstanceFunctionProlog(CodeGenFunction &CGF) override;
|
2010-09-02 17:58:18 +08:00
|
|
|
|
2017-02-23 04:28:02 +08:00
|
|
|
AddedStructorArgs
|
|
|
|
addImplicitConstructorArgs(CodeGenFunction &CGF, const CXXConstructorDecl *D,
|
|
|
|
CXXCtorType Type, bool ForVirtualBase,
|
|
|
|
bool Delegating, CallArgList &Args) override;
|
2013-06-20 02:10:35 +08:00
|
|
|
|
2013-12-13 08:53:54 +08:00
|
|
|
void EmitDestructorCall(CodeGenFunction &CGF, const CXXDestructorDecl *DD,
|
|
|
|
CXXDtorType Type, bool ForVirtualBase,
|
2019-07-22 17:39:13 +08:00
|
|
|
bool Delegating, Address This,
|
|
|
|
QualType ThisTy) override;
|
2013-12-13 08:53:54 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void emitVTableDefinitions(CodeGenVTables &CGVT,
|
|
|
|
const CXXRecordDecl *RD) override;
|
2013-09-27 22:48:01 +08:00
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
bool isVirtualOffsetNeededForVTableField(CodeGenFunction &CGF,
|
|
|
|
CodeGenFunction::VPtr Vptr) override;
|
|
|
|
|
|
|
|
bool doStructorsInitializeVPtrs(const CXXRecordDecl *VTableClass) override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *
|
|
|
|
getVTableAddressPoint(BaseSubobject Base,
|
|
|
|
const CXXRecordDecl *VTableClass) override;
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
llvm::Value *getVTableAddressPointInStructor(
|
|
|
|
CodeGenFunction &CGF, const CXXRecordDecl *VTableClass,
|
2015-09-15 08:37:06 +08:00
|
|
|
BaseSubobject Base, const CXXRecordDecl *NearestVBase) override;
|
|
|
|
|
|
|
|
llvm::Value *getVTableAddressPointInStructorWithVTT(
|
|
|
|
CodeGenFunction &CGF, const CXXRecordDecl *VTableClass,
|
|
|
|
BaseSubobject Base, const CXXRecordDecl *NearestVBase);
|
2013-09-27 22:48:01 +08:00
|
|
|
|
|
|
|
llvm::Constant *
|
|
|
|
getVTableAddressPointForConstExpr(BaseSubobject Base,
|
2014-03-12 14:41:41 +08:00
|
|
|
const CXXRecordDecl *VTableClass) override;
|
2013-09-27 22:48:01 +08:00
|
|
|
|
|
|
|
llvm::GlobalVariable *getAddrOfVTable(const CXXRecordDecl *RD,
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits VPtrOffset) override;
|
2013-09-27 22:48:01 +08:00
|
|
|
|
2018-02-07 02:52:44 +08:00
|
|
|
CGCallee getVirtualFunctionPointer(CodeGenFunction &CGF, GlobalDecl GD,
|
|
|
|
Address This, llvm::Type *Ty,
|
|
|
|
SourceLocation Loc) override;
|
2013-08-21 14:25:03 +08:00
|
|
|
|
2014-11-01 04:09:12 +08:00
|
|
|
llvm::Value *EmitVirtualDestructorCall(CodeGenFunction &CGF,
|
|
|
|
const CXXDestructorDecl *Dtor,
|
2019-07-22 17:39:13 +08:00
|
|
|
CXXDtorType DtorType, Address This,
|
|
|
|
DeleteOrMemberCallExpr E) override;
|
2013-02-15 22:45:22 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void emitVirtualInheritanceTables(const CXXRecordDecl *RD) override;
|
2013-06-19 23:20:38 +08:00
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
bool canSpeculativelyEmitVTable(const CXXRecordDecl *RD) const override;
|
2018-11-28 03:33:49 +08:00
|
|
|
bool canSpeculativelyEmitVTableAsBaseClass(const CXXRecordDecl *RD) const;
|
2015-07-24 12:04:49 +08:00
|
|
|
|
2014-06-07 04:04:01 +08:00
|
|
|
void setThunkLinkage(llvm::Function *Thunk, bool ForVTable, GlobalDecl GD,
|
|
|
|
bool ReturnAdjustment) override {
|
2013-10-09 17:23:58 +08:00
|
|
|
// Allow inlining of thunks by emitting them with available_externally
|
|
|
|
// linkage together with vtables when needed.
|
2015-07-01 10:10:26 +08:00
|
|
|
if (ForVTable && !Thunk->hasLocalLinkage())
|
2013-10-09 17:23:58 +08:00
|
|
|
Thunk->setLinkage(llvm::GlobalValue::AvailableExternallyLinkage);
|
2018-03-01 08:35:47 +08:00
|
|
|
CGM.setGVProperties(Thunk, GD);
|
2013-10-09 17:23:58 +08:00
|
|
|
}
|
|
|
|
|
2018-03-01 08:35:47 +08:00
|
|
|
bool exportThunk() override { return true; }
|
|
|
|
|
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::Value *performThisAdjustment(CodeGenFunction &CGF, Address This,
|
2014-03-12 14:41:41 +08:00
|
|
|
const ThisAdjustment &TA) override;
|
2013-10-30 19:55:43 +08:00
|
|
|
|
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::Value *performReturnAdjustment(CodeGenFunction &CGF, Address Ret,
|
2014-03-12 14:41:41 +08:00
|
|
|
const ReturnAdjustment &RA) override;
|
2013-10-30 19:55:43 +08:00
|
|
|
|
2014-09-12 07:05:02 +08:00
|
|
|
size_t getSrcArgforCopyCtor(const CXXConstructorDecl *,
|
|
|
|
FunctionArgList &Args) const override {
|
|
|
|
assert(!Args.empty() && "expected the arglist to not be empty!");
|
|
|
|
return Args.size() - 1;
|
|
|
|
}
|
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
StringRef GetPureVirtualCallName() override { return "__cxa_pure_virtual"; }
|
|
|
|
StringRef GetDeletedVirtualCallName() override
|
|
|
|
{ return "__cxa_deleted_virtual"; }
|
2012-07-18 01:10:11 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits getArrayCookieSizeImpl(QualType elementType) override;
|
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 InitializeArrayCookie(CodeGenFunction &CGF,
|
|
|
|
Address NewPtr,
|
|
|
|
llvm::Value *NumElements,
|
|
|
|
const CXXNewExpr *expr,
|
|
|
|
QualType ElementType) override;
|
2012-05-01 13:23:51 +08:00
|
|
|
llvm::Value *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 allocPtr,
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits cookieSize) override;
|
2010-09-08 09:44:27 +08:00
|
|
|
|
2010-11-06 17:44:32 +08:00
|
|
|
void EmitGuardedInit(CodeGenFunction &CGF, const VarDecl &D,
|
2014-03-12 14:41:41 +08:00
|
|
|
llvm::GlobalVariable *DeclPtr,
|
|
|
|
bool PerformInit) override;
|
2013-04-15 07:01:42 +08:00
|
|
|
void registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
|
2019-02-07 09:14:17 +08:00
|
|
|
llvm::FunctionCallee dtor,
|
|
|
|
llvm::Constant *addr) override;
|
2013-04-20 00:42:07 +08:00
|
|
|
|
|
|
|
llvm::Function *getOrCreateThreadLocalWrapper(const VarDecl *VD,
|
2014-09-26 14:28:25 +08:00
|
|
|
llvm::Value *Val);
|
2013-04-20 00:42:07 +08:00
|
|
|
void EmitThreadLocalInitFuncs(
|
2014-10-05 13:05:40 +08:00
|
|
|
CodeGenModule &CGM,
|
2015-12-01 09:10:48 +08:00
|
|
|
ArrayRef<const VarDecl *> CXXThreadLocals,
|
2014-10-05 13:05:40 +08:00
|
|
|
ArrayRef<llvm::Function *> CXXThreadLocalInits,
|
2015-12-01 09:10:48 +08:00
|
|
|
ArrayRef<const VarDecl *> CXXThreadLocalInitVars) override;
|
2014-10-05 13:05:40 +08:00
|
|
|
|
2019-09-13 04:00:24 +08:00
|
|
|
/// Determine whether we will definitely emit this variable with a constant
|
|
|
|
/// initializer, either because the language semantics demand it or because
|
|
|
|
/// we know that the initializer is a constant.
|
|
|
|
bool isEmittedWithConstantInitializer(const VarDecl *VD) const {
|
|
|
|
VD = VD->getMostRecentDecl();
|
|
|
|
if (VD->hasAttr<ConstInitAttr>())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// All later checks examine the initializer specified on the variable. If
|
|
|
|
// the variable is weak, such examination would not be correct.
|
|
|
|
if (VD->isWeak() || VD->hasAttr<SelectAnyAttr>())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
const VarDecl *InitDecl = VD->getInitializingDeclaration();
|
|
|
|
if (!InitDecl)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If there's no initializer to run, this is constant initialization.
|
|
|
|
if (!InitDecl->hasInit())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If we have the only definition, we don't need a thread wrapper if we
|
|
|
|
// will emit the value as a constant.
|
|
|
|
if (isUniqueGVALinkage(getContext().GetGVALinkageForVariable(VD)))
|
2019-09-29 13:08:46 +08:00
|
|
|
return !VD->needsDestruction(getContext()) && InitDecl->evaluateValue();
|
2019-09-13 04:00:24 +08:00
|
|
|
|
|
|
|
// Otherwise, we need a thread wrapper unless we know that every
|
|
|
|
// translation unit will emit the value as a constant. We rely on
|
|
|
|
// ICE-ness not varying between translation units, which isn't actually
|
|
|
|
// guaranteed by the standard but is necessary for sanity.
|
|
|
|
return InitDecl->isInitKnownICE() && InitDecl->isInitICE();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool usesThreadWrapperFunction(const VarDecl *VD) const override {
|
2019-10-01 09:23:23 +08:00
|
|
|
return !isEmittedWithConstantInitializer(VD) ||
|
|
|
|
VD->needsDestruction(getContext());
|
2019-09-13 04:00:24 +08:00
|
|
|
}
|
2014-03-27 06:48:22 +08:00
|
|
|
LValue EmitThreadLocalVarDeclLValue(CodeGenFunction &CGF, const VarDecl *VD,
|
|
|
|
QualType LValType) override;
|
2013-06-29 04:45:28 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
bool NeedsVTTParameter(GlobalDecl GD) override;
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
/**************************** RTTI Uniqueness ******************************/
|
|
|
|
|
|
|
|
protected:
|
|
|
|
/// Returns true if the ABI requires RTTI type_info objects to be unique
|
|
|
|
/// across a program.
|
|
|
|
virtual bool shouldRTTIBeUnique() const { return true; }
|
|
|
|
|
|
|
|
public:
|
|
|
|
/// What sort of unique-RTTI behavior should we use?
|
|
|
|
enum RTTIUniquenessKind {
|
|
|
|
/// We are guaranteeing, or need to guarantee, that the RTTI string
|
|
|
|
/// is unique.
|
|
|
|
RUK_Unique,
|
|
|
|
|
|
|
|
/// We are not guaranteeing uniqueness for the RTTI string, so we
|
|
|
|
/// can demote to hidden visibility but must use string comparisons.
|
|
|
|
RUK_NonUniqueHidden,
|
|
|
|
|
|
|
|
/// We are not guaranteeing uniqueness for the RTTI string, so we
|
|
|
|
/// have to use string comparisons, but we also have to emit it with
|
|
|
|
/// non-hidden visibility.
|
|
|
|
RUK_NonUniqueVisible
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Return the required visibility status for the given type and linkage in
|
|
|
|
/// the current ABI.
|
|
|
|
RTTIUniquenessKind
|
|
|
|
classifyRTTIUniqueness(QualType CanTy,
|
|
|
|
llvm::GlobalValue::LinkageTypes Linkage) const;
|
|
|
|
friend class ItaniumRTTIBuilder;
|
2014-09-16 03:20:10 +08:00
|
|
|
|
2019-03-23 07:05:10 +08:00
|
|
|
void emitCXXStructor(GlobalDecl GD) override;
|
2015-07-24 12:04:49 +08:00
|
|
|
|
2017-12-14 05:53:04 +08:00
|
|
|
std::pair<llvm::Value *, const CXXRecordDecl *>
|
|
|
|
LoadVTablePtr(CodeGenFunction &CGF, Address This,
|
|
|
|
const CXXRecordDecl *RD) override;
|
|
|
|
|
2015-07-24 12:04:49 +08:00
|
|
|
private:
|
2017-06-01 16:04:05 +08:00
|
|
|
bool hasAnyUnusedVirtualInlineFunction(const CXXRecordDecl *RD) const {
|
|
|
|
const auto &VtableLayout =
|
|
|
|
CGM.getItaniumVTableContext().getVTableLayout(RD);
|
|
|
|
|
|
|
|
for (const auto &VtableComponent : VtableLayout.vtable_components()) {
|
|
|
|
// Skip empty slot.
|
|
|
|
if (!VtableComponent.isUsedFunctionPointerKind())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
const CXXMethodDecl *Method = VtableComponent.getFunctionDecl();
|
|
|
|
if (!Method->getCanonicalDecl()->isInlined())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
StringRef Name = CGM.getMangledName(VtableComponent.getGlobalDecl());
|
|
|
|
auto *Entry = CGM.GetGlobalValue(Name);
|
|
|
|
// This checks if virtual inline function has already been emitted.
|
|
|
|
// Note that it is possible that this inline function would be emitted
|
|
|
|
// after trying to emit vtable speculatively. Because of this we do
|
|
|
|
// an extra pass after emitting all deferred vtables to find and emit
|
|
|
|
// these vtables opportunistically.
|
|
|
|
if (!Entry || Entry->isDeclaration())
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2015-07-24 12:04:49 +08:00
|
|
|
}
|
2015-09-15 08:37:06 +08:00
|
|
|
|
|
|
|
bool isVTableHidden(const CXXRecordDecl *RD) const {
|
|
|
|
const auto &VtableLayout =
|
|
|
|
CGM.getItaniumVTableContext().getVTableLayout(RD);
|
|
|
|
|
|
|
|
for (const auto &VtableComponent : VtableLayout.vtable_components()) {
|
|
|
|
if (VtableComponent.isRTTIKind()) {
|
|
|
|
const CXXRecordDecl *RTTIDecl = VtableComponent.getRTTIDecl();
|
|
|
|
if (RTTIDecl->getVisibility() == Visibility::HiddenVisibility)
|
|
|
|
return true;
|
|
|
|
} else if (VtableComponent.isUsedFunctionPointerKind()) {
|
|
|
|
const CXXMethodDecl *Method = VtableComponent.getFunctionDecl();
|
|
|
|
if (Method->getVisibility() == Visibility::HiddenVisibility &&
|
|
|
|
!Method->isDefined())
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2010-05-26 03:52:27 +08:00
|
|
|
};
|
2010-08-22 06:46:04 +08:00
|
|
|
|
|
|
|
class ARMCXXABI : public ItaniumCXXABI {
|
|
|
|
public:
|
2013-07-25 00:25:13 +08:00
|
|
|
ARMCXXABI(CodeGen::CodeGenModule &CGM) :
|
2019-07-19 08:30:23 +08:00
|
|
|
ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true,
|
|
|
|
/*UseARMGuardVarABI=*/true) {}
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
bool HasThisReturn(GlobalDecl GD) const override {
|
2013-07-01 04:40:16 +08:00
|
|
|
return (isa<CXXConstructorDecl>(GD.getDecl()) || (
|
|
|
|
isa<CXXDestructorDecl>(GD.getDecl()) &&
|
|
|
|
GD.getDtorType() != Dtor_Deleting));
|
|
|
|
}
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void EmitReturnFromThunk(CodeGenFunction &CGF, RValue RV,
|
|
|
|
QualType ResTy) override;
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits getArrayCookieSizeImpl(QualType elementType) override;
|
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 InitializeArrayCookie(CodeGenFunction &CGF,
|
|
|
|
Address NewPtr,
|
|
|
|
llvm::Value *NumElements,
|
|
|
|
const CXXNewExpr *expr,
|
|
|
|
QualType ElementType) override;
|
|
|
|
llvm::Value *readArrayCookieImpl(CodeGenFunction &CGF, Address allocPtr,
|
2014-03-12 14:41:41 +08:00
|
|
|
CharUnits cookieSize) override;
|
2010-08-22 06:46:04 +08:00
|
|
|
};
|
2014-03-29 23:09:45 +08:00
|
|
|
|
|
|
|
class iOS64CXXABI : public ARMCXXABI {
|
|
|
|
public:
|
2016-09-16 10:40:45 +08:00
|
|
|
iOS64CXXABI(CodeGen::CodeGenModule &CGM) : ARMCXXABI(CGM) {
|
|
|
|
Use32BitVTableOffsetABI = true;
|
|
|
|
}
|
2014-03-31 01:32:48 +08:00
|
|
|
|
|
|
|
// ARM64 libraries are prepared for non-unique RTTI.
|
2014-07-07 14:20:47 +08:00
|
|
|
bool shouldRTTIBeUnique() const override { return false; }
|
2014-03-29 23:09:45 +08:00
|
|
|
};
|
2015-09-04 06:51:53 +08:00
|
|
|
|
2019-09-07 09:59:43 +08:00
|
|
|
class FuchsiaCXXABI final : public ItaniumCXXABI {
|
|
|
|
public:
|
|
|
|
explicit FuchsiaCXXABI(CodeGen::CodeGenModule &CGM)
|
|
|
|
: ItaniumCXXABI(CGM) {}
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool HasThisReturn(GlobalDecl GD) const override {
|
|
|
|
return isa<CXXConstructorDecl>(GD.getDecl()) ||
|
|
|
|
(isa<CXXDestructorDecl>(GD.getDecl()) &&
|
|
|
|
GD.getDtorType() != Dtor_Deleting);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-09-04 06:51:53 +08:00
|
|
|
class WebAssemblyCXXABI final : public ItaniumCXXABI {
|
|
|
|
public:
|
|
|
|
explicit WebAssemblyCXXABI(CodeGen::CodeGenModule &CGM)
|
|
|
|
: ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true,
|
|
|
|
/*UseARMGuardVarABI=*/true) {}
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
void emitBeginCatch(CodeGenFunction &CGF, const CXXCatchStmt *C) override;
|
2015-09-04 06:51:53 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
bool HasThisReturn(GlobalDecl GD) const override {
|
|
|
|
return isa<CXXConstructorDecl>(GD.getDecl()) ||
|
|
|
|
(isa<CXXDestructorDecl>(GD.getDecl()) &&
|
|
|
|
GD.getDtorType() != Dtor_Deleting);
|
|
|
|
}
|
2016-05-11 01:44:55 +08:00
|
|
|
bool canCallMismatchedFunctionType() const override { return false; }
|
2015-09-04 06:51:53 +08:00
|
|
|
};
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
2010-05-26 03:52:27 +08:00
|
|
|
|
2010-08-16 11:33:14 +08:00
|
|
|
CodeGen::CGCXXABI *CodeGen::CreateItaniumCXXABI(CodeGenModule &CGM) {
|
2013-04-17 06:48:15 +08:00
|
|
|
switch (CGM.getTarget().getCXXABI().getKind()) {
|
2013-01-26 07:36:14 +08:00
|
|
|
// For IR-generation purposes, there's no significant difference
|
|
|
|
// between the ARM and iOS ABIs.
|
|
|
|
case TargetCXXABI::GenericARM:
|
|
|
|
case TargetCXXABI::iOS:
|
2015-10-31 00:30:36 +08:00
|
|
|
case TargetCXXABI::WatchOS:
|
2013-01-26 07:36:14 +08:00
|
|
|
return new ARMCXXABI(CGM);
|
|
|
|
|
2014-03-29 23:09:45 +08:00
|
|
|
case TargetCXXABI::iOS64:
|
|
|
|
return new iOS64CXXABI(CGM);
|
|
|
|
|
2019-09-07 09:59:43 +08:00
|
|
|
case TargetCXXABI::Fuchsia:
|
|
|
|
return new FuchsiaCXXABI(CGM);
|
|
|
|
|
2013-01-31 20:13:10 +08:00
|
|
|
// Note that AArch64 uses the generic ItaniumCXXABI class since it doesn't
|
|
|
|
// include the other 32-bit ARM oddities: constructor/destructor return values
|
|
|
|
// and array cookies.
|
|
|
|
case TargetCXXABI::GenericAArch64:
|
2019-07-19 08:30:23 +08:00
|
|
|
return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true,
|
|
|
|
/*UseARMGuardVarABI=*/true);
|
2013-01-31 20:13:10 +08:00
|
|
|
|
2015-02-18 23:21:35 +08:00
|
|
|
case TargetCXXABI::GenericMIPS:
|
2019-07-19 08:30:23 +08:00
|
|
|
return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true);
|
2015-02-18 23:21:35 +08:00
|
|
|
|
2015-09-04 06:51:53 +08:00
|
|
|
case TargetCXXABI::WebAssembly:
|
|
|
|
return new WebAssemblyCXXABI(CGM);
|
|
|
|
|
2013-01-26 07:36:14 +08:00
|
|
|
case TargetCXXABI::GenericItanium:
|
2013-07-25 00:25:13 +08:00
|
|
|
if (CGM.getContext().getTargetInfo().getTriple().getArch()
|
|
|
|
== llvm::Triple::le32) {
|
|
|
|
// For PNaCl, use ARM-style method pointers so that PNaCl code
|
|
|
|
// does not assume anything about the alignment of function
|
|
|
|
// pointers.
|
2019-07-19 08:30:23 +08:00
|
|
|
return new ItaniumCXXABI(CGM, /*UseARMMethodPtrABI=*/true);
|
2013-07-25 00:25:13 +08:00
|
|
|
}
|
2013-01-26 07:36:14 +08:00
|
|
|
return new ItaniumCXXABI(CGM);
|
|
|
|
|
|
|
|
case TargetCXXABI::Microsoft:
|
|
|
|
llvm_unreachable("Microsoft ABI is not Itanium-based");
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad ABI kind");
|
2010-08-22 06:46:04 +08:00
|
|
|
}
|
|
|
|
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::Type *
|
2010-08-23 09:21:21 +08:00
|
|
|
ItaniumCXXABI::ConvertMemberPointerType(const MemberPointerType *MPT) {
|
|
|
|
if (MPT->isMemberDataPointer())
|
2013-03-23 00:13:10 +08:00
|
|
|
return CGM.PtrDiffTy;
|
2017-05-10 03:31:30 +08:00
|
|
|
return llvm::StructType::get(CGM.PtrDiffTy, CGM.PtrDiffTy);
|
2010-08-22 14:43:33 +08:00
|
|
|
}
|
|
|
|
|
2010-08-22 08:59:17 +08:00
|
|
|
/// In the Itanium and ARM ABIs, method pointers have the form:
|
|
|
|
/// struct { ptrdiff_t ptr; ptrdiff_t adj; } memptr;
|
|
|
|
///
|
|
|
|
/// In the Itanium ABI:
|
|
|
|
/// - method pointers are virtual if (memptr.ptr & 1) is nonzero
|
|
|
|
/// - the this-adjustment is (memptr.adj)
|
|
|
|
/// - the virtual offset is (memptr.ptr - 1)
|
|
|
|
///
|
|
|
|
/// In the ARM ABI:
|
|
|
|
/// - method pointers are virtual if (memptr.adj & 1) is nonzero
|
|
|
|
/// - the this-adjustment is (memptr.adj >> 1)
|
|
|
|
/// - the virtual offset is (memptr.ptr)
|
|
|
|
/// ARM uses 'adj' for the virtual flag because Thumb functions
|
|
|
|
/// may be only single-byte aligned.
|
|
|
|
///
|
|
|
|
/// If the member is virtual, the adjusted 'this' pointer points
|
|
|
|
/// to a vtable pointer from which the virtual offset is applied.
|
|
|
|
///
|
|
|
|
/// If the member is non-virtual, memptr.ptr is the address of
|
|
|
|
/// the function to call.
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee ItaniumCXXABI::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 ThisAddr,
|
|
|
|
llvm::Value *&ThisPtrForCall,
|
2014-02-21 07:22:07 +08:00
|
|
|
llvm::Value *MemFnPtr, const MemberPointerType *MPT) {
|
2010-08-22 08:05:51 +08:00
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
|
|
|
|
2017-11-11 09:15:41 +08:00
|
|
|
const FunctionProtoType *FPT =
|
2010-08-22 08:05:51 +08:00
|
|
|
MPT->getPointeeType()->getAs<FunctionProtoType>();
|
2019-10-03 04:45:16 +08:00
|
|
|
auto *RD =
|
|
|
|
cast<CXXRecordDecl>(MPT->getClass()->castAs<RecordType>()->getDecl());
|
2010-08-22 08:05:51 +08:00
|
|
|
|
2015-12-03 05:58:08 +08:00
|
|
|
llvm::FunctionType *FTy = CGM.getTypes().GetFunctionType(
|
|
|
|
CGM.getTypes().arrangeCXXMethodType(RD, FPT, /*FD=*/nullptr));
|
2010-08-22 08:05:51 +08:00
|
|
|
|
2013-03-23 00:13:10 +08:00
|
|
|
llvm::Constant *ptrdiff_1 = llvm::ConstantInt::get(CGM.PtrDiffTy, 1);
|
2010-08-22 08:05:51 +08:00
|
|
|
|
2010-08-22 08:59:17 +08:00
|
|
|
llvm::BasicBlock *FnVirtual = CGF.createBasicBlock("memptr.virtual");
|
|
|
|
llvm::BasicBlock *FnNonVirtual = CGF.createBasicBlock("memptr.nonvirtual");
|
|
|
|
llvm::BasicBlock *FnEnd = CGF.createBasicBlock("memptr.end");
|
|
|
|
|
2010-08-22 18:59:02 +08:00
|
|
|
// Extract memptr.adj, which is in the second field.
|
|
|
|
llvm::Value *RawAdj = Builder.CreateExtractValue(MemFnPtr, 1, "memptr.adj");
|
2010-08-22 08:59:17 +08:00
|
|
|
|
|
|
|
// Compute the true adjustment.
|
|
|
|
llvm::Value *Adj = RawAdj;
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI)
|
2010-08-22 08:59:17 +08:00
|
|
|
Adj = Builder.CreateAShr(Adj, ptrdiff_1, "memptr.adj.shifted");
|
2010-08-22 08:05:51 +08:00
|
|
|
|
|
|
|
// Apply the adjustment and cast back to the original struct type
|
|
|
|
// for consistency.
|
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::Value *This = ThisAddr.getPointer();
|
2010-08-22 08:59:17 +08:00
|
|
|
llvm::Value *Ptr = Builder.CreateBitCast(This, Builder.getInt8PtrTy());
|
|
|
|
Ptr = Builder.CreateInBoundsGEP(Ptr, Adj);
|
|
|
|
This = Builder.CreateBitCast(Ptr, This->getType(), "this.adjusted");
|
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;
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-08-22 08:05:51 +08:00
|
|
|
// Load the function pointer.
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Value *FnAsInt = Builder.CreateExtractValue(MemFnPtr, 0, "memptr.ptr");
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-08-22 08:05:51 +08:00
|
|
|
// If the LSB in the function pointer is 1, the function pointer points to
|
|
|
|
// a virtual function.
|
2010-08-22 08:59:17 +08:00
|
|
|
llvm::Value *IsVirtual;
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI)
|
2010-08-22 08:59:17 +08:00
|
|
|
IsVirtual = Builder.CreateAnd(RawAdj, ptrdiff_1);
|
|
|
|
else
|
|
|
|
IsVirtual = Builder.CreateAnd(FnAsInt, ptrdiff_1);
|
|
|
|
IsVirtual = Builder.CreateIsNotNull(IsVirtual, "memptr.isvirtual");
|
2010-08-22 08:05:51 +08:00
|
|
|
Builder.CreateCondBr(IsVirtual, FnVirtual, FnNonVirtual);
|
|
|
|
|
|
|
|
// In the virtual path, the adjustment left 'This' pointing to the
|
|
|
|
// vtable of the correct base subobject. The "function pointer" is an
|
2010-08-22 08:59:17 +08:00
|
|
|
// offset within the vtable (+1 for the virtual flag on non-ARM).
|
2010-08-22 08:05:51 +08:00
|
|
|
CGF.EmitBlock(FnVirtual);
|
|
|
|
|
|
|
|
// Cast the adjusted this to a pointer to vtable pointer and load.
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::Type *VTableTy = Builder.getInt8PtrTy();
|
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
|
|
|
CharUnits VTablePtrAlign =
|
|
|
|
CGF.CGM.getDynamicOffsetAlignment(ThisAddr.getAlignment(), RD,
|
|
|
|
CGF.getPointerAlign());
|
|
|
|
llvm::Value *VTable =
|
2015-09-16 05:46:55 +08:00
|
|
|
CGF.GetVTablePtr(Address(This, VTablePtrAlign), VTableTy, RD);
|
2010-08-22 08:05:51 +08:00
|
|
|
|
|
|
|
// Apply the offset.
|
2016-09-16 10:40:45 +08:00
|
|
|
// On ARM64, to reserve extra space in virtual member function pointers,
|
|
|
|
// we only pay attention to the low 32 bits of the offset.
|
2010-08-22 08:59:17 +08:00
|
|
|
llvm::Value *VTableOffset = FnAsInt;
|
2013-07-25 00:25:13 +08:00
|
|
|
if (!UseARMMethodPtrABI)
|
|
|
|
VTableOffset = Builder.CreateSub(VTableOffset, ptrdiff_1);
|
2016-09-16 10:40:45 +08:00
|
|
|
if (Use32BitVTableOffsetABI) {
|
|
|
|
VTableOffset = Builder.CreateTrunc(VTableOffset, CGF.Int32Ty);
|
|
|
|
VTableOffset = Builder.CreateZExt(VTableOffset, CGM.PtrDiffTy);
|
|
|
|
}
|
2018-06-26 10:15:47 +08:00
|
|
|
|
|
|
|
// Check the address of the function pointer if CFI on member function
|
|
|
|
// pointers is enabled.
|
|
|
|
llvm::Constant *CheckSourceLocation;
|
|
|
|
llvm::Constant *CheckTypeDesc;
|
|
|
|
bool ShouldEmitCFICheck = CGF.SanOpts.has(SanitizerKind::CFIMFCall) &&
|
|
|
|
CGM.HasHiddenLTOVisibility(RD);
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
bool ShouldEmitVFEInfo = CGM.getCodeGenOpts().VirtualFunctionElimination &&
|
|
|
|
CGM.HasHiddenLTOVisibility(RD);
|
2020-01-25 04:24:18 +08:00
|
|
|
bool ShouldEmitWPDInfo =
|
|
|
|
CGM.getCodeGenOpts().WholeProgramVTables &&
|
|
|
|
// Don't insert type tests if we are forcing public std visibility.
|
|
|
|
!CGM.HasLTOVisibilityPublicStd(RD);
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
llvm::Value *VirtualFn = nullptr;
|
2019-10-15 07:25:25 +08:00
|
|
|
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
{
|
|
|
|
CodeGenFunction::SanitizerScope SanScope(&CGF);
|
|
|
|
llvm::Value *TypeId = nullptr;
|
|
|
|
llvm::Value *CheckResult = nullptr;
|
|
|
|
|
2020-01-25 04:24:18 +08:00
|
|
|
if (ShouldEmitCFICheck || ShouldEmitVFEInfo || ShouldEmitWPDInfo) {
|
|
|
|
// If doing CFI, VFE or WPD, we will need the metadata node to check
|
|
|
|
// against.
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
llvm::Metadata *MD =
|
|
|
|
CGM.CreateMetadataIdentifierForVirtualMemPtrType(QualType(MPT, 0));
|
|
|
|
TypeId = llvm::MetadataAsValue::get(CGF.getLLVMContext(), MD);
|
|
|
|
}
|
Dead Virtual Function Elimination
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 374539
2019-10-11 19:59:55 +08:00
|
|
|
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
llvm::Value *VFPAddr = Builder.CreateGEP(VTable, VTableOffset);
|
|
|
|
|
|
|
|
if (ShouldEmitVFEInfo) {
|
|
|
|
// If doing VFE, load from the vtable with a type.checked.load intrinsic
|
|
|
|
// call. Note that we use the GEP to calculate the address to load from
|
|
|
|
// and pass 0 as the offset to the intrinsic. This is because every
|
|
|
|
// vtable slot of the correct type is marked with matching metadata, and
|
|
|
|
// we know that the load must be from one of these slots.
|
|
|
|
llvm::Value *CheckedLoad = Builder.CreateCall(
|
|
|
|
CGM.getIntrinsic(llvm::Intrinsic::type_checked_load),
|
|
|
|
{VFPAddr, llvm::ConstantInt::get(CGM.Int32Ty, 0), TypeId});
|
|
|
|
CheckResult = Builder.CreateExtractValue(CheckedLoad, 1);
|
|
|
|
VirtualFn = Builder.CreateExtractValue(CheckedLoad, 0);
|
|
|
|
VirtualFn = Builder.CreateBitCast(VirtualFn, FTy->getPointerTo(),
|
|
|
|
"memptr.virtualfn");
|
2019-10-15 07:25:25 +08:00
|
|
|
} else {
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
// When not doing VFE, emit a normal load, as it allows more
|
|
|
|
// optimisations than type.checked.load.
|
2020-01-25 04:24:18 +08:00
|
|
|
if (ShouldEmitCFICheck || ShouldEmitWPDInfo) {
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
CheckResult = Builder.CreateCall(
|
|
|
|
CGM.getIntrinsic(llvm::Intrinsic::type_test),
|
|
|
|
{Builder.CreateBitCast(VFPAddr, CGF.Int8PtrTy), TypeId});
|
|
|
|
}
|
|
|
|
VFPAddr =
|
|
|
|
Builder.CreateBitCast(VFPAddr, FTy->getPointerTo()->getPointerTo());
|
|
|
|
VirtualFn = Builder.CreateAlignedLoad(VFPAddr, CGF.getPointerAlign(),
|
|
|
|
"memptr.virtualfn");
|
Dead Virtual Function Elimination
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 374539
2019-10-11 19:59:55 +08:00
|
|
|
}
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
assert(VirtualFn && "Virtual fuction pointer not created!");
|
2020-01-25 04:24:18 +08:00
|
|
|
assert((!ShouldEmitCFICheck || !ShouldEmitVFEInfo || !ShouldEmitWPDInfo ||
|
|
|
|
CheckResult) &&
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
"Check result required but not created!");
|
|
|
|
|
|
|
|
if (ShouldEmitCFICheck) {
|
|
|
|
// If doing CFI, emit the check.
|
|
|
|
CheckSourceLocation = CGF.EmitCheckSourceLocation(E->getBeginLoc());
|
|
|
|
CheckTypeDesc = CGF.EmitCheckTypeDescriptor(QualType(MPT, 0));
|
|
|
|
llvm::Constant *StaticData[] = {
|
|
|
|
llvm::ConstantInt::get(CGF.Int8Ty, CodeGenFunction::CFITCK_VMFCall),
|
|
|
|
CheckSourceLocation,
|
|
|
|
CheckTypeDesc,
|
|
|
|
};
|
2010-08-22 08:05:51 +08:00
|
|
|
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
if (CGM.getCodeGenOpts().SanitizeTrap.has(SanitizerKind::CFIMFCall)) {
|
|
|
|
CGF.EmitTrapCheck(CheckResult);
|
|
|
|
} else {
|
|
|
|
llvm::Value *AllVtables = llvm::MetadataAsValue::get(
|
|
|
|
CGM.getLLVMContext(),
|
|
|
|
llvm::MDString::get(CGM.getLLVMContext(), "all-vtables"));
|
|
|
|
llvm::Value *ValidVtable = Builder.CreateCall(
|
|
|
|
CGM.getIntrinsic(llvm::Intrinsic::type_test), {VTable, AllVtables});
|
|
|
|
CGF.EmitCheck(std::make_pair(CheckResult, SanitizerKind::CFIMFCall),
|
|
|
|
SanitizerHandler::CFICheckFail, StaticData,
|
|
|
|
{VTable, ValidVtable});
|
|
|
|
}
|
|
|
|
|
|
|
|
FnVirtual = Builder.GetInsertBlock();
|
|
|
|
}
|
|
|
|
} // End of sanitizer scope
|
2019-10-15 07:25:25 +08:00
|
|
|
|
2010-08-22 08:05:51 +08:00
|
|
|
CGF.EmitBranch(FnEnd);
|
|
|
|
|
|
|
|
// In the non-virtual path, the function pointer is actually a
|
|
|
|
// function pointer.
|
|
|
|
CGF.EmitBlock(FnNonVirtual);
|
|
|
|
llvm::Value *NonVirtualFn =
|
2010-08-22 08:59:17 +08:00
|
|
|
Builder.CreateIntToPtr(FnAsInt, FTy->getPointerTo(), "memptr.nonvirtualfn");
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2018-06-26 10:15:47 +08:00
|
|
|
// Check the function pointer if CFI on member function pointers is enabled.
|
|
|
|
if (ShouldEmitCFICheck) {
|
|
|
|
CXXRecordDecl *RD = MPT->getClass()->getAsCXXRecordDecl();
|
|
|
|
if (RD->hasDefinition()) {
|
|
|
|
CodeGenFunction::SanitizerScope SanScope(&CGF);
|
|
|
|
|
|
|
|
llvm::Constant *StaticData[] = {
|
|
|
|
llvm::ConstantInt::get(CGF.Int8Ty, CodeGenFunction::CFITCK_NVMFCall),
|
|
|
|
CheckSourceLocation,
|
|
|
|
CheckTypeDesc,
|
|
|
|
};
|
|
|
|
|
|
|
|
llvm::Value *Bit = Builder.getFalse();
|
|
|
|
llvm::Value *CastedNonVirtualFn =
|
|
|
|
Builder.CreateBitCast(NonVirtualFn, CGF.Int8PtrTy);
|
|
|
|
for (const CXXRecordDecl *Base : CGM.getMostBaseClasses(RD)) {
|
|
|
|
llvm::Metadata *MD = CGM.CreateMetadataIdentifierForType(
|
|
|
|
getContext().getMemberPointerType(
|
|
|
|
MPT->getPointeeType(),
|
|
|
|
getContext().getRecordType(Base).getTypePtr()));
|
|
|
|
llvm::Value *TypeId =
|
|
|
|
llvm::MetadataAsValue::get(CGF.getLLVMContext(), MD);
|
|
|
|
|
|
|
|
llvm::Value *TypeTest =
|
|
|
|
Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::type_test),
|
|
|
|
{CastedNonVirtualFn, TypeId});
|
|
|
|
Bit = Builder.CreateOr(Bit, TypeTest);
|
|
|
|
}
|
|
|
|
|
|
|
|
CGF.EmitCheck(std::make_pair(Bit, SanitizerKind::CFIMFCall),
|
|
|
|
SanitizerHandler::CFICheckFail, StaticData,
|
|
|
|
{CastedNonVirtualFn, llvm::UndefValue::get(CGF.IntPtrTy)});
|
|
|
|
|
|
|
|
FnNonVirtual = Builder.GetInsertBlock();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-08-22 08:05:51 +08:00
|
|
|
// We're done.
|
|
|
|
CGF.EmitBlock(FnEnd);
|
2016-10-27 07:46:34 +08:00
|
|
|
llvm::PHINode *CalleePtr = Builder.CreatePHI(FTy->getPointerTo(), 2);
|
|
|
|
CalleePtr->addIncoming(VirtualFn, FnVirtual);
|
|
|
|
CalleePtr->addIncoming(NonVirtualFn, FnNonVirtual);
|
|
|
|
|
|
|
|
CGCallee Callee(FPT, CalleePtr);
|
2010-08-22 08:05:51 +08:00
|
|
|
return Callee;
|
|
|
|
}
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2010-09-01 05:07:20 +08:00
|
|
|
/// Compute an l-value by applying the given pointer-to-member to a
|
|
|
|
/// base object.
|
2014-02-21 07:22:07 +08:00
|
|
|
llvm::Value *ItaniumCXXABI::EmitMemberDataPointerAddress(
|
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 Base, llvm::Value *MemPtr,
|
2014-02-21 07:22:07 +08:00
|
|
|
const MemberPointerType *MPT) {
|
2013-03-23 00:13:10 +08:00
|
|
|
assert(MemPtr->getType() == CGM.PtrDiffTy);
|
2010-09-01 05:07:20 +08:00
|
|
|
|
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
|
|
|
|
|
|
|
// Cast to char*.
|
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
|
|
|
Base = Builder.CreateElementBitCast(Base, CGF.Int8Ty);
|
2010-09-01 05:07:20 +08:00
|
|
|
|
|
|
|
// Apply the offset, which we assume is non-null.
|
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::Value *Addr =
|
|
|
|
Builder.CreateInBoundsGEP(Base.getPointer(), MemPtr, "memptr.offset");
|
2010-09-01 05:07:20 +08:00
|
|
|
|
|
|
|
// Cast the address to the appropriate pointer type, adopting the
|
|
|
|
// address space of the base 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
|
|
|
llvm::Type *PType = CGF.ConvertTypeForMem(MPT->getPointeeType())
|
|
|
|
->getPointerTo(Base.getAddressSpace());
|
2010-09-01 05:07:20 +08:00
|
|
|
return Builder.CreateBitCast(Addr, PType);
|
|
|
|
}
|
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
/// Perform a bitcast, derived-to-base, or base-to-derived member pointer
|
|
|
|
/// conversion.
|
|
|
|
///
|
|
|
|
/// Bitcast conversions are always a no-op under Itanium.
|
2010-08-23 09:21:21 +08:00
|
|
|
///
|
|
|
|
/// Obligatory offset/adjustment diagram:
|
|
|
|
/// <-- offset --> <-- adjustment -->
|
|
|
|
/// |--------------------------|----------------------|--------------------|
|
|
|
|
/// ^Derived address point ^Base address point ^Member address point
|
|
|
|
///
|
|
|
|
/// So when converting a base member pointer to a derived member pointer,
|
|
|
|
/// we add the offset to the adjustment because the address point has
|
|
|
|
/// decreased; and conversely, when converting a derived MP to a base MP
|
|
|
|
/// we subtract the offset from the adjustment because the address point
|
|
|
|
/// has increased.
|
|
|
|
///
|
|
|
|
/// The standard forbids (at compile time) conversion to and from
|
|
|
|
/// virtual bases, which is why we don't have to consider them here.
|
|
|
|
///
|
|
|
|
/// The standard forbids (at run time) casting a derived MP to a base
|
|
|
|
/// MP when the derived MP does not point to a member of the base.
|
|
|
|
/// This is why -1 is a reasonable choice for null data member
|
|
|
|
/// pointers.
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Value *
|
2010-08-23 09:21:21 +08:00
|
|
|
ItaniumCXXABI::EmitMemberPointerConversion(CodeGenFunction &CGF,
|
|
|
|
const CastExpr *E,
|
2012-02-15 09:22:51 +08:00
|
|
|
llvm::Value *src) {
|
2010-08-25 19:45:40 +08:00
|
|
|
assert(E->getCastKind() == CK_DerivedToBaseMemberPointer ||
|
2012-02-15 09:22:51 +08:00
|
|
|
E->getCastKind() == CK_BaseToDerivedMemberPointer ||
|
|
|
|
E->getCastKind() == CK_ReinterpretMemberPointer);
|
|
|
|
|
|
|
|
// Under Itanium, reinterprets don't require any additional processing.
|
|
|
|
if (E->getCastKind() == CK_ReinterpretMemberPointer) return src;
|
|
|
|
|
|
|
|
// Use constant emission if we can.
|
|
|
|
if (isa<llvm::Constant>(src))
|
|
|
|
return EmitMemberPointerConversion(E, cast<llvm::Constant>(src));
|
|
|
|
|
|
|
|
llvm::Constant *adj = getMemberPointerAdjustment(E);
|
|
|
|
if (!adj) return src;
|
2010-08-22 11:04:22 +08:00
|
|
|
|
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
2012-02-15 09:22:51 +08:00
|
|
|
bool isDerivedToBase = (E->getCastKind() == CK_DerivedToBaseMemberPointer);
|
|
|
|
|
|
|
|
const MemberPointerType *destTy =
|
|
|
|
E->getType()->castAs<MemberPointerType>();
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
// For member data pointers, this is just a matter of adding the
|
|
|
|
// offset if the source is non-null.
|
|
|
|
if (destTy->isMemberDataPointer()) {
|
|
|
|
llvm::Value *dst;
|
|
|
|
if (isDerivedToBase)
|
|
|
|
dst = Builder.CreateNSWSub(src, adj, "adj");
|
|
|
|
else
|
|
|
|
dst = Builder.CreateNSWAdd(src, adj, "adj");
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
// Null check.
|
|
|
|
llvm::Value *null = llvm::Constant::getAllOnesValue(src->getType());
|
|
|
|
llvm::Value *isNull = Builder.CreateICmpEQ(src, null, "memptr.isnull");
|
|
|
|
return Builder.CreateSelect(isNull, src, dst);
|
|
|
|
}
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
// The this-adjustment is left-shifted by 1 on ARM.
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI) {
|
2012-02-15 09:22:51 +08:00
|
|
|
uint64_t offset = cast<llvm::ConstantInt>(adj)->getZExtValue();
|
|
|
|
offset <<= 1;
|
|
|
|
adj = llvm::ConstantInt::get(adj->getType(), offset);
|
|
|
|
}
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
llvm::Value *srcAdj = Builder.CreateExtractValue(src, 1, "src.adj");
|
|
|
|
llvm::Value *dstAdj;
|
|
|
|
if (isDerivedToBase)
|
|
|
|
dstAdj = Builder.CreateNSWSub(srcAdj, adj, "adj");
|
2010-08-22 11:04:22 +08:00
|
|
|
else
|
2012-02-15 09:22:51 +08:00
|
|
|
dstAdj = Builder.CreateNSWAdd(srcAdj, adj, "adj");
|
|
|
|
|
|
|
|
return Builder.CreateInsertValue(src, dstAdj, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *
|
|
|
|
ItaniumCXXABI::EmitMemberPointerConversion(const CastExpr *E,
|
|
|
|
llvm::Constant *src) {
|
|
|
|
assert(E->getCastKind() == CK_DerivedToBaseMemberPointer ||
|
|
|
|
E->getCastKind() == CK_BaseToDerivedMemberPointer ||
|
|
|
|
E->getCastKind() == CK_ReinterpretMemberPointer);
|
2010-08-22 11:04:22 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
// Under Itanium, reinterprets don't require any additional processing.
|
|
|
|
if (E->getCastKind() == CK_ReinterpretMemberPointer) return src;
|
|
|
|
|
|
|
|
// If the adjustment is trivial, we don't need to do anything.
|
|
|
|
llvm::Constant *adj = getMemberPointerAdjustment(E);
|
|
|
|
if (!adj) return src;
|
|
|
|
|
|
|
|
bool isDerivedToBase = (E->getCastKind() == CK_DerivedToBaseMemberPointer);
|
|
|
|
|
|
|
|
const MemberPointerType *destTy =
|
|
|
|
E->getType()->castAs<MemberPointerType>();
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
// For member data pointers, this is just a matter of adding the
|
|
|
|
// offset if the source is non-null.
|
2012-02-15 09:22:51 +08:00
|
|
|
if (destTy->isMemberDataPointer()) {
|
|
|
|
// null maps to null.
|
|
|
|
if (src->isAllOnesValue()) return src;
|
2010-08-23 09:21:21 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
if (isDerivedToBase)
|
|
|
|
return llvm::ConstantExpr::getNSWSub(src, adj);
|
|
|
|
else
|
|
|
|
return llvm::ConstantExpr::getNSWAdd(src, adj);
|
2010-08-23 09:21:21 +08:00
|
|
|
}
|
|
|
|
|
2010-08-22 18:59:02 +08:00
|
|
|
// The this-adjustment is left-shifted by 1 on ARM.
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI) {
|
2012-02-15 09:22:51 +08:00
|
|
|
uint64_t offset = cast<llvm::ConstantInt>(adj)->getZExtValue();
|
|
|
|
offset <<= 1;
|
|
|
|
adj = llvm::ConstantInt::get(adj->getType(), offset);
|
2010-08-22 18:59:02 +08:00
|
|
|
}
|
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
llvm::Constant *srcAdj = llvm::ConstantExpr::getExtractValue(src, 1);
|
|
|
|
llvm::Constant *dstAdj;
|
|
|
|
if (isDerivedToBase)
|
|
|
|
dstAdj = llvm::ConstantExpr::getNSWSub(srcAdj, adj);
|
2010-08-22 18:59:02 +08:00
|
|
|
else
|
2012-02-15 09:22:51 +08:00
|
|
|
dstAdj = llvm::ConstantExpr::getNSWAdd(srcAdj, adj);
|
2010-08-22 18:59:02 +08:00
|
|
|
|
2012-02-15 09:22:51 +08:00
|
|
|
return llvm::ConstantExpr::getInsertValue(src, dstAdj, 1);
|
2010-08-22 11:04:22 +08:00
|
|
|
}
|
2010-08-22 12:16:24 +08:00
|
|
|
|
|
|
|
llvm::Constant *
|
2010-08-23 09:21:21 +08:00
|
|
|
ItaniumCXXABI::EmitNullMemberPointer(const MemberPointerType *MPT) {
|
|
|
|
// Itanium C++ ABI 2.3:
|
|
|
|
// A NULL pointer is represented as -1.
|
2017-11-11 09:15:41 +08:00
|
|
|
if (MPT->isMemberDataPointer())
|
2013-03-23 00:13:10 +08:00
|
|
|
return llvm::ConstantInt::get(CGM.PtrDiffTy, -1ULL, /*isSigned=*/true);
|
2010-08-22 18:59:02 +08:00
|
|
|
|
2013-03-23 00:13:10 +08:00
|
|
|
llvm::Constant *Zero = llvm::ConstantInt::get(CGM.PtrDiffTy, 0);
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Constant *Values[2] = { Zero, Zero };
|
2011-06-20 12:01:35 +08:00
|
|
|
return llvm::ConstantStruct::getAnon(Values);
|
2010-08-22 12:16:24 +08:00
|
|
|
}
|
|
|
|
|
2011-02-03 16:15:49 +08:00
|
|
|
llvm::Constant *
|
|
|
|
ItaniumCXXABI::EmitMemberDataPointer(const MemberPointerType *MPT,
|
|
|
|
CharUnits offset) {
|
2010-08-23 09:21:21 +08:00
|
|
|
// Itanium C++ ABI 2.3:
|
|
|
|
// A pointer to data member is an offset from the base address of
|
|
|
|
// the class object containing it, represented as a ptrdiff_t
|
2013-03-23 00:13:10 +08:00
|
|
|
return llvm::ConstantInt::get(CGM.PtrDiffTy, offset.getQuantity());
|
2010-08-23 09:21:21 +08:00
|
|
|
}
|
|
|
|
|
2015-06-23 15:31:01 +08:00
|
|
|
llvm::Constant *
|
|
|
|
ItaniumCXXABI::EmitMemberFunctionPointer(const CXXMethodDecl *MD) {
|
2012-01-14 12:30:29 +08:00
|
|
|
return BuildMemberPointer(MD, CharUnits::Zero());
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *ItaniumCXXABI::BuildMemberPointer(const CXXMethodDecl *MD,
|
|
|
|
CharUnits ThisAdjustment) {
|
2010-08-22 18:59:02 +08:00
|
|
|
assert(MD->isInstance() && "Member function must not be static!");
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2010-08-22 18:59:02 +08:00
|
|
|
CodeGenTypes &Types = CGM.getTypes();
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2010-08-22 18:59:02 +08:00
|
|
|
// Get the function pointer (or index if this is a virtual function).
|
|
|
|
llvm::Constant *MemPtr[2];
|
|
|
|
if (MD->isVirtual()) {
|
2013-11-05 23:54:58 +08:00
|
|
|
uint64_t Index = CGM.getItaniumVTableContext().getMethodVTableIndex(MD);
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2011-04-09 09:30:02 +08:00
|
|
|
const ASTContext &Context = getContext();
|
|
|
|
CharUnits PointerWidth =
|
2011-09-02 08:18:52 +08:00
|
|
|
Context.toCharUnitsFromBits(Context.getTargetInfo().getPointerWidth(0));
|
2011-04-09 09:30:02 +08:00
|
|
|
uint64_t VTableOffset = (Index * PointerWidth.getQuantity());
|
2010-08-22 18:59:02 +08:00
|
|
|
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI) {
|
2010-08-22 18:59:02 +08:00
|
|
|
// ARM C++ ABI 3.2.1:
|
|
|
|
// This ABI specifies that adj contains twice the this
|
|
|
|
// adjustment, plus 1 if the member function is virtual. The
|
|
|
|
// least significant bit of adj then makes exactly the same
|
|
|
|
// discrimination as the least significant bit of ptr does for
|
|
|
|
// Itanium.
|
2013-03-23 00:13:10 +08:00
|
|
|
MemPtr[0] = llvm::ConstantInt::get(CGM.PtrDiffTy, VTableOffset);
|
|
|
|
MemPtr[1] = llvm::ConstantInt::get(CGM.PtrDiffTy,
|
2012-01-14 12:30:29 +08:00
|
|
|
2 * ThisAdjustment.getQuantity() + 1);
|
2010-08-22 18:59:02 +08:00
|
|
|
} else {
|
|
|
|
// Itanium C++ ABI 2.3:
|
|
|
|
// For a virtual function, [the pointer field] is 1 plus the
|
|
|
|
// virtual table offset (in bytes) of the function,
|
|
|
|
// represented as a ptrdiff_t.
|
2013-03-23 00:13:10 +08:00
|
|
|
MemPtr[0] = llvm::ConstantInt::get(CGM.PtrDiffTy, VTableOffset + 1);
|
|
|
|
MemPtr[1] = llvm::ConstantInt::get(CGM.PtrDiffTy,
|
2012-01-14 12:30:29 +08:00
|
|
|
ThisAdjustment.getQuantity());
|
2010-08-22 18:59:02 +08:00
|
|
|
}
|
|
|
|
} else {
|
2011-04-12 08:42:48 +08:00
|
|
|
const FunctionProtoType *FPT = MD->getType()->castAs<FunctionProtoType>();
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::Type *Ty;
|
2011-04-12 08:42:48 +08:00
|
|
|
// Check whether the function has a computable LLVM signature.
|
2011-07-10 08:18:59 +08:00
|
|
|
if (Types.isFuncTypeConvertible(FPT)) {
|
2011-04-12 08:42:48 +08:00
|
|
|
// The function has a computable LLVM signature; use the correct type.
|
2012-02-17 11:33:10 +08:00
|
|
|
Ty = Types.GetFunctionType(Types.arrangeCXXMethodDeclaration(MD));
|
2010-08-22 18:59:02 +08:00
|
|
|
} else {
|
2011-04-12 08:42:48 +08:00
|
|
|
// Use an arbitrary non-function type to tell GetAddrOfFunction that the
|
|
|
|
// function type is incomplete.
|
2013-03-23 00:13:10 +08:00
|
|
|
Ty = CGM.PtrDiffTy;
|
2010-08-22 18:59:02 +08:00
|
|
|
}
|
2011-04-12 08:42:48 +08:00
|
|
|
llvm::Constant *addr = CGM.GetAddrOfFunction(MD, Ty);
|
2010-08-22 18:59:02 +08:00
|
|
|
|
2013-03-23 00:13:10 +08:00
|
|
|
MemPtr[0] = llvm::ConstantExpr::getPtrToInt(addr, CGM.PtrDiffTy);
|
2013-07-25 00:25:13 +08:00
|
|
|
MemPtr[1] = llvm::ConstantInt::get(CGM.PtrDiffTy,
|
|
|
|
(UseARMMethodPtrABI ? 2 : 1) *
|
2012-01-14 12:30:29 +08:00
|
|
|
ThisAdjustment.getQuantity());
|
2010-08-22 18:59:02 +08:00
|
|
|
}
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2011-06-20 12:01:35 +08:00
|
|
|
return llvm::ConstantStruct::getAnon(MemPtr);
|
2010-08-22 14:43:33 +08:00
|
|
|
}
|
|
|
|
|
2012-01-14 12:30:29 +08:00
|
|
|
llvm::Constant *ItaniumCXXABI::EmitMemberPointer(const APValue &MP,
|
|
|
|
QualType MPType) {
|
|
|
|
const MemberPointerType *MPT = MPType->castAs<MemberPointerType>();
|
|
|
|
const ValueDecl *MPD = MP.getMemberPointerDecl();
|
|
|
|
if (!MPD)
|
|
|
|
return EmitNullMemberPointer(MPT);
|
|
|
|
|
2013-05-10 05:01:17 +08:00
|
|
|
CharUnits ThisAdjustment = getMemberPointerPathAdjustment(MP);
|
2012-01-14 12:30:29 +08:00
|
|
|
|
|
|
|
if (const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(MPD))
|
|
|
|
return BuildMemberPointer(MD, ThisAdjustment);
|
|
|
|
|
|
|
|
CharUnits FieldOffset =
|
|
|
|
getContext().toCharUnitsFromBits(getContext().getFieldOffset(MPD));
|
|
|
|
return EmitMemberDataPointer(MPT, ThisAdjustment + FieldOffset);
|
|
|
|
}
|
|
|
|
|
2010-08-22 16:30:07 +08:00
|
|
|
/// The comparison algorithm is pretty easy: the member pointers are
|
|
|
|
/// the same if they're either bitwise identical *or* both null.
|
|
|
|
///
|
|
|
|
/// ARM is different here only because null-ness is more complicated.
|
|
|
|
llvm::Value *
|
2010-08-23 09:21:21 +08:00
|
|
|
ItaniumCXXABI::EmitMemberPointerComparison(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *L,
|
|
|
|
llvm::Value *R,
|
|
|
|
const MemberPointerType *MPT,
|
|
|
|
bool Inequality) {
|
2010-08-22 16:30:07 +08:00
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
|
|
|
|
|
|
|
llvm::ICmpInst::Predicate Eq;
|
|
|
|
llvm::Instruction::BinaryOps And, Or;
|
|
|
|
if (Inequality) {
|
|
|
|
Eq = llvm::ICmpInst::ICMP_NE;
|
|
|
|
And = llvm::Instruction::Or;
|
|
|
|
Or = llvm::Instruction::And;
|
|
|
|
} else {
|
|
|
|
Eq = llvm::ICmpInst::ICMP_EQ;
|
|
|
|
And = llvm::Instruction::And;
|
|
|
|
Or = llvm::Instruction::Or;
|
|
|
|
}
|
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
// Member data pointers are easy because there's a unique null
|
|
|
|
// value, so it just comes down to bitwise equality.
|
|
|
|
if (MPT->isMemberDataPointer())
|
|
|
|
return Builder.CreateICmp(Eq, L, R);
|
|
|
|
|
|
|
|
// For member function pointers, the tautologies are more complex.
|
|
|
|
// The Itanium tautology is:
|
2010-08-23 14:56:36 +08:00
|
|
|
// (L == R) <==> (L.ptr == R.ptr && (L.ptr == 0 || L.adj == R.adj))
|
2010-08-23 09:21:21 +08:00
|
|
|
// The ARM tautology is:
|
2010-08-23 14:56:36 +08:00
|
|
|
// (L == R) <==> (L.ptr == R.ptr &&
|
|
|
|
// (L.adj == R.adj ||
|
|
|
|
// (L.ptr == 0 && ((L.adj|R.adj) & 1) == 0)))
|
2010-08-23 09:21:21 +08:00
|
|
|
// The inequality tautologies have exactly the same structure, except
|
|
|
|
// applying De Morgan's laws.
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-08-23 09:21:21 +08:00
|
|
|
llvm::Value *LPtr = Builder.CreateExtractValue(L, 0, "lhs.memptr.ptr");
|
|
|
|
llvm::Value *RPtr = Builder.CreateExtractValue(R, 0, "rhs.memptr.ptr");
|
|
|
|
|
2010-08-22 16:30:07 +08:00
|
|
|
// This condition tests whether L.ptr == R.ptr. This must always be
|
|
|
|
// true for equality to hold.
|
|
|
|
llvm::Value *PtrEq = Builder.CreateICmp(Eq, LPtr, RPtr, "cmp.ptr");
|
|
|
|
|
|
|
|
// This condition, together with the assumption that L.ptr == R.ptr,
|
|
|
|
// tests whether the pointers are both null. ARM imposes an extra
|
|
|
|
// condition.
|
|
|
|
llvm::Value *Zero = llvm::Constant::getNullValue(LPtr->getType());
|
|
|
|
llvm::Value *EqZero = Builder.CreateICmp(Eq, LPtr, Zero, "cmp.ptr.null");
|
|
|
|
|
|
|
|
// This condition tests whether L.adj == R.adj. If this isn't
|
|
|
|
// true, the pointers are unequal unless they're both null.
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Value *LAdj = Builder.CreateExtractValue(L, 1, "lhs.memptr.adj");
|
|
|
|
llvm::Value *RAdj = Builder.CreateExtractValue(R, 1, "rhs.memptr.adj");
|
2010-08-22 16:30:07 +08:00
|
|
|
llvm::Value *AdjEq = Builder.CreateICmp(Eq, LAdj, RAdj, "cmp.adj");
|
|
|
|
|
|
|
|
// Null member function pointers on ARM clear the low bit of Adj,
|
|
|
|
// so the zero condition has to check that neither low bit is set.
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI) {
|
2010-08-22 16:30:07 +08:00
|
|
|
llvm::Value *One = llvm::ConstantInt::get(LPtr->getType(), 1);
|
|
|
|
|
|
|
|
// Compute (l.adj | r.adj) & 1 and test it against zero.
|
|
|
|
llvm::Value *OrAdj = Builder.CreateOr(LAdj, RAdj, "or.adj");
|
|
|
|
llvm::Value *OrAdjAnd1 = Builder.CreateAnd(OrAdj, One);
|
|
|
|
llvm::Value *OrAdjAnd1EqZero = Builder.CreateICmp(Eq, OrAdjAnd1, Zero,
|
|
|
|
"cmp.or.adj");
|
|
|
|
EqZero = Builder.CreateBinOp(And, EqZero, OrAdjAnd1EqZero);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Tie together all our conditions.
|
|
|
|
llvm::Value *Result = Builder.CreateBinOp(Or, EqZero, AdjEq);
|
|
|
|
Result = Builder.CreateBinOp(And, PtrEq, Result,
|
|
|
|
Inequality ? "memptr.ne" : "memptr.eq");
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *
|
2010-08-23 09:21:21 +08:00
|
|
|
ItaniumCXXABI::EmitMemberPointerIsNotNull(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *MemPtr,
|
|
|
|
const MemberPointerType *MPT) {
|
2010-08-22 16:30:07 +08:00
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
2010-08-23 09:21:21 +08:00
|
|
|
|
|
|
|
/// For member data pointers, this is just a check against -1.
|
|
|
|
if (MPT->isMemberDataPointer()) {
|
2013-03-23 00:13:10 +08:00
|
|
|
assert(MemPtr->getType() == CGM.PtrDiffTy);
|
2010-08-23 09:21:21 +08:00
|
|
|
llvm::Value *NegativeOne =
|
|
|
|
llvm::Constant::getAllOnesValue(MemPtr->getType());
|
|
|
|
return Builder.CreateICmpNE(MemPtr, NegativeOne, "memptr.tobool");
|
|
|
|
}
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2011-04-20 07:10:47 +08:00
|
|
|
// In Itanium, a member function pointer is not null if 'ptr' is not null.
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Value *Ptr = Builder.CreateExtractValue(MemPtr, 0, "memptr.ptr");
|
2010-08-22 16:30:07 +08:00
|
|
|
|
|
|
|
llvm::Constant *Zero = llvm::ConstantInt::get(Ptr->getType(), 0);
|
|
|
|
llvm::Value *Result = Builder.CreateICmpNE(Ptr, Zero, "memptr.tobool");
|
|
|
|
|
2011-04-20 07:10:47 +08:00
|
|
|
// On ARM, a member function pointer is also non-null if the low bit of 'adj'
|
|
|
|
// (the virtual bit) is set.
|
2013-07-25 00:25:13 +08:00
|
|
|
if (UseARMMethodPtrABI) {
|
2010-08-22 16:30:07 +08:00
|
|
|
llvm::Constant *One = llvm::ConstantInt::get(Ptr->getType(), 1);
|
2010-08-22 18:59:02 +08:00
|
|
|
llvm::Value *Adj = Builder.CreateExtractValue(MemPtr, 1, "memptr.adj");
|
2010-08-22 16:30:07 +08:00
|
|
|
llvm::Value *VirtualBit = Builder.CreateAnd(Adj, One, "memptr.virtualbit");
|
2011-04-20 07:10:47 +08:00
|
|
|
llvm::Value *IsVirtual = Builder.CreateICmpNE(VirtualBit, Zero,
|
|
|
|
"memptr.isvirtual");
|
|
|
|
Result = Builder.CreateOr(Result, IsVirtual);
|
2010-08-22 16:30:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
2010-08-22 14:43:33 +08:00
|
|
|
|
2014-05-14 06:05:45 +08:00
|
|
|
bool ItaniumCXXABI::classifyReturnType(CGFunctionInfo &FI) const {
|
|
|
|
const CXXRecordDecl *RD = FI.getReturnType()->getAsCXXRecordDecl();
|
|
|
|
if (!RD)
|
|
|
|
return false;
|
|
|
|
|
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
|
|
|
// If C++ prohibits us from making a copy, return by address.
|
2019-05-01 06:23:20 +08:00
|
|
|
if (!RD->canPassInRegisters()) {
|
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
|
|
|
auto Align = CGM.getContext().getTypeAlignInChars(FI.getReturnType());
|
|
|
|
FI.getReturnInfo() = ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
|
2014-05-14 06:05:45 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-08-23 05:01:12 +08:00
|
|
|
/// The Itanium ABI requires non-zero initialization only for data
|
|
|
|
/// member pointers, for which '0' is a valid offset.
|
|
|
|
bool ItaniumCXXABI::isZeroInitializable(const MemberPointerType *MPT) {
|
2015-04-24 09:25:08 +08:00
|
|
|
return MPT->isMemberFunctionPointer();
|
2010-08-22 12:16:24 +08:00
|
|
|
}
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2012-09-25 18:10:39 +08:00
|
|
|
/// The Itanium ABI always places an offset to the complete object
|
|
|
|
/// at entry -2 in the vtable.
|
2014-11-01 15:37:17 +08:00
|
|
|
void ItaniumCXXABI::emitVirtualObjectDelete(CodeGenFunction &CGF,
|
|
|
|
const CXXDeleteExpr *DE,
|
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,
|
2014-11-01 15:37:17 +08:00
|
|
|
QualType ElementType,
|
|
|
|
const CXXDestructorDecl *Dtor) {
|
|
|
|
bool UseGlobalDelete = DE->isGlobalDelete();
|
2014-11-01 04:09:12 +08:00
|
|
|
if (UseGlobalDelete) {
|
|
|
|
// Derive the complete-object pointer, which is what we need
|
|
|
|
// to pass to the deallocation function.
|
|
|
|
|
|
|
|
// Grab the vtable pointer as an intptr_t*.
|
2015-09-16 05:46:55 +08:00
|
|
|
auto *ClassDecl =
|
2019-10-03 04:45:16 +08:00
|
|
|
cast<CXXRecordDecl>(ElementType->castAs<RecordType>()->getDecl());
|
2015-09-16 05:46:55 +08:00
|
|
|
llvm::Value *VTable =
|
|
|
|
CGF.GetVTablePtr(Ptr, CGF.IntPtrTy->getPointerTo(), ClassDecl);
|
2014-11-01 04:09:12 +08:00
|
|
|
|
|
|
|
// Track back to entry -2 and pull out the offset there.
|
|
|
|
llvm::Value *OffsetPtr = CGF.Builder.CreateConstInBoundsGEP1_64(
|
|
|
|
VTable, -2, "complete-offset.ptr");
|
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::Value *Offset =
|
|
|
|
CGF.Builder.CreateAlignedLoad(OffsetPtr, CGF.getPointerAlign());
|
2014-11-01 04:09:12 +08:00
|
|
|
|
|
|
|
// Apply the offset.
|
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::Value *CompletePtr =
|
|
|
|
CGF.Builder.CreateBitCast(Ptr.getPointer(), CGF.Int8PtrTy);
|
2014-11-01 04:09:12 +08:00
|
|
|
CompletePtr = CGF.Builder.CreateInBoundsGEP(CompletePtr, Offset);
|
|
|
|
|
|
|
|
// If we're supposed to call the global delete, make sure we do so
|
|
|
|
// even if the destructor throws.
|
2014-11-01 15:37:17 +08:00
|
|
|
CGF.pushCallObjectDeleteCleanup(DE->getOperatorDelete(), CompletePtr,
|
|
|
|
ElementType);
|
2014-11-01 04:09:12 +08:00
|
|
|
}
|
2012-09-25 18:10:39 +08:00
|
|
|
|
2014-11-01 04:09:12 +08:00
|
|
|
// FIXME: Provide a source location here even though there's no
|
|
|
|
// CXXMemberCallExpr for dtor call.
|
|
|
|
CXXDtorType DtorType = UseGlobalDelete ? Dtor_Complete : Dtor_Deleting;
|
2019-07-22 17:39:13 +08:00
|
|
|
EmitVirtualDestructorCall(CGF, Dtor, DtorType, Ptr, DE);
|
2014-11-01 04:09:12 +08:00
|
|
|
|
|
|
|
if (UseGlobalDelete)
|
|
|
|
CGF.PopCleanupBlock();
|
2012-09-25 18:10:39 +08:00
|
|
|
}
|
|
|
|
|
2014-11-25 15:20:20 +08:00
|
|
|
void ItaniumCXXABI::emitRethrow(CodeGenFunction &CGF, bool isNoReturn) {
|
|
|
|
// void __cxa_rethrow();
|
|
|
|
|
|
|
|
llvm::FunctionType *FTy =
|
2019-07-16 12:46:31 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, /*isVarArg=*/false);
|
2014-11-25 15:20:20 +08:00
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee Fn = CGM.CreateRuntimeFunction(FTy, "__cxa_rethrow");
|
2014-11-25 15:20:20 +08:00
|
|
|
|
|
|
|
if (isNoReturn)
|
|
|
|
CGF.EmitNoreturnRuntimeCallOrInvoke(Fn, None);
|
|
|
|
else
|
|
|
|
CGF.EmitRuntimeCallOrInvoke(Fn);
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getAllocateExceptionFn(CodeGenModule &CGM) {
|
2015-03-05 08:46:22 +08:00
|
|
|
// void *__cxa_allocate_exception(size_t thrown_size);
|
|
|
|
|
|
|
|
llvm::FunctionType *FTy =
|
2019-07-16 12:46:31 +08:00
|
|
|
llvm::FunctionType::get(CGM.Int8PtrTy, CGM.SizeTy, /*isVarArg=*/false);
|
2015-03-05 08:46:22 +08:00
|
|
|
|
|
|
|
return CGM.CreateRuntimeFunction(FTy, "__cxa_allocate_exception");
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getThrowFn(CodeGenModule &CGM) {
|
2015-03-05 08:46:22 +08:00
|
|
|
// void __cxa_throw(void *thrown_exception, std::type_info *tinfo,
|
|
|
|
// void (*dest) (void *));
|
|
|
|
|
|
|
|
llvm::Type *Args[3] = { CGM.Int8PtrTy, CGM.Int8PtrTy, CGM.Int8PtrTy };
|
|
|
|
llvm::FunctionType *FTy =
|
2019-07-16 12:46:31 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, Args, /*isVarArg=*/false);
|
2015-03-05 08:46:22 +08:00
|
|
|
|
|
|
|
return CGM.CreateRuntimeFunction(FTy, "__cxa_throw");
|
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumCXXABI::emitThrow(CodeGenFunction &CGF, const CXXThrowExpr *E) {
|
|
|
|
QualType ThrowType = E->getSubExpr()->getType();
|
|
|
|
// Now allocate the exception object.
|
|
|
|
llvm::Type *SizeTy = CGF.ConvertType(getContext().getSizeType());
|
|
|
|
uint64_t TypeSize = getContext().getTypeSizeInChars(ThrowType).getQuantity();
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee AllocExceptionFn = getAllocateExceptionFn(CGM);
|
2015-03-05 08:46:22 +08:00
|
|
|
llvm::CallInst *ExceptionPtr = CGF.EmitNounwindRuntimeCall(
|
|
|
|
AllocExceptionFn, llvm::ConstantInt::get(SizeTy, TypeSize), "exception");
|
|
|
|
|
2019-05-10 10:16:37 +08:00
|
|
|
CharUnits ExnAlign = CGF.getContext().getExnObjectAlignment();
|
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.EmitAnyExprToExn(E->getSubExpr(), Address(ExceptionPtr, ExnAlign));
|
2015-03-05 08:46:22 +08:00
|
|
|
|
|
|
|
// Now throw the exception.
|
|
|
|
llvm::Constant *TypeInfo = CGM.GetAddrOfRTTIDescriptor(ThrowType,
|
|
|
|
/*ForEH=*/true);
|
|
|
|
|
|
|
|
// The address of the destructor. If the exception type has a
|
|
|
|
// trivial destructor (or isn't a record), we just pass null.
|
|
|
|
llvm::Constant *Dtor = nullptr;
|
|
|
|
if (const RecordType *RecordTy = ThrowType->getAs<RecordType>()) {
|
|
|
|
CXXRecordDecl *Record = cast<CXXRecordDecl>(RecordTy->getDecl());
|
|
|
|
if (!Record->hasTrivialDestructor()) {
|
|
|
|
CXXDestructorDecl *DtorD = Record->getDestructor();
|
2019-03-23 07:05:10 +08:00
|
|
|
Dtor = CGM.getAddrOfCXXStructor(GlobalDecl(DtorD, Dtor_Complete));
|
2015-03-05 08:46:22 +08:00
|
|
|
Dtor = llvm::ConstantExpr::getBitCast(Dtor, CGM.Int8PtrTy);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!Dtor) Dtor = llvm::Constant::getNullValue(CGM.Int8PtrTy);
|
|
|
|
|
|
|
|
llvm::Value *args[] = { ExceptionPtr, TypeInfo, Dtor };
|
|
|
|
CGF.EmitNoreturnRuntimeCallOrInvoke(getThrowFn(CGM), args);
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getItaniumDynamicCastFn(CodeGenFunction &CGF) {
|
2014-06-23 03:05:33 +08:00
|
|
|
// void *__dynamic_cast(const void *sub,
|
|
|
|
// const abi::__class_type_info *src,
|
|
|
|
// const abi::__class_type_info *dst,
|
|
|
|
// std::ptrdiff_t src2dst_offset);
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2014-06-23 03:05:33 +08:00
|
|
|
llvm::Type *Int8PtrTy = CGF.Int8PtrTy;
|
2017-11-11 09:15:41 +08:00
|
|
|
llvm::Type *PtrDiffTy =
|
2014-06-23 03:05:33 +08:00
|
|
|
CGF.ConvertType(CGF.getContext().getPointerDiffType());
|
|
|
|
|
|
|
|
llvm::Type *Args[4] = { Int8PtrTy, Int8PtrTy, Int8PtrTy, PtrDiffTy };
|
|
|
|
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(Int8PtrTy, Args, false);
|
|
|
|
|
|
|
|
// Mark the function as nounwind readonly.
|
|
|
|
llvm::Attribute::AttrKind FuncAttrs[] = { llvm::Attribute::NoUnwind,
|
|
|
|
llvm::Attribute::ReadOnly };
|
2017-03-22 00:57:30 +08:00
|
|
|
llvm::AttributeList Attrs = llvm::AttributeList::get(
|
|
|
|
CGF.getLLVMContext(), llvm::AttributeList::FunctionIndex, FuncAttrs);
|
2014-06-23 03:05:33 +08:00
|
|
|
|
|
|
|
return CGF.CGM.CreateRuntimeFunction(FTy, "__dynamic_cast", Attrs);
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getBadCastFn(CodeGenFunction &CGF) {
|
2014-06-23 03:05:33 +08:00
|
|
|
// void __cxa_bad_cast();
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(CGF.VoidTy, false);
|
|
|
|
return CGF.CGM.CreateRuntimeFunction(FTy, "__cxa_bad_cast");
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Compute the src2dst_offset hint as described in the
|
2014-06-23 03:05:33 +08:00
|
|
|
/// Itanium C++ ABI [2.9.7]
|
|
|
|
static CharUnits computeOffsetHint(ASTContext &Context,
|
|
|
|
const CXXRecordDecl *Src,
|
|
|
|
const CXXRecordDecl *Dst) {
|
|
|
|
CXXBasePaths Paths(/*FindAmbiguities=*/true, /*RecordPaths=*/true,
|
|
|
|
/*DetectVirtual=*/false);
|
|
|
|
|
|
|
|
// If Dst is not derived from Src we can skip the whole computation below and
|
|
|
|
// return that Src is not a public base of Dst. Record all inheritance paths.
|
|
|
|
if (!Dst->isDerivedFrom(Src, Paths))
|
|
|
|
return CharUnits::fromQuantity(-2ULL);
|
|
|
|
|
|
|
|
unsigned NumPublicPaths = 0;
|
|
|
|
CharUnits Offset;
|
|
|
|
|
|
|
|
// Now walk all possible inheritance paths.
|
2015-07-29 00:10:58 +08:00
|
|
|
for (const CXXBasePath &Path : Paths) {
|
|
|
|
if (Path.Access != AS_public) // Ignore non-public inheritance.
|
2014-06-23 03:05:33 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
++NumPublicPaths;
|
|
|
|
|
2015-07-29 00:10:58 +08:00
|
|
|
for (const CXXBasePathElement &PathElement : Path) {
|
2014-06-23 03:05:33 +08:00
|
|
|
// If the path contains a virtual base class we can't give any hint.
|
|
|
|
// -1: no hint.
|
2015-07-29 00:10:58 +08:00
|
|
|
if (PathElement.Base->isVirtual())
|
2014-06-23 03:05:33 +08:00
|
|
|
return CharUnits::fromQuantity(-1ULL);
|
|
|
|
|
|
|
|
if (NumPublicPaths > 1) // Won't use offsets, skip computation.
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Accumulate the base class offsets.
|
2015-07-29 00:10:58 +08:00
|
|
|
const ASTRecordLayout &L = Context.getASTRecordLayout(PathElement.Class);
|
|
|
|
Offset += L.getBaseClassOffset(
|
|
|
|
PathElement.Base->getType()->getAsCXXRecordDecl());
|
2014-06-23 03:05:33 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// -2: Src is not a public base of Dst.
|
|
|
|
if (NumPublicPaths == 0)
|
|
|
|
return CharUnits::fromQuantity(-2ULL);
|
|
|
|
|
|
|
|
// -3: Src is a multiple public base type but never a virtual base type.
|
|
|
|
if (NumPublicPaths > 1)
|
|
|
|
return CharUnits::fromQuantity(-3ULL);
|
|
|
|
|
|
|
|
// Otherwise, the Src type is a unique public nonvirtual base type of Dst.
|
|
|
|
// Return the offset of Src from the origin of Dst.
|
|
|
|
return Offset;
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getBadTypeidFn(CodeGenFunction &CGF) {
|
2014-06-23 03:05:33 +08:00
|
|
|
// void __cxa_bad_typeid();
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(CGF.VoidTy, false);
|
|
|
|
|
|
|
|
return CGF.CGM.CreateRuntimeFunction(FTy, "__cxa_bad_typeid");
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ItaniumCXXABI::shouldTypeidBeNullChecked(bool IsDeref,
|
|
|
|
QualType SrcRecordTy) {
|
|
|
|
return IsDeref;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumCXXABI::EmitBadTypeidCall(CodeGenFunction &CGF) {
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee Fn = getBadTypeidFn(CGF);
|
2019-01-30 10:54:28 +08:00
|
|
|
llvm::CallBase *Call = CGF.EmitRuntimeCallOrInvoke(Fn);
|
|
|
|
Call->setDoesNotReturn();
|
2014-06-23 03:05:33 +08:00
|
|
|
CGF.Builder.CreateUnreachable();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *ItaniumCXXABI::EmitTypeid(CodeGenFunction &CGF,
|
|
|
|
QualType SrcRecordTy,
|
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 ThisPtr,
|
2014-06-23 03:05:33 +08:00
|
|
|
llvm::Type *StdTypeInfoPtrTy) {
|
2015-09-16 05:46:55 +08:00
|
|
|
auto *ClassDecl =
|
2019-10-03 04:45:16 +08:00
|
|
|
cast<CXXRecordDecl>(SrcRecordTy->castAs<RecordType>()->getDecl());
|
2014-06-23 03:05:33 +08:00
|
|
|
llvm::Value *Value =
|
2015-09-16 05:46:55 +08:00
|
|
|
CGF.GetVTablePtr(ThisPtr, StdTypeInfoPtrTy->getPointerTo(), ClassDecl);
|
2014-06-23 03:05:33 +08:00
|
|
|
|
|
|
|
// Load the type info.
|
|
|
|
Value = CGF.Builder.CreateConstInBoundsGEP1_64(Value, -1ULL);
|
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 CGF.Builder.CreateAlignedLoad(Value, CGF.getPointerAlign());
|
2014-06-23 03:05:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool ItaniumCXXABI::shouldDynamicCastCallBeNullChecked(bool SrcIsPtr,
|
|
|
|
QualType SrcRecordTy) {
|
|
|
|
return SrcIsPtr;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *ItaniumCXXABI::EmitDynamicCastCall(
|
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, Address ThisAddr, QualType SrcRecordTy,
|
2014-06-23 03:05:33 +08:00
|
|
|
QualType DestTy, QualType DestRecordTy, llvm::BasicBlock *CastEnd) {
|
|
|
|
llvm::Type *PtrDiffLTy =
|
|
|
|
CGF.ConvertType(CGF.getContext().getPointerDiffType());
|
|
|
|
llvm::Type *DestLTy = CGF.ConvertType(DestTy);
|
|
|
|
|
|
|
|
llvm::Value *SrcRTTI =
|
|
|
|
CGF.CGM.GetAddrOfRTTIDescriptor(SrcRecordTy.getUnqualifiedType());
|
|
|
|
llvm::Value *DestRTTI =
|
|
|
|
CGF.CGM.GetAddrOfRTTIDescriptor(DestRecordTy.getUnqualifiedType());
|
|
|
|
|
|
|
|
// Compute the offset hint.
|
|
|
|
const CXXRecordDecl *SrcDecl = SrcRecordTy->getAsCXXRecordDecl();
|
|
|
|
const CXXRecordDecl *DestDecl = DestRecordTy->getAsCXXRecordDecl();
|
|
|
|
llvm::Value *OffsetHint = llvm::ConstantInt::get(
|
|
|
|
PtrDiffLTy,
|
|
|
|
computeOffsetHint(CGF.getContext(), SrcDecl, DestDecl).getQuantity());
|
|
|
|
|
|
|
|
// Emit the call to __dynamic_cast.
|
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::Value *Value = ThisAddr.getPointer();
|
2014-06-23 03:05:33 +08:00
|
|
|
Value = CGF.EmitCastToVoidPtr(Value);
|
|
|
|
|
|
|
|
llvm::Value *args[] = {Value, SrcRTTI, DestRTTI, OffsetHint};
|
|
|
|
Value = CGF.EmitNounwindRuntimeCall(getItaniumDynamicCastFn(CGF), args);
|
|
|
|
Value = CGF.Builder.CreateBitCast(Value, DestLTy);
|
|
|
|
|
|
|
|
/// C++ [expr.dynamic.cast]p9:
|
|
|
|
/// A failed cast to reference type throws std::bad_cast
|
|
|
|
if (DestTy->isReferenceType()) {
|
|
|
|
llvm::BasicBlock *BadCastBlock =
|
|
|
|
CGF.createBasicBlock("dynamic_cast.bad_cast");
|
|
|
|
|
|
|
|
llvm::Value *IsNull = CGF.Builder.CreateIsNull(Value);
|
|
|
|
CGF.Builder.CreateCondBr(IsNull, BadCastBlock, CastEnd);
|
|
|
|
|
|
|
|
CGF.EmitBlock(BadCastBlock);
|
|
|
|
EmitBadCastCall(CGF);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Value;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *ItaniumCXXABI::EmitDynamicCastToVoid(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 ThisAddr,
|
2014-06-23 03:05:33 +08:00
|
|
|
QualType SrcRecordTy,
|
|
|
|
QualType DestTy) {
|
|
|
|
llvm::Type *PtrDiffLTy =
|
|
|
|
CGF.ConvertType(CGF.getContext().getPointerDiffType());
|
|
|
|
llvm::Type *DestLTy = CGF.ConvertType(DestTy);
|
|
|
|
|
2015-09-16 05:46:55 +08:00
|
|
|
auto *ClassDecl =
|
2019-10-03 04:45:16 +08:00
|
|
|
cast<CXXRecordDecl>(SrcRecordTy->castAs<RecordType>()->getDecl());
|
2014-06-23 03:05:33 +08:00
|
|
|
// Get the vtable pointer.
|
2015-09-16 05:46:55 +08:00
|
|
|
llvm::Value *VTable = CGF.GetVTablePtr(ThisAddr, PtrDiffLTy->getPointerTo(),
|
|
|
|
ClassDecl);
|
2014-06-23 03:05:33 +08:00
|
|
|
|
|
|
|
// Get the offset-to-top from the vtable.
|
|
|
|
llvm::Value *OffsetToTop =
|
|
|
|
CGF.Builder.CreateConstInBoundsGEP1_64(VTable, -2ULL);
|
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
|
|
|
OffsetToTop =
|
|
|
|
CGF.Builder.CreateAlignedLoad(OffsetToTop, CGF.getPointerAlign(),
|
|
|
|
"offset.to.top");
|
2014-06-23 03:05:33 +08:00
|
|
|
|
|
|
|
// Finally, add the offset to 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
|
|
|
llvm::Value *Value = ThisAddr.getPointer();
|
2014-06-23 03:05:33 +08:00
|
|
|
Value = CGF.EmitCastToVoidPtr(Value);
|
|
|
|
Value = CGF.Builder.CreateInBoundsGEP(Value, OffsetToTop);
|
|
|
|
|
|
|
|
return CGF.Builder.CreateBitCast(Value, DestLTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ItaniumCXXABI::EmitBadCastCall(CodeGenFunction &CGF) {
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee Fn = getBadCastFn(CGF);
|
2019-01-30 10:54:28 +08:00
|
|
|
llvm::CallBase *Call = CGF.EmitRuntimeCallOrInvoke(Fn);
|
|
|
|
Call->setDoesNotReturn();
|
2014-06-23 03:05:33 +08:00
|
|
|
CGF.Builder.CreateUnreachable();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-05-30 02:02:47 +08:00
|
|
|
llvm::Value *
|
|
|
|
ItaniumCXXABI::GetVirtualBaseClassOffset(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 This,
|
2013-05-30 02:02:47 +08:00
|
|
|
const CXXRecordDecl *ClassDecl,
|
|
|
|
const CXXRecordDecl *BaseClassDecl) {
|
2015-09-16 05:46:55 +08:00
|
|
|
llvm::Value *VTablePtr = CGF.GetVTablePtr(This, CGM.Int8PtrTy, ClassDecl);
|
2013-05-30 02:02:47 +08:00
|
|
|
CharUnits VBaseOffsetOffset =
|
2013-11-05 23:54:58 +08:00
|
|
|
CGM.getItaniumVTableContext().getVirtualBaseOffsetOffset(ClassDecl,
|
|
|
|
BaseClassDecl);
|
2013-05-30 02:02:47 +08:00
|
|
|
|
|
|
|
llvm::Value *VBaseOffsetPtr =
|
|
|
|
CGF.Builder.CreateConstGEP1_64(VTablePtr, VBaseOffsetOffset.getQuantity(),
|
|
|
|
"vbase.offset.ptr");
|
|
|
|
VBaseOffsetPtr = CGF.Builder.CreateBitCast(VBaseOffsetPtr,
|
|
|
|
CGM.PtrDiffTy->getPointerTo());
|
|
|
|
|
|
|
|
llvm::Value *VBaseOffset =
|
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.Builder.CreateAlignedLoad(VBaseOffsetPtr, CGF.getPointerAlign(),
|
|
|
|
"vbase.offset");
|
2013-05-30 02:02:47 +08:00
|
|
|
|
|
|
|
return VBaseOffset;
|
|
|
|
}
|
|
|
|
|
2013-08-05 01:30:04 +08:00
|
|
|
void ItaniumCXXABI::EmitCXXConstructors(const CXXConstructorDecl *D) {
|
|
|
|
// Just make sure we're in sync with TargetCXXABI.
|
|
|
|
assert(CGM.getTarget().getCXXABI().hasConstructorVariants());
|
|
|
|
|
2013-12-09 22:51:17 +08:00
|
|
|
// The constructor used for constructing this as a base class;
|
|
|
|
// ignores virtual bases.
|
|
|
|
CGM.EmitGlobal(GlobalDecl(D, Ctor_Base));
|
|
|
|
|
2013-08-05 01:30:04 +08:00
|
|
|
// The constructor used for constructing this as a complete class;
|
2015-01-07 13:25:05 +08:00
|
|
|
// constructs the virtual bases, then calls the base constructor.
|
2013-08-05 01:30:04 +08:00
|
|
|
if (!D->getParent()->isAbstract()) {
|
|
|
|
// We don't need to emit the complete ctor if the class is abstract.
|
|
|
|
CGM.EmitGlobal(GlobalDecl(D, Ctor_Complete));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-23 04:28:02 +08:00
|
|
|
CGCXXABI::AddedStructorArgs
|
2019-03-23 07:05:10 +08:00
|
|
|
ItaniumCXXABI::buildStructorSignature(GlobalDecl GD,
|
2014-09-09 00:01:27 +08:00
|
|
|
SmallVectorImpl<CanQualType> &ArgTys) {
|
2010-09-02 18:25:57 +08:00
|
|
|
ASTContext &Context = getContext();
|
2010-08-31 15:33:07 +08:00
|
|
|
|
2014-09-09 00:01:27 +08:00
|
|
|
// All parameters are already in place except VTT, which goes after 'this'.
|
|
|
|
// These are Clang types, so we don't need to worry about sret yet.
|
2010-08-31 15:33:07 +08:00
|
|
|
|
|
|
|
// Check if we need to add a VTT parameter (which has type void **).
|
2019-03-23 07:05:10 +08:00
|
|
|
if ((isa<CXXConstructorDecl>(GD.getDecl()) ? GD.getCtorType() == Ctor_Base
|
|
|
|
: GD.getDtorType() == Dtor_Base) &&
|
|
|
|
cast<CXXMethodDecl>(GD.getDecl())->getParent()->getNumVBases() != 0) {
|
2014-09-09 00:01:27 +08:00
|
|
|
ArgTys.insert(ArgTys.begin() + 1,
|
|
|
|
Context.getPointerType(Context.VoidPtrTy));
|
2017-02-23 04:28:02 +08:00
|
|
|
return AddedStructorArgs::prefix(1);
|
|
|
|
}
|
|
|
|
return AddedStructorArgs{};
|
2010-08-31 15:33:07 +08:00
|
|
|
}
|
|
|
|
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
void ItaniumCXXABI::EmitCXXDestructors(const CXXDestructorDecl *D) {
|
2013-12-09 22:51:17 +08:00
|
|
|
// The destructor used for destructing this as a base class; ignores
|
|
|
|
// virtual bases.
|
|
|
|
CGM.EmitGlobal(GlobalDecl(D, Dtor_Base));
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
|
|
|
|
// The destructor used for destructing this as a most-derived class;
|
|
|
|
// call the base destructor and then destructs any virtual bases.
|
|
|
|
CGM.EmitGlobal(GlobalDecl(D, Dtor_Complete));
|
|
|
|
|
2013-12-09 22:51:17 +08:00
|
|
|
// The destructor in a virtual table is always a 'deleting'
|
|
|
|
// destructor, which calls the complete destructor and then uses the
|
|
|
|
// appropriate operator delete.
|
|
|
|
if (D->isVirtual())
|
|
|
|
CGM.EmitGlobal(GlobalDecl(D, Dtor_Deleting));
|
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
2013-07-22 21:51:44 +08:00
|
|
|
}
|
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
void ItaniumCXXABI::addImplicitStructorParams(CodeGenFunction &CGF,
|
|
|
|
QualType &ResTy,
|
|
|
|
FunctionArgList &Params) {
|
2010-08-31 15:33:07 +08:00
|
|
|
const CXXMethodDecl *MD = cast<CXXMethodDecl>(CGF.CurGD.getDecl());
|
2013-12-18 03:46:40 +08:00
|
|
|
assert(isa<CXXConstructorDecl>(MD) || isa<CXXDestructorDecl>(MD));
|
2010-08-31 15:33:07 +08:00
|
|
|
|
|
|
|
// Check if we need a VTT parameter as well.
|
2013-06-29 04:45:28 +08:00
|
|
|
if (NeedsVTTParameter(CGF.CurGD)) {
|
2010-09-02 18:25:57 +08:00
|
|
|
ASTContext &Context = getContext();
|
2010-08-31 15:33:07 +08:00
|
|
|
|
|
|
|
// FIXME: avoid the fake decl
|
|
|
|
QualType T = Context.getPointerType(Context.VoidPtrTy);
|
2017-06-09 21:40:18 +08:00
|
|
|
auto *VTTDecl = ImplicitParamDecl::Create(
|
|
|
|
Context, /*DC=*/nullptr, MD->getLocation(), &Context.Idents.get("vtt"),
|
|
|
|
T, ImplicitParamDecl::CXXVTT);
|
2013-12-18 03:46:40 +08:00
|
|
|
Params.insert(Params.begin() + 1, VTTDecl);
|
2013-12-13 08:09:59 +08:00
|
|
|
getStructorImplicitParamDecl(CGF) = VTTDecl;
|
2010-08-31 15:33:07 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumCXXABI::EmitInstanceFunctionProlog(CodeGenFunction &CGF) {
|
2016-07-28 06:04:24 +08:00
|
|
|
// Naked functions have no prolog.
|
|
|
|
if (CGF.CurFuncDecl && CGF.CurFuncDecl->hasAttr<NakedAttr>())
|
|
|
|
return;
|
|
|
|
|
[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
|
|
|
/// Initialize the 'this' slot. In the Itanium C++ ABI, no prologue
|
2018-04-06 23:14:32 +08:00
|
|
|
/// adjustments are required, because they are all handled by thunks.
|
[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
|
|
|
setCXXABIThisValue(CGF, loadIncomingCXXThis(CGF));
|
2010-08-31 15:33:07 +08:00
|
|
|
|
|
|
|
/// Initialize the 'vtt' slot if needed.
|
2013-12-13 08:09:59 +08:00
|
|
|
if (getStructorImplicitParamDecl(CGF)) {
|
|
|
|
getStructorImplicitParamValue(CGF) = CGF.Builder.CreateLoad(
|
|
|
|
CGF.GetAddrOfLocalVar(getStructorImplicitParamDecl(CGF)), "vtt");
|
2010-08-31 15:33:07 +08:00
|
|
|
}
|
|
|
|
|
2013-07-01 04:40:16 +08:00
|
|
|
/// If this is a function that the ABI specifies returns 'this', initialize
|
|
|
|
/// the return slot to 'this' at the start of the function.
|
|
|
|
///
|
|
|
|
/// Unlike the setting of return types, this is done within the ABI
|
|
|
|
/// implementation instead of by clients of CGCXXABI because:
|
|
|
|
/// 1) getThisValue is currently protected
|
|
|
|
/// 2) in theory, an ABI could implement 'this' returns some other way;
|
|
|
|
/// HasThisReturn only specifies a contract, not the implementation
|
2010-08-31 15:33:07 +08:00
|
|
|
if (HasThisReturn(CGF.CurGD))
|
2012-02-11 10:57:39 +08:00
|
|
|
CGF.Builder.CreateStore(getThisValue(CGF), CGF.ReturnValue);
|
2010-08-31 15:33:07 +08:00
|
|
|
}
|
|
|
|
|
2017-02-23 04:28:02 +08:00
|
|
|
CGCXXABI::AddedStructorArgs ItaniumCXXABI::addImplicitConstructorArgs(
|
2013-12-18 03:46:40 +08:00
|
|
|
CodeGenFunction &CGF, const CXXConstructorDecl *D, CXXCtorType Type,
|
|
|
|
bool ForVirtualBase, bool Delegating, CallArgList &Args) {
|
|
|
|
if (!NeedsVTTParameter(GlobalDecl(D, Type)))
|
2017-02-23 04:28:02 +08:00
|
|
|
return AddedStructorArgs{};
|
2013-02-27 21:46:31 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
// Insert the implicit 'vtt' argument as the second argument.
|
|
|
|
llvm::Value *VTT =
|
|
|
|
CGF.GetVTTParameter(GlobalDecl(D, Type), ForVirtualBase, Delegating);
|
|
|
|
QualType VTTTy = getContext().getPointerType(getContext().VoidPtrTy);
|
2018-03-15 23:25:19 +08:00
|
|
|
Args.insert(Args.begin() + 1, CallArg(RValue::get(VTT), VTTTy));
|
2017-02-23 04:28:02 +08:00
|
|
|
return AddedStructorArgs::prefix(1); // Added one arg.
|
2013-12-13 08:53:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction &CGF,
|
|
|
|
const CXXDestructorDecl *DD,
|
|
|
|
CXXDtorType Type, bool ForVirtualBase,
|
2019-07-22 17:39:13 +08:00
|
|
|
bool Delegating, Address This,
|
|
|
|
QualType ThisTy) {
|
2013-12-13 08:53:54 +08:00
|
|
|
GlobalDecl GD(DD, Type);
|
|
|
|
llvm::Value *VTT = CGF.GetVTTParameter(GD, ForVirtualBase, Delegating);
|
|
|
|
QualType VTTTy = getContext().getPointerType(getContext().VoidPtrTy);
|
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee Callee;
|
|
|
|
if (getContext().getLangOpts().AppleKext &&
|
|
|
|
Type != Dtor_Base && DD->isVirtual())
|
2013-12-13 08:53:54 +08:00
|
|
|
Callee = CGF.BuildAppleKextVirtualDestructorCall(DD, Type, DD->getParent());
|
2016-10-27 07:46:34 +08:00
|
|
|
else
|
2019-03-23 07:05:10 +08:00
|
|
|
Callee = CGCallee::forDirect(CGM.getAddrOfCXXStructor(GD), GD);
|
2013-12-13 08:53:54 +08:00
|
|
|
|
2019-07-22 17:39:13 +08:00
|
|
|
CGF.EmitCXXDestructorCall(GD, Callee, This.getPointer(), ThisTy, VTT, VTTTy,
|
|
|
|
nullptr);
|
2013-02-27 21:46:31 +08:00
|
|
|
}
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables &CGVT,
|
|
|
|
const CXXRecordDecl *RD) {
|
|
|
|
llvm::GlobalVariable *VTable = getAddrOfVTable(RD, CharUnits());
|
|
|
|
if (VTable->hasInitializer())
|
|
|
|
return;
|
|
|
|
|
2013-11-05 23:54:58 +08:00
|
|
|
ItaniumVTableContext &VTContext = CGM.getItaniumVTableContext();
|
2013-09-27 22:48:01 +08:00
|
|
|
const VTableLayout &VTLayout = VTContext.getVTableLayout(RD);
|
|
|
|
llvm::GlobalVariable::LinkageTypes Linkage = CGM.getVTableLinkage(RD);
|
2014-07-02 04:30:31 +08:00
|
|
|
llvm::Constant *RTTI =
|
|
|
|
CGM.GetAddrOfRTTIDescriptor(CGM.getContext().getTagDeclType(RD));
|
2013-09-27 22:48:01 +08:00
|
|
|
|
|
|
|
// Create and set the initializer.
|
2016-11-29 06:18:33 +08:00
|
|
|
ConstantInitBuilder Builder(CGM);
|
2016-12-14 04:40:39 +08:00
|
|
|
auto Components = Builder.beginStruct();
|
2016-11-29 06:18:33 +08:00
|
|
|
CGVT.createVTableInitializer(Components, VTLayout, RTTI);
|
|
|
|
Components.finishAndSetAsInitializer(VTable);
|
2013-09-27 22:48:01 +08:00
|
|
|
|
|
|
|
// Set the correct linkage.
|
|
|
|
VTable->setLinkage(Linkage);
|
|
|
|
|
2015-05-10 05:10:07 +08:00
|
|
|
if (CGM.supportsCOMDAT() && VTable->isWeakForLinker())
|
|
|
|
VTable->setComdat(CGM.getModule().getOrInsertComdat(VTable->getName()));
|
2015-01-16 07:18:01 +08:00
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
// Set the right visibility.
|
2018-02-08 06:15:33 +08:00
|
|
|
CGM.setGVProperties(VTable, RD);
|
2013-09-27 22:48:01 +08:00
|
|
|
|
|
|
|
// If this is the magic class __cxxabiv1::__fundamental_type_info,
|
|
|
|
// we will emit the typeinfo for the fundamental types. This is the
|
|
|
|
// same behaviour as GCC.
|
|
|
|
const DeclContext *DC = RD->getDeclContext();
|
|
|
|
if (RD->getIdentifier() &&
|
|
|
|
RD->getIdentifier()->isStr("__fundamental_type_info") &&
|
|
|
|
isa<NamespaceDecl>(DC) && cast<NamespaceDecl>(DC)->getIdentifier() &&
|
|
|
|
cast<NamespaceDecl>(DC)->getIdentifier()->isStr("__cxxabiv1") &&
|
|
|
|
DC->getParent()->isTranslationUnit())
|
2018-07-24 08:43:47 +08:00
|
|
|
EmitFundamentalRTTIDescriptors(RD);
|
2015-02-21 04:30:56 +08:00
|
|
|
|
2016-01-23 09:20:18 +08:00
|
|
|
if (!VTable->isDeclarationForLinker())
|
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
2019-10-17 17:58:57 +08:00
|
|
|
CGM.EmitVTableTypeMetadata(RD, VTable, VTLayout);
|
2013-09-27 22:48:01 +08:00
|
|
|
}
|
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
bool ItaniumCXXABI::isVirtualOffsetNeededForVTableField(
|
|
|
|
CodeGenFunction &CGF, CodeGenFunction::VPtr Vptr) {
|
|
|
|
if (Vptr.NearestVBase == nullptr)
|
|
|
|
return false;
|
|
|
|
return NeedsVTTParameter(CGF.CurGD);
|
|
|
|
}
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
llvm::Value *ItaniumCXXABI::getVTableAddressPointInStructor(
|
|
|
|
CodeGenFunction &CGF, const CXXRecordDecl *VTableClass, BaseSubobject Base,
|
2015-09-15 08:37:06 +08:00
|
|
|
const CXXRecordDecl *NearestVBase) {
|
2015-09-11 04:18:30 +08:00
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
if ((Base.getBase()->getNumVBases() || NearestVBase != nullptr) &&
|
|
|
|
NeedsVTTParameter(CGF.CurGD)) {
|
|
|
|
return getVTableAddressPointInStructorWithVTT(CGF, VTableClass, Base,
|
|
|
|
NearestVBase);
|
|
|
|
}
|
|
|
|
return getVTableAddressPoint(Base, VTableClass);
|
2013-09-27 22:48:01 +08:00
|
|
|
}
|
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
llvm::Constant *
|
|
|
|
ItaniumCXXABI::getVTableAddressPoint(BaseSubobject Base,
|
|
|
|
const CXXRecordDecl *VTableClass) {
|
|
|
|
llvm::GlobalValue *VTable = getAddrOfVTable(VTableClass, CharUnits());
|
2013-09-27 22:48:01 +08:00
|
|
|
|
2016-12-14 04:40:39 +08:00
|
|
|
// Find the appropriate vtable within the vtable group, and the address point
|
|
|
|
// within that vtable.
|
|
|
|
VTableLayout::AddressPointLocation AddressPoint =
|
|
|
|
CGM.getItaniumVTableContext()
|
|
|
|
.getVTableLayout(VTableClass)
|
|
|
|
.getAddressPoint(Base);
|
2013-09-27 22:48:01 +08:00
|
|
|
llvm::Value *Indices[] = {
|
2016-03-15 03:07:10 +08:00
|
|
|
llvm::ConstantInt::get(CGM.Int32Ty, 0),
|
2016-12-14 04:40:39 +08:00
|
|
|
llvm::ConstantInt::get(CGM.Int32Ty, AddressPoint.VTableIndex),
|
|
|
|
llvm::ConstantInt::get(CGM.Int32Ty, AddressPoint.AddressPointIndex),
|
2013-09-27 22:48:01 +08:00
|
|
|
};
|
|
|
|
|
2016-12-14 04:50:44 +08:00
|
|
|
return llvm::ConstantExpr::getGetElementPtr(VTable->getValueType(), VTable,
|
|
|
|
Indices, /*InBounds=*/true,
|
|
|
|
/*InRangeIndex=*/1);
|
2013-09-27 22:48:01 +08:00
|
|
|
}
|
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
llvm::Value *ItaniumCXXABI::getVTableAddressPointInStructorWithVTT(
|
|
|
|
CodeGenFunction &CGF, const CXXRecordDecl *VTableClass, BaseSubobject Base,
|
|
|
|
const CXXRecordDecl *NearestVBase) {
|
|
|
|
assert((Base.getBase()->getNumVBases() || NearestVBase != nullptr) &&
|
|
|
|
NeedsVTTParameter(CGF.CurGD) && "This class doesn't have VTT");
|
|
|
|
|
|
|
|
// Get the secondary vpointer index.
|
|
|
|
uint64_t VirtualPointerIndex =
|
|
|
|
CGM.getVTables().getSecondaryVirtualPointerIndex(VTableClass, Base);
|
|
|
|
|
|
|
|
/// Load the VTT.
|
|
|
|
llvm::Value *VTT = CGF.LoadCXXVTT();
|
|
|
|
if (VirtualPointerIndex)
|
|
|
|
VTT = CGF.Builder.CreateConstInBoundsGEP1_64(VTT, VirtualPointerIndex);
|
|
|
|
|
|
|
|
// And load the address point from the VTT.
|
|
|
|
return CGF.Builder.CreateAlignedLoad(VTT, CGF.getPointerAlign());
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *ItaniumCXXABI::getVTableAddressPointForConstExpr(
|
|
|
|
BaseSubobject Base, const CXXRecordDecl *VTableClass) {
|
|
|
|
return getVTableAddressPoint(Base, VTableClass);
|
|
|
|
}
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
llvm::GlobalVariable *ItaniumCXXABI::getAddrOfVTable(const CXXRecordDecl *RD,
|
|
|
|
CharUnits VPtrOffset) {
|
|
|
|
assert(VPtrOffset.isZero() && "Itanium ABI only supports zero vptr offsets");
|
|
|
|
|
|
|
|
llvm::GlobalVariable *&VTable = VTables[RD];
|
|
|
|
if (VTable)
|
|
|
|
return VTable;
|
|
|
|
|
2016-01-29 09:35:53 +08:00
|
|
|
// Queue up this vtable for possible deferred emission.
|
2013-09-27 22:48:01 +08:00
|
|
|
CGM.addDeferredVTable(RD);
|
|
|
|
|
2015-07-29 22:21:47 +08:00
|
|
|
SmallString<256> Name;
|
|
|
|
llvm::raw_svector_ostream Out(Name);
|
2013-10-03 14:26:13 +08:00
|
|
|
getMangleContext().mangleCXXVTable(RD, Out);
|
2013-09-27 22:48:01 +08:00
|
|
|
|
2016-12-14 04:40:39 +08:00
|
|
|
const VTableLayout &VTLayout =
|
|
|
|
CGM.getItaniumVTableContext().getVTableLayout(RD);
|
|
|
|
llvm::Type *VTableType = CGM.getVTables().getVTableType(VTLayout);
|
2013-09-27 22:48:01 +08:00
|
|
|
|
2018-09-12 22:09:06 +08:00
|
|
|
// Use pointer alignment for the vtable. Otherwise we would align them based
|
|
|
|
// on the size of the initializer which doesn't make sense as only single
|
|
|
|
// values are read.
|
|
|
|
unsigned PAlign = CGM.getTarget().getPointerAlign(0);
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
VTable = CGM.CreateOrReplaceCXXRuntimeVariable(
|
2018-09-12 22:09:06 +08:00
|
|
|
Name, VTableType, llvm::GlobalValue::ExternalLinkage,
|
|
|
|
getContext().toCharUnitsFromBits(PAlign).getQuantity());
|
2016-06-15 05:02:05 +08:00
|
|
|
VTable->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
|
2014-06-03 07:13:03 +08:00
|
|
|
|
2018-02-24 03:30:48 +08:00
|
|
|
CGM.setGVProperties(VTable, RD);
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
return VTable;
|
|
|
|
}
|
|
|
|
|
2018-02-07 02:52:44 +08:00
|
|
|
CGCallee ItaniumCXXABI::getVirtualFunctionPointer(CodeGenFunction &CGF,
|
|
|
|
GlobalDecl GD,
|
|
|
|
Address This,
|
|
|
|
llvm::Type *Ty,
|
|
|
|
SourceLocation Loc) {
|
2013-08-21 14:25:03 +08:00
|
|
|
Ty = Ty->getPointerTo()->getPointerTo();
|
2015-09-16 05:46:55 +08:00
|
|
|
auto *MethodDecl = cast<CXXMethodDecl>(GD.getDecl());
|
|
|
|
llvm::Value *VTable = CGF.GetVTablePtr(This, Ty, MethodDecl->getParent());
|
2013-08-21 14:25:03 +08:00
|
|
|
|
2013-11-05 23:54:58 +08:00
|
|
|
uint64_t VTableIndex = CGM.getItaniumVTableContext().getMethodVTableIndex(GD);
|
2018-02-07 02:52:44 +08:00
|
|
|
llvm::Value *VFunc;
|
|
|
|
if (CGF.ShouldEmitVTableTypeCheckedLoad(MethodDecl->getParent())) {
|
|
|
|
VFunc = CGF.EmitVTableTypeCheckedLoad(
|
2016-06-25 08:24:06 +08:00
|
|
|
MethodDecl->getParent(), VTable,
|
|
|
|
VTableIndex * CGM.getContext().getTargetInfo().getPointerWidth(0) / 8);
|
2018-02-07 02:52:44 +08:00
|
|
|
} else {
|
|
|
|
CGF.EmitTypeMetadataCodeForVCall(MethodDecl->getParent(), VTable, Loc);
|
|
|
|
|
|
|
|
llvm::Value *VFuncPtr =
|
|
|
|
CGF.Builder.CreateConstInBoundsGEP1_64(VTable, VTableIndex, "vfn");
|
|
|
|
auto *VFuncLoad =
|
|
|
|
CGF.Builder.CreateAlignedLoad(VFuncPtr, CGF.getPointerAlign());
|
|
|
|
|
|
|
|
// Add !invariant.load md to virtual function load to indicate that
|
|
|
|
// function didn't change inside vtable.
|
|
|
|
// It's safe to add it without -fstrict-vtable-pointers, but it would not
|
|
|
|
// help in devirtualization because it will only matter if we will have 2
|
|
|
|
// the same virtual function loads from the same vtable load, which won't
|
|
|
|
// happen without enabled devirtualization with -fstrict-vtable-pointers.
|
|
|
|
if (CGM.getCodeGenOpts().OptimizationLevel > 0 &&
|
|
|
|
CGM.getCodeGenOpts().StrictVTablePointers)
|
|
|
|
VFuncLoad->setMetadata(
|
|
|
|
llvm::LLVMContext::MD_invariant_load,
|
|
|
|
llvm::MDNode::get(CGM.getLLVMContext(),
|
|
|
|
llvm::ArrayRef<llvm::Metadata *>()));
|
|
|
|
VFunc = VFuncLoad;
|
|
|
|
}
|
2016-10-27 07:46:34 +08:00
|
|
|
|
2018-11-13 23:48:08 +08:00
|
|
|
CGCallee Callee(GD, VFunc);
|
2018-02-07 02:52:44 +08:00
|
|
|
return Callee;
|
2013-08-21 14:25:03 +08:00
|
|
|
}
|
|
|
|
|
2014-11-01 04:09:12 +08:00
|
|
|
llvm::Value *ItaniumCXXABI::EmitVirtualDestructorCall(
|
|
|
|
CodeGenFunction &CGF, const CXXDestructorDecl *Dtor, CXXDtorType DtorType,
|
2019-07-22 17:39:13 +08:00
|
|
|
Address This, DeleteOrMemberCallExpr E) {
|
|
|
|
auto *CE = E.dyn_cast<const CXXMemberCallExpr *>();
|
|
|
|
auto *D = E.dyn_cast<const CXXDeleteExpr *>();
|
|
|
|
assert((CE != nullptr) ^ (D != nullptr));
|
2014-08-26 04:17:35 +08:00
|
|
|
assert(CE == nullptr || CE->arg_begin() == CE->arg_end());
|
2013-02-15 22:45:22 +08:00
|
|
|
assert(DtorType == Dtor_Deleting || DtorType == Dtor_Complete);
|
|
|
|
|
2019-03-23 07:05:10 +08:00
|
|
|
GlobalDecl GD(Dtor, DtorType);
|
|
|
|
const CGFunctionInfo *FInfo =
|
|
|
|
&CGM.getTypes().arrangeCXXStructorDeclaration(GD);
|
2018-03-01 13:43:23 +08:00
|
|
|
llvm::FunctionType *Ty = CGF.CGM.getTypes().GetFunctionType(*FInfo);
|
2019-03-23 07:05:10 +08:00
|
|
|
CGCallee Callee = CGCallee::forVirtual(CE, GD, This, Ty);
|
2013-02-15 22:45:22 +08:00
|
|
|
|
2019-07-22 17:39:13 +08:00
|
|
|
QualType ThisTy;
|
|
|
|
if (CE) {
|
|
|
|
ThisTy = CE->getObjectType();
|
|
|
|
} else {
|
|
|
|
ThisTy = D->getDestroyedType();
|
|
|
|
}
|
|
|
|
|
|
|
|
CGF.EmitCXXDestructorCall(GD, Callee, This.getPointer(), ThisTy, nullptr,
|
|
|
|
QualType(), nullptr);
|
2014-11-01 04:09:12 +08:00
|
|
|
return nullptr;
|
2013-02-15 22:45:22 +08:00
|
|
|
}
|
|
|
|
|
2013-09-27 22:48:01 +08:00
|
|
|
void ItaniumCXXABI::emitVirtualInheritanceTables(const CXXRecordDecl *RD) {
|
2013-06-19 23:20:38 +08:00
|
|
|
CodeGenVTables &VTables = CGM.getVTables();
|
|
|
|
llvm::GlobalVariable *VTT = VTables.GetAddrOfVTT(RD);
|
2013-09-27 22:48:01 +08:00
|
|
|
VTables.EmitVTTDefinition(VTT, CGM.getVTableLinkage(RD), RD);
|
2013-06-19 23:20:38 +08:00
|
|
|
}
|
|
|
|
|
2018-11-28 03:33:49 +08:00
|
|
|
bool ItaniumCXXABI::canSpeculativelyEmitVTableAsBaseClass(
|
|
|
|
const CXXRecordDecl *RD) const {
|
2015-07-24 12:04:49 +08:00
|
|
|
// We don't emit available_externally vtables if we are in -fapple-kext mode
|
|
|
|
// because kext mode does not permit devirtualization.
|
|
|
|
if (CGM.getLangOpts().AppleKext)
|
|
|
|
return false;
|
|
|
|
|
2018-06-13 21:55:42 +08:00
|
|
|
// If the vtable is hidden then it is not safe to emit an available_externally
|
|
|
|
// copy of vtable.
|
|
|
|
if (isVTableHidden(RD))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (CGM.getCodeGenOpts().ForceEmitVTables)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If we don't have any not emitted inline virtual function then we are safe
|
|
|
|
// to emit an available_externally copy of vtable.
|
2015-07-24 12:04:49 +08:00
|
|
|
// FIXME we can still emit a copy of the vtable if we
|
|
|
|
// can emit definition of the inline functions.
|
2018-11-28 03:33:49 +08:00
|
|
|
if (hasAnyUnusedVirtualInlineFunction(RD))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// For a class with virtual bases, we must also be able to speculatively
|
|
|
|
// emit the VTT, because CodeGen doesn't have separate notions of "can emit
|
|
|
|
// the vtable" and "can emit the VTT". For a base subobject, this means we
|
|
|
|
// need to be able to emit non-virtual base vtables.
|
|
|
|
if (RD->getNumVBases()) {
|
|
|
|
for (const auto &B : RD->bases()) {
|
|
|
|
auto *BRD = B.getType()->getAsCXXRecordDecl();
|
|
|
|
assert(BRD && "no class for base specifier");
|
|
|
|
if (B.isVirtual() || !BRD->isDynamicClass())
|
|
|
|
continue;
|
|
|
|
if (!canSpeculativelyEmitVTableAsBaseClass(BRD))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ItaniumCXXABI::canSpeculativelyEmitVTable(const CXXRecordDecl *RD) const {
|
|
|
|
if (!canSpeculativelyEmitVTableAsBaseClass(RD))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// For a complete-object vtable (or more specifically, for the VTT), we need
|
|
|
|
// to be able to speculatively emit the vtables of all dynamic virtual bases.
|
|
|
|
for (const auto &B : RD->vbases()) {
|
|
|
|
auto *BRD = B.getType()->getAsCXXRecordDecl();
|
|
|
|
assert(BRD && "no class for base specifier");
|
|
|
|
if (!BRD->isDynamicClass())
|
|
|
|
continue;
|
|
|
|
if (!canSpeculativelyEmitVTableAsBaseClass(BRD))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2015-07-24 12:04:49 +08:00
|
|
|
}
|
2013-10-30 19:55:43 +08:00
|
|
|
static llvm::Value *performTypeAdjustment(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 InitialPtr,
|
2013-10-30 19:55:43 +08:00
|
|
|
int64_t NonVirtualAdjustment,
|
|
|
|
int64_t VirtualAdjustment,
|
|
|
|
bool IsReturnAdjustment) {
|
|
|
|
if (!NonVirtualAdjustment && !VirtualAdjustment)
|
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 InitialPtr.getPointer();
|
2013-10-30 19:55:43 +08:00
|
|
|
|
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 V = CGF.Builder.CreateElementBitCast(InitialPtr, CGF.Int8Ty);
|
2013-10-30 19:55:43 +08:00
|
|
|
|
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
|
|
|
// In a base-to-derived cast, the non-virtual adjustment is applied first.
|
2013-10-30 19:55:43 +08:00
|
|
|
if (NonVirtualAdjustment && !IsReturnAdjustment) {
|
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
|
|
|
V = CGF.Builder.CreateConstInBoundsByteGEP(V,
|
|
|
|
CharUnits::fromQuantity(NonVirtualAdjustment));
|
2013-10-30 19:55:43 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
// Perform the virtual adjustment if we have one.
|
|
|
|
llvm::Value *ResultPtr;
|
2013-10-30 19:55:43 +08:00
|
|
|
if (VirtualAdjustment) {
|
|
|
|
llvm::Type *PtrDiffTy =
|
|
|
|
CGF.ConvertType(CGF.getContext().getPointerDiffType());
|
|
|
|
|
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 VTablePtrPtr = CGF.Builder.CreateElementBitCast(V, CGF.Int8PtrTy);
|
2013-10-30 19:55:43 +08:00
|
|
|
llvm::Value *VTablePtr = CGF.Builder.CreateLoad(VTablePtrPtr);
|
|
|
|
|
|
|
|
llvm::Value *OffsetPtr =
|
|
|
|
CGF.Builder.CreateConstInBoundsGEP1_64(VTablePtr, VirtualAdjustment);
|
|
|
|
|
|
|
|
OffsetPtr = CGF.Builder.CreateBitCast(OffsetPtr, PtrDiffTy->getPointerTo());
|
|
|
|
|
|
|
|
// Load the adjustment offset from the vtable.
|
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::Value *Offset =
|
|
|
|
CGF.Builder.CreateAlignedLoad(OffsetPtr, CGF.getPointerAlign());
|
2013-10-30 19:55:43 +08:00
|
|
|
|
|
|
|
// Adjust our 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
|
|
|
ResultPtr = CGF.Builder.CreateInBoundsGEP(V.getPointer(), Offset);
|
|
|
|
} else {
|
|
|
|
ResultPtr = V.getPointer();
|
2013-10-30 19:55:43 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
// In a derived-to-base conversion, the non-virtual adjustment is
|
|
|
|
// applied second.
|
2013-10-30 19:55:43 +08:00
|
|
|
if (NonVirtualAdjustment && IsReturnAdjustment) {
|
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
|
|
|
ResultPtr = CGF.Builder.CreateConstInBoundsGEP1_64(ResultPtr,
|
|
|
|
NonVirtualAdjustment);
|
2013-10-30 19:55:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Cast back to the original type.
|
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 CGF.Builder.CreateBitCast(ResultPtr, InitialPtr.getType());
|
2013-10-30 19:55:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *ItaniumCXXABI::performThisAdjustment(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 This,
|
2013-10-30 19:55:43 +08:00
|
|
|
const ThisAdjustment &TA) {
|
2013-11-06 14:24:31 +08:00
|
|
|
return performTypeAdjustment(CGF, This, TA.NonVirtual,
|
|
|
|
TA.Virtual.Itanium.VCallOffsetOffset,
|
2013-10-30 19:55:43 +08:00
|
|
|
/*IsReturnAdjustment=*/false);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *
|
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
|
|
|
ItaniumCXXABI::performReturnAdjustment(CodeGenFunction &CGF, Address Ret,
|
2013-10-30 19:55:43 +08:00
|
|
|
const ReturnAdjustment &RA) {
|
|
|
|
return performTypeAdjustment(CGF, Ret, RA.NonVirtual,
|
|
|
|
RA.Virtual.Itanium.VBaseOffsetOffset,
|
|
|
|
/*IsReturnAdjustment=*/true);
|
|
|
|
}
|
|
|
|
|
2010-08-31 15:33:07 +08:00
|
|
|
void ARMCXXABI::EmitReturnFromThunk(CodeGenFunction &CGF,
|
|
|
|
RValue RV, QualType ResultType) {
|
|
|
|
if (!isa<CXXDestructorDecl>(CGF.CurGD.getDecl()))
|
|
|
|
return ItaniumCXXABI::EmitReturnFromThunk(CGF, RV, ResultType);
|
|
|
|
|
|
|
|
// Destructor thunks in the ARM ABI have indeterminate results.
|
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 *T = CGF.ReturnValue.getElementType();
|
2010-08-31 15:33:07 +08:00
|
|
|
RValue Undef = RValue::get(llvm::UndefValue::get(T));
|
|
|
|
return ItaniumCXXABI::EmitReturnFromThunk(CGF, Undef, ResultType);
|
|
|
|
}
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
/************************** Array allocation cookies **************************/
|
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
CharUnits ItaniumCXXABI::getArrayCookieSizeImpl(QualType elementType) {
|
|
|
|
// The array cookie is a size_t; pad that up to the element alignment.
|
|
|
|
// The cookie is actually right-justified in that space.
|
|
|
|
return std::max(CharUnits::fromQuantity(CGM.SizeSizeInBytes),
|
|
|
|
CGM.getContext().getTypeAlignInChars(elementType));
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
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 ItaniumCXXABI::InitializeArrayCookie(CodeGenFunction &CGF,
|
|
|
|
Address NewPtr,
|
|
|
|
llvm::Value *NumElements,
|
|
|
|
const CXXNewExpr *expr,
|
|
|
|
QualType ElementType) {
|
2012-05-01 13:23:51 +08:00
|
|
|
assert(requiresArrayCookie(expr));
|
2010-09-02 17:58:18 +08:00
|
|
|
|
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
|
|
|
unsigned AS = NewPtr.getAddressSpace();
|
2010-09-02 17:58:18 +08:00
|
|
|
|
2010-09-02 18:25:57 +08:00
|
|
|
ASTContext &Ctx = getContext();
|
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
|
|
|
CharUnits SizeSize = CGF.getSizeSize();
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// The size of the cookie.
|
|
|
|
CharUnits CookieSize =
|
|
|
|
std::max(SizeSize, Ctx.getTypeAlignInChars(ElementType));
|
2012-05-01 13:23:51 +08:00
|
|
|
assert(CookieSize == getArrayCookieSizeImpl(ElementType));
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// Compute an offset to the cookie.
|
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 CookiePtr = NewPtr;
|
2010-09-02 17:58:18 +08:00
|
|
|
CharUnits CookieOffset = CookieSize - SizeSize;
|
|
|
|
if (!CookieOffset.isZero())
|
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
|
|
|
CookiePtr = CGF.Builder.CreateConstInBoundsByteGEP(CookiePtr, CookieOffset);
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// Write the number of elements into the appropriate slot.
|
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 NumElementsPtr =
|
|
|
|
CGF.Builder.CreateElementBitCast(CookiePtr, CGF.SizeTy);
|
2014-08-26 10:29:59 +08:00
|
|
|
llvm::Instruction *SI = CGF.Builder.CreateStore(NumElements, NumElementsPtr);
|
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
|
|
|
|
|
|
|
// Handle the array cookie specially in ASan.
|
2018-01-02 21:46:12 +08:00
|
|
|
if (CGM.getLangOpts().Sanitize.has(SanitizerKind::Address) && AS == 0 &&
|
2018-02-12 19:49:02 +08:00
|
|
|
(expr->getOperatorNew()->isReplaceableGlobalAllocationFunction() ||
|
2018-11-03 01:29:04 +08:00
|
|
|
CGM.getCodeGenOpts().SanitizeAddressPoisonCustomArrayCookie)) {
|
2014-08-29 09:01:32 +08:00
|
|
|
// The store to the CookiePtr does not need to be instrumented.
|
2014-08-26 10:29:59 +08:00
|
|
|
CGM.getSanitizerMetadata()->disableSanitizerForInstruction(SI);
|
|
|
|
llvm::FunctionType *FTy =
|
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::FunctionType::get(CGM.VoidTy, NumElementsPtr.getType(), false);
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee F =
|
2014-08-26 10:29:59 +08:00
|
|
|
CGM.CreateRuntimeFunction(FTy, "__asan_poison_cxx_array_cookie");
|
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.Builder.CreateCall(F, NumElementsPtr.getPointer());
|
2014-08-26 10:29:59 +08:00
|
|
|
}
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// Finally, compute a pointer to the actual data buffer by skipping
|
|
|
|
// over the cookie completely.
|
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 CGF.Builder.CreateConstInBoundsByteGEP(NewPtr, CookieSize);
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
llvm::Value *ItaniumCXXABI::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 allocPtr,
|
2012-05-01 13:23:51 +08:00
|
|
|
CharUnits cookieSize) {
|
|
|
|
// The element size is right-justified in the cookie.
|
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 numElementsPtr = allocPtr;
|
|
|
|
CharUnits numElementsOffset = cookieSize - CGF.getSizeSize();
|
2012-05-01 13:23:51 +08:00
|
|
|
if (!numElementsOffset.isZero())
|
|
|
|
numElementsPtr =
|
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.Builder.CreateConstInBoundsByteGEP(numElementsPtr, numElementsOffset);
|
2010-09-02 17:58:18 +08:00
|
|
|
|
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
|
|
|
unsigned AS = allocPtr.getAddressSpace();
|
|
|
|
numElementsPtr = CGF.Builder.CreateElementBitCast(numElementsPtr, CGF.SizeTy);
|
2014-11-08 06:29:38 +08:00
|
|
|
if (!CGM.getLangOpts().Sanitize.has(SanitizerKind::Address) || AS != 0)
|
2014-08-29 09:01:32 +08:00
|
|
|
return CGF.Builder.CreateLoad(numElementsPtr);
|
|
|
|
// In asan mode emit a function call instead of a regular load and let the
|
|
|
|
// run-time deal with it: if the shadow is properly poisoned return the
|
|
|
|
// cookie, otherwise return 0 to avoid an infinite loop calling DTORs.
|
|
|
|
// We can't simply ignore this load using nosanitize metadata because
|
|
|
|
// the metadata may be lost.
|
|
|
|
llvm::FunctionType *FTy =
|
|
|
|
llvm::FunctionType::get(CGF.SizeTy, CGF.SizeTy->getPointerTo(0), false);
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee F =
|
2014-08-29 09:01:32 +08:00
|
|
|
CGM.CreateRuntimeFunction(FTy, "__asan_load_cxx_array_cookie");
|
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 CGF.Builder.CreateCall(F, numElementsPtr.getPointer());
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
CharUnits ARMCXXABI::getArrayCookieSizeImpl(QualType elementType) {
|
2013-01-26 07:36:19 +08:00
|
|
|
// ARM says that the cookie is always:
|
2010-09-02 17:58:18 +08:00
|
|
|
// struct array_cookie {
|
|
|
|
// std::size_t element_size; // element_size != 0
|
|
|
|
// std::size_t element_count;
|
|
|
|
// };
|
2013-01-26 07:36:19 +08:00
|
|
|
// But the base ABI doesn't give anything an alignment greater than
|
|
|
|
// 8, so we can dismiss this as typical ABI-author blindness to
|
|
|
|
// actual language complexity and round up to the element alignment.
|
|
|
|
return std::max(CharUnits::fromQuantity(2 * CGM.SizeSizeInBytes),
|
|
|
|
CGM.getContext().getTypeAlignInChars(elementType));
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
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 ARMCXXABI::InitializeArrayCookie(CodeGenFunction &CGF,
|
|
|
|
Address newPtr,
|
|
|
|
llvm::Value *numElements,
|
|
|
|
const CXXNewExpr *expr,
|
|
|
|
QualType elementType) {
|
2012-05-01 13:23:51 +08:00
|
|
|
assert(requiresArrayCookie(expr));
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// The cookie is always at the start of the buffer.
|
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 cookie = newPtr;
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// The first element is the element size.
|
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
|
|
|
cookie = CGF.Builder.CreateElementBitCast(cookie, CGF.SizeTy);
|
2013-01-26 07:36:19 +08:00
|
|
|
llvm::Value *elementSize = llvm::ConstantInt::get(CGF.SizeTy,
|
|
|
|
getContext().getTypeSizeInChars(elementType).getQuantity());
|
|
|
|
CGF.Builder.CreateStore(elementSize, cookie);
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// The second element is the element count.
|
2019-02-10 06:22:28 +08:00
|
|
|
cookie = CGF.Builder.CreateConstInBoundsGEP(cookie, 1);
|
2013-01-26 07:36:19 +08:00
|
|
|
CGF.Builder.CreateStore(numElements, cookie);
|
2010-09-02 17:58:18 +08:00
|
|
|
|
|
|
|
// Finally, compute a pointer to the actual data buffer by skipping
|
|
|
|
// over the cookie completely.
|
2013-01-26 07:36:19 +08:00
|
|
|
CharUnits cookieSize = ARMCXXABI::getArrayCookieSizeImpl(elementType);
|
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 CGF.Builder.CreateConstInBoundsByteGEP(newPtr, cookieSize);
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
2012-05-01 13:23:51 +08:00
|
|
|
llvm::Value *ARMCXXABI::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 allocPtr,
|
2012-05-01 13:23:51 +08:00
|
|
|
CharUnits cookieSize) {
|
|
|
|
// The number of elements is at offset sizeof(size_t) relative to
|
|
|
|
// the allocated 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
|
|
|
Address numElementsPtr
|
|
|
|
= CGF.Builder.CreateConstInBoundsByteGEP(allocPtr, CGF.getSizeSize());
|
2010-09-02 17:58:18 +08:00
|
|
|
|
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
|
|
|
numElementsPtr = CGF.Builder.CreateElementBitCast(numElementsPtr, CGF.SizeTy);
|
2012-05-01 13:23:51 +08:00
|
|
|
return CGF.Builder.CreateLoad(numElementsPtr);
|
2010-09-02 17:58:18 +08:00
|
|
|
}
|
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
/*********************** Static local initialization **************************/
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getGuardAcquireFn(CodeGenModule &CGM,
|
|
|
|
llvm::PointerType *GuardPtrTy) {
|
2010-09-08 09:44:27 +08:00
|
|
|
// int __cxa_guard_acquire(__guard *guard_object);
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::FunctionType *FTy =
|
2010-09-08 09:44:27 +08:00
|
|
|
llvm::FunctionType::get(CGM.getTypes().ConvertType(CGM.getContext().IntTy),
|
2011-07-29 21:56:53 +08:00
|
|
|
GuardPtrTy, /*isVarArg=*/false);
|
2017-03-22 00:57:30 +08:00
|
|
|
return CGM.CreateRuntimeFunction(
|
|
|
|
FTy, "__cxa_guard_acquire",
|
|
|
|
llvm::AttributeList::get(CGM.getLLVMContext(),
|
|
|
|
llvm::AttributeList::FunctionIndex,
|
|
|
|
llvm::Attribute::NoUnwind));
|
2010-09-08 09:44:27 +08:00
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getGuardReleaseFn(CodeGenModule &CGM,
|
|
|
|
llvm::PointerType *GuardPtrTy) {
|
2010-09-08 09:44:27 +08:00
|
|
|
// void __cxa_guard_release(__guard *guard_object);
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::FunctionType *FTy =
|
2012-02-07 08:39:47 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, GuardPtrTy, /*isVarArg=*/false);
|
2017-03-22 00:57:30 +08:00
|
|
|
return CGM.CreateRuntimeFunction(
|
|
|
|
FTy, "__cxa_guard_release",
|
|
|
|
llvm::AttributeList::get(CGM.getLLVMContext(),
|
|
|
|
llvm::AttributeList::FunctionIndex,
|
|
|
|
llvm::Attribute::NoUnwind));
|
2010-09-08 09:44:27 +08:00
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getGuardAbortFn(CodeGenModule &CGM,
|
|
|
|
llvm::PointerType *GuardPtrTy) {
|
2010-09-08 09:44:27 +08:00
|
|
|
// void __cxa_guard_abort(__guard *guard_object);
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::FunctionType *FTy =
|
2012-02-07 08:39:47 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, GuardPtrTy, /*isVarArg=*/false);
|
2017-03-22 00:57:30 +08:00
|
|
|
return CGM.CreateRuntimeFunction(
|
|
|
|
FTy, "__cxa_guard_abort",
|
|
|
|
llvm::AttributeList::get(CGM.getLLVMContext(),
|
|
|
|
llvm::AttributeList::FunctionIndex,
|
|
|
|
llvm::Attribute::NoUnwind));
|
2010-09-08 09:44:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
namespace {
|
2015-08-19 06:40:54 +08:00
|
|
|
struct CallGuardAbort final : EHScopeStack::Cleanup {
|
2010-09-08 09:44:27 +08:00
|
|
|
llvm::GlobalVariable *Guard;
|
2012-03-31 03:44:53 +08:00
|
|
|
CallGuardAbort(llvm::GlobalVariable *Guard) : Guard(Guard) {}
|
2010-09-08 09:44:27 +08:00
|
|
|
|
2014-03-12 14:41:41 +08:00
|
|
|
void Emit(CodeGenFunction &CGF, Flags flags) override {
|
2013-03-01 03:01:20 +08:00
|
|
|
CGF.EmitNounwindRuntimeCall(getGuardAbortFn(CGF.CGM, Guard->getType()),
|
|
|
|
Guard);
|
2010-09-08 09:44:27 +08:00
|
|
|
}
|
|
|
|
};
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
2010-09-08 09:44:27 +08:00
|
|
|
|
|
|
|
/// The ARM code here follows the Itanium code closely enough that we
|
|
|
|
/// just special-case it at particular places.
|
2010-11-06 17:44:32 +08:00
|
|
|
void ItaniumCXXABI::EmitGuardedInit(CodeGenFunction &CGF,
|
|
|
|
const VarDecl &D,
|
2012-03-31 05:00:39 +08:00
|
|
|
llvm::GlobalVariable *var,
|
|
|
|
bool shouldPerformInit) {
|
2010-09-08 09:44:27 +08:00
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
2010-11-06 17:44:32 +08:00
|
|
|
|
2016-06-25 08:15:56 +08:00
|
|
|
// Inline variables that weren't instantiated from variable templates have
|
|
|
|
// partially-ordered initialization within their translation unit.
|
|
|
|
bool NonTemplateInline =
|
|
|
|
D.isInline() &&
|
|
|
|
!isTemplateInstantiation(D.getTemplateSpecializationKind());
|
|
|
|
|
|
|
|
// We only need to use thread-safe statics for local non-TLS variables and
|
|
|
|
// inline variables; other global initialization is always single-threaded
|
|
|
|
// or (through lazy dynamic loading in multiple threads) unsequenced.
|
2013-04-15 07:01:42 +08:00
|
|
|
bool threadsafe = getContext().getLangOpts().ThreadsafeStatics &&
|
2016-06-25 08:15:56 +08:00
|
|
|
(D.isLocalVarDecl() || NonTemplateInline) &&
|
|
|
|
!D.getTLSKind();
|
2011-04-27 12:37:08 +08:00
|
|
|
|
|
|
|
// If we have a global variable with internal linkage and thread-safe statics
|
|
|
|
// are disabled, we can just let the guard variable be of type i8.
|
2012-03-31 05:00:39 +08:00
|
|
|
bool useInt8GuardVariable = !threadsafe && var->hasInternalLinkage();
|
|
|
|
|
|
|
|
llvm::IntegerType *guardTy;
|
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
|
|
|
CharUnits guardAlignment;
|
2011-06-17 15:33:57 +08:00
|
|
|
if (useInt8GuardVariable) {
|
2012-03-31 05:00:39 +08:00
|
|
|
guardTy = CGF.Int8Ty;
|
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
|
|
|
guardAlignment = CharUnits::One();
|
2011-06-17 15:33:57 +08:00
|
|
|
} else {
|
2013-01-31 20:13:10 +08:00
|
|
|
// Guard variables are 64 bits in the generic ABI and size width on ARM
|
|
|
|
// (i.e. 32-bit on AArch32, 64-bit on AArch64).
|
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
|
|
|
if (UseARMGuardVarABI) {
|
|
|
|
guardTy = CGF.SizeTy;
|
|
|
|
guardAlignment = CGF.getSizeAlign();
|
|
|
|
} else {
|
|
|
|
guardTy = CGF.Int64Ty;
|
|
|
|
guardAlignment = CharUnits::fromQuantity(
|
|
|
|
CGM.getDataLayout().getABITypeAlignment(guardTy));
|
|
|
|
}
|
2012-03-31 05:00:39 +08:00
|
|
|
}
|
|
|
|
llvm::PointerType *guardPtrTy = guardTy->getPointerTo();
|
|
|
|
|
|
|
|
// Create the guard variable if we don't already have it (as we
|
|
|
|
// might if we're double-emitting this function body).
|
|
|
|
llvm::GlobalVariable *guard = CGM.getStaticLocalDeclGuardAddress(&D);
|
|
|
|
if (!guard) {
|
|
|
|
// Mangle the name for the guard.
|
|
|
|
SmallString<256> guardName;
|
|
|
|
{
|
|
|
|
llvm::raw_svector_ostream out(guardName);
|
2013-09-11 04:14:30 +08:00
|
|
|
getMangleContext().mangleStaticGuardVariable(&D, out);
|
2012-03-31 05:00:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create the guard variable with a zero-initializer.
|
|
|
|
// Just absorb linkage and visibility from the guarded variable.
|
|
|
|
guard = new llvm::GlobalVariable(CGM.getModule(), guardTy,
|
|
|
|
false, var->getLinkage(),
|
|
|
|
llvm::ConstantInt::get(guardTy, 0),
|
|
|
|
guardName.str());
|
2018-02-08 06:15:33 +08:00
|
|
|
guard->setDSOLocal(var->isDSOLocal());
|
2012-03-31 05:00:39 +08:00
|
|
|
guard->setVisibility(var->getVisibility());
|
2013-04-15 07:01:42 +08:00
|
|
|
// If the variable is thread-local, so is its guard variable.
|
|
|
|
guard->setThreadLocalMode(var->getThreadLocalMode());
|
2019-10-03 21:00:29 +08:00
|
|
|
guard->setAlignment(guardAlignment.getAsAlign());
|
2012-03-31 05:00:39 +08:00
|
|
|
|
2015-09-04 04:33:29 +08:00
|
|
|
// The ABI says: "It is suggested that it be emitted in the same COMDAT
|
|
|
|
// group as the associated data object." In practice, this doesn't work for
|
2017-01-18 05:46:38 +08:00
|
|
|
// non-ELF and non-Wasm object formats, so only do it for ELF and Wasm.
|
2015-01-13 06:13:53 +08:00
|
|
|
llvm::Comdat *C = var->getComdat();
|
2015-09-04 04:33:29 +08:00
|
|
|
if (!D.isLocalVarDecl() && C &&
|
2017-01-18 05:46:38 +08:00
|
|
|
(CGM.getTarget().getTriple().isOSBinFormatELF() ||
|
|
|
|
CGM.getTarget().getTriple().isOSBinFormatWasm())) {
|
2014-09-20 03:43:18 +08:00
|
|
|
guard->setComdat(C);
|
2016-06-25 08:15:56 +08:00
|
|
|
// An inline variable's guard function is run from the per-TU
|
|
|
|
// initialization function, not via a dedicated global ctor function, so
|
|
|
|
// we can't put it in a comdat.
|
|
|
|
if (!NonTemplateInline)
|
|
|
|
CGF.CurFn->setComdat(C);
|
2015-05-10 05:10:07 +08:00
|
|
|
} else if (CGM.supportsCOMDAT() && guard->isWeakForLinker()) {
|
|
|
|
guard->setComdat(CGM.getModule().getOrInsertComdat(guard->getName()));
|
2014-09-20 03:43:18 +08:00
|
|
|
}
|
|
|
|
|
2012-03-31 05:00:39 +08:00
|
|
|
CGM.setStaticLocalDeclGuardAddress(&D, guard);
|
2011-04-27 12:37:08 +08:00
|
|
|
}
|
2010-09-08 09:44:27 +08:00
|
|
|
|
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 guardAddr = Address(guard, guardAlignment);
|
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
// Test whether the variable has completed initialization.
|
2014-04-23 09:50:10 +08:00
|
|
|
//
|
2010-09-08 09:44:27 +08:00
|
|
|
// Itanium C++ ABI 3.3.2:
|
|
|
|
// The following is pseudo-code showing how these functions can be used:
|
|
|
|
// if (obj_guard.first_byte == 0) {
|
|
|
|
// if ( __cxa_guard_acquire (&obj_guard) ) {
|
|
|
|
// try {
|
|
|
|
// ... initialize the object ...;
|
|
|
|
// } catch (...) {
|
|
|
|
// __cxa_guard_abort (&obj_guard);
|
|
|
|
// throw;
|
|
|
|
// }
|
|
|
|
// ... queue object destructor with __cxa_atexit() ...;
|
|
|
|
// __cxa_guard_release (&obj_guard);
|
|
|
|
// }
|
|
|
|
// }
|
2014-03-29 23:09:45 +08:00
|
|
|
|
2014-04-23 09:50:10 +08:00
|
|
|
// Load the first byte of the guard variable.
|
|
|
|
llvm::LoadInst *LI =
|
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
|
|
|
Builder.CreateLoad(Builder.CreateElementBitCast(guardAddr, CGM.Int8Ty));
|
2014-04-23 09:50:10 +08:00
|
|
|
|
|
|
|
// Itanium ABI:
|
|
|
|
// An implementation supporting thread-safety on multiprocessor
|
|
|
|
// systems must also guarantee that references to the initialized
|
|
|
|
// object do not occur before the load of the initialization flag.
|
|
|
|
//
|
|
|
|
// In LLVM, we do this by marking the load Acquire.
|
|
|
|
if (threadsafe)
|
2016-04-07 01:26:42 +08:00
|
|
|
LI->setAtomic(llvm::AtomicOrdering::Acquire);
|
2014-04-23 09:50:10 +08:00
|
|
|
|
|
|
|
// For ARM, we should only check the first bit, rather than the entire byte:
|
|
|
|
//
|
|
|
|
// ARM C++ ABI 3.2.3.1:
|
|
|
|
// To support the potential use of initialization guard variables
|
|
|
|
// as semaphores that are the target of ARM SWP and LDREX/STREX
|
|
|
|
// synchronizing instructions we define a static initialization
|
|
|
|
// guard variable to be a 4-byte aligned, 4-byte word with the
|
|
|
|
// following inline access protocol.
|
|
|
|
// #define INITIALIZED 1
|
|
|
|
// if ((obj_guard & INITIALIZED) != INITIALIZED) {
|
|
|
|
// if (__cxa_guard_acquire(&obj_guard))
|
|
|
|
// ...
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// and similarly for ARM64:
|
|
|
|
//
|
|
|
|
// ARM64 C++ ABI 3.2.2:
|
|
|
|
// This ABI instead only specifies the value bit 0 of the static guard
|
|
|
|
// variable; all other bits are platform defined. Bit 0 shall be 0 when the
|
|
|
|
// variable is not initialized and 1 when it is.
|
|
|
|
llvm::Value *V =
|
|
|
|
(UseARMGuardVarABI && !useInt8GuardVariable)
|
|
|
|
? Builder.CreateAnd(LI, llvm::ConstantInt::get(CGM.Int8Ty, 1))
|
|
|
|
: LI;
|
2017-07-27 06:01:09 +08:00
|
|
|
llvm::Value *NeedsInit = Builder.CreateIsNull(V, "guard.uninitialized");
|
2010-09-08 09:44:27 +08:00
|
|
|
|
|
|
|
llvm::BasicBlock *InitCheckBlock = CGF.createBasicBlock("init.check");
|
|
|
|
llvm::BasicBlock *EndBlock = CGF.createBasicBlock("init.end");
|
|
|
|
|
|
|
|
// Check if the first byte of the guard variable is zero.
|
2017-07-27 06:01:09 +08:00
|
|
|
CGF.EmitCXXGuardedInitBranch(NeedsInit, InitCheckBlock, EndBlock,
|
|
|
|
CodeGenFunction::GuardKind::VariableGuard, &D);
|
2010-09-08 09:44:27 +08:00
|
|
|
|
|
|
|
CGF.EmitBlock(InitCheckBlock);
|
|
|
|
|
|
|
|
// Variables used when coping with thread-safe statics and exceptions.
|
2017-11-11 09:15:41 +08:00
|
|
|
if (threadsafe) {
|
2010-09-08 09:44:27 +08:00
|
|
|
// Call __cxa_guard_acquire.
|
|
|
|
llvm::Value *V
|
2013-03-01 03:01:20 +08:00
|
|
|
= CGF.EmitNounwindRuntimeCall(getGuardAcquireFn(CGM, guardPtrTy), guard);
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
llvm::BasicBlock *InitBlock = CGF.createBasicBlock("init");
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
Builder.CreateCondBr(Builder.CreateIsNotNull(V, "tobool"),
|
|
|
|
InitBlock, EndBlock);
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
// Call __cxa_guard_abort along the exceptional edge.
|
2012-03-31 05:00:39 +08:00
|
|
|
CGF.EHStack.pushCleanup<CallGuardAbort>(EHCleanup, guard);
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2010-09-08 09:44:27 +08:00
|
|
|
CGF.EmitBlock(InitBlock);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit the initializer and add a global destructor if appropriate.
|
2012-03-31 05:00:39 +08:00
|
|
|
CGF.EmitCXXGlobalVarDeclInit(D, var, shouldPerformInit);
|
2010-09-08 09:44:27 +08:00
|
|
|
|
2011-06-17 15:33:57 +08:00
|
|
|
if (threadsafe) {
|
2010-09-08 09:44:27 +08:00
|
|
|
// Pop the guard-abort cleanup if we pushed one.
|
|
|
|
CGF.PopCleanupBlock();
|
|
|
|
|
|
|
|
// Call __cxa_guard_release. This cannot throw.
|
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.EmitNounwindRuntimeCall(getGuardReleaseFn(CGM, guardPtrTy),
|
|
|
|
guardAddr.getPointer());
|
2010-09-08 09:44:27 +08:00
|
|
|
} else {
|
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
|
|
|
Builder.CreateStore(llvm::ConstantInt::get(guardTy, 1), guardAddr);
|
2010-09-08 09:44:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CGF.EmitBlock(EndBlock);
|
|
|
|
}
|
2012-05-01 14:13:13 +08:00
|
|
|
|
|
|
|
/// Register a global destructor using __cxa_atexit.
|
|
|
|
static void emitGlobalDtorWithCXAAtExit(CodeGenFunction &CGF,
|
2019-02-07 09:14:17 +08:00
|
|
|
llvm::FunctionCallee dtor,
|
|
|
|
llvm::Constant *addr, bool TLS) {
|
2019-06-14 02:20:19 +08:00
|
|
|
assert((TLS || CGF.getTypes().getCodeGenOpts().CXAAtExit) &&
|
|
|
|
"__cxa_atexit is disabled");
|
2013-05-03 03:18:03 +08:00
|
|
|
const char *Name = "__cxa_atexit";
|
|
|
|
if (TLS) {
|
|
|
|
const llvm::Triple &T = CGF.getTarget().getTriple();
|
2015-11-12 07:08:18 +08:00
|
|
|
Name = T.isOSDarwin() ? "_tlv_atexit" : "__cxa_thread_atexit";
|
2013-05-03 03:18:03 +08:00
|
|
|
}
|
2013-04-15 07:01:42 +08:00
|
|
|
|
2012-05-01 14:13:13 +08:00
|
|
|
// We're assuming that the destructor function is something we can
|
|
|
|
// reasonably call with the default CC. Go ahead and cast it to the
|
|
|
|
// right prototype.
|
|
|
|
llvm::Type *dtorTy =
|
|
|
|
llvm::FunctionType::get(CGF.VoidTy, CGF.Int8PtrTy, false)->getPointerTo();
|
|
|
|
|
2019-07-15 19:58:10 +08:00
|
|
|
// Preserve address space of addr.
|
|
|
|
auto AddrAS = addr ? addr->getType()->getPointerAddressSpace() : 0;
|
|
|
|
auto AddrInt8PtrTy =
|
|
|
|
AddrAS ? CGF.Int8Ty->getPointerTo(AddrAS) : CGF.Int8PtrTy;
|
|
|
|
|
|
|
|
// Create a variable that binds the atexit to this shared object.
|
|
|
|
llvm::Constant *handle =
|
|
|
|
CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
|
|
|
|
auto *GV = cast<llvm::GlobalValue>(handle->stripPointerCasts());
|
|
|
|
GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
|
|
|
|
|
2012-05-01 14:13:13 +08:00
|
|
|
// extern "C" int __cxa_atexit(void (*f)(void *), void *p, void *d);
|
2019-07-15 19:58:10 +08:00
|
|
|
llvm::Type *paramTys[] = {dtorTy, AddrInt8PtrTy, handle->getType()};
|
2012-05-01 14:13:13 +08:00
|
|
|
llvm::FunctionType *atexitTy =
|
|
|
|
llvm::FunctionType::get(CGF.IntTy, paramTys, false);
|
|
|
|
|
|
|
|
// Fetch the actual function.
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee atexit = CGF.CGM.CreateRuntimeFunction(atexitTy, Name);
|
|
|
|
if (llvm::Function *fn = dyn_cast<llvm::Function>(atexit.getCallee()))
|
2012-05-01 14:13:13 +08:00
|
|
|
fn->setDoesNotThrow();
|
|
|
|
|
2018-04-18 02:41:52 +08:00
|
|
|
if (!addr)
|
|
|
|
// addr is null when we are trying to register a dtor annotated with
|
|
|
|
// __attribute__((destructor)) in a constructor function. Using null here is
|
|
|
|
// okay because this argument is just passed back to the destructor
|
|
|
|
// function.
|
|
|
|
addr = llvm::Constant::getNullValue(CGF.Int8PtrTy);
|
|
|
|
|
2019-02-07 09:14:17 +08:00
|
|
|
llvm::Value *args[] = {llvm::ConstantExpr::getBitCast(
|
|
|
|
cast<llvm::Constant>(dtor.getCallee()), dtorTy),
|
2019-07-15 19:58:10 +08:00
|
|
|
llvm::ConstantExpr::getBitCast(addr, AddrInt8PtrTy),
|
2019-02-07 09:14:17 +08:00
|
|
|
handle};
|
2013-03-01 03:01:20 +08:00
|
|
|
CGF.EmitNounwindRuntimeCall(atexit, args);
|
2012-05-01 14:13:13 +08:00
|
|
|
}
|
|
|
|
|
2018-04-18 02:41:52 +08:00
|
|
|
void CodeGenModule::registerGlobalDtorsWithAtExit() {
|
2020-01-02 00:23:21 +08:00
|
|
|
for (const auto &I : DtorsUsingAtExit) {
|
2018-04-18 02:41:52 +08:00
|
|
|
int Priority = I.first;
|
|
|
|
const llvm::TinyPtrVector<llvm::Function *> &Dtors = I.second;
|
|
|
|
|
|
|
|
// Create a function that registers destructors that have the same priority.
|
|
|
|
//
|
|
|
|
// Since constructor functions are run in non-descending order of their
|
|
|
|
// priorities, destructors are registered in non-descending order of their
|
|
|
|
// priorities, and since destructor functions are run in the reverse order
|
|
|
|
// of their registration, destructor functions are run in non-ascending
|
|
|
|
// order of their priorities.
|
|
|
|
CodeGenFunction CGF(*this);
|
|
|
|
std::string GlobalInitFnName =
|
|
|
|
std::string("__GLOBAL_init_") + llvm::to_string(Priority);
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
|
|
|
|
llvm::Function *GlobalInitFn = CreateGlobalInitOrDestructFunction(
|
|
|
|
FTy, GlobalInitFnName, getTypes().arrangeNullaryFunction(),
|
|
|
|
SourceLocation());
|
|
|
|
ASTContext &Ctx = getContext();
|
2018-11-11 08:56:15 +08:00
|
|
|
QualType ReturnTy = Ctx.VoidTy;
|
|
|
|
QualType FunctionTy = Ctx.getFunctionType(ReturnTy, llvm::None, {});
|
2018-04-18 02:41:52 +08:00
|
|
|
FunctionDecl *FD = FunctionDecl::Create(
|
|
|
|
Ctx, Ctx.getTranslationUnitDecl(), SourceLocation(), SourceLocation(),
|
2018-11-11 08:56:15 +08:00
|
|
|
&Ctx.Idents.get(GlobalInitFnName), FunctionTy, nullptr, SC_Static,
|
2018-04-18 02:41:52 +08:00
|
|
|
false, false);
|
2018-11-11 08:56:15 +08:00
|
|
|
CGF.StartFunction(GlobalDecl(FD), ReturnTy, GlobalInitFn,
|
2018-04-18 02:41:52 +08:00
|
|
|
getTypes().arrangeNullaryFunction(), FunctionArgList(),
|
|
|
|
SourceLocation(), SourceLocation());
|
|
|
|
|
|
|
|
for (auto *Dtor : Dtors) {
|
|
|
|
// Register the destructor function calling __cxa_atexit if it is
|
|
|
|
// available. Otherwise fall back on calling atexit.
|
|
|
|
if (getCodeGenOpts().CXAAtExit)
|
|
|
|
emitGlobalDtorWithCXAAtExit(CGF, Dtor, nullptr, false);
|
|
|
|
else
|
|
|
|
CGF.registerGlobalDtorWithAtExit(Dtor);
|
|
|
|
}
|
|
|
|
|
|
|
|
CGF.FinishFunction();
|
|
|
|
AddGlobalCtor(GlobalInitFn, Priority, nullptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-01 14:13:13 +08:00
|
|
|
/// Register a global destructor as best as we know how.
|
2019-02-07 09:14:17 +08:00
|
|
|
void ItaniumCXXABI::registerGlobalDtor(CodeGenFunction &CGF, const VarDecl &D,
|
|
|
|
llvm::FunctionCallee dtor,
|
2012-05-01 14:13:13 +08:00
|
|
|
llvm::Constant *addr) {
|
2018-08-22 01:24:06 +08:00
|
|
|
if (D.isNoDestroy(CGM.getContext()))
|
|
|
|
return;
|
|
|
|
|
2019-06-14 02:20:19 +08:00
|
|
|
// emitGlobalDtorWithCXAAtExit will emit a call to either __cxa_thread_atexit
|
|
|
|
// or __cxa_atexit depending on whether this VarDecl is a thread-local storage
|
|
|
|
// or not. CXAAtExit controls only __cxa_atexit, so use it if it is enabled.
|
|
|
|
// We can always use __cxa_thread_atexit.
|
|
|
|
if (CGM.getCodeGenOpts().CXAAtExit || D.getTLSKind())
|
2013-04-15 07:01:42 +08:00
|
|
|
return emitGlobalDtorWithCXAAtExit(CGF, dtor, addr, D.getTLSKind());
|
|
|
|
|
2012-05-01 14:13:13 +08:00
|
|
|
// In Apple kexts, we want to add a global destructor entry.
|
|
|
|
// FIXME: shouldn't this be guarded by some variable?
|
2012-11-02 06:30:59 +08:00
|
|
|
if (CGM.getLangOpts().AppleKext) {
|
2012-05-01 14:13:13 +08:00
|
|
|
// Generate a global destructor entry.
|
|
|
|
return CGM.AddCXXDtorEntry(dtor, addr);
|
|
|
|
}
|
|
|
|
|
2013-08-28 07:57:18 +08:00
|
|
|
CGF.registerGlobalDtorWithAtExit(D, dtor, addr);
|
2012-05-01 14:13:13 +08:00
|
|
|
}
|
2013-04-20 00:42:07 +08:00
|
|
|
|
2014-07-12 04:28:10 +08:00
|
|
|
static bool isThreadWrapperReplaceable(const VarDecl *VD,
|
|
|
|
CodeGen::CodeGenModule &CGM) {
|
|
|
|
assert(!VD->isStaticLocal() && "static local VarDecls don't need wrappers!");
|
2015-11-12 07:08:18 +08:00
|
|
|
// Darwin prefers to have references to thread local variables to go through
|
2014-07-12 04:28:10 +08:00
|
|
|
// the thread wrapper instead of directly referencing the backing variable.
|
|
|
|
return VD->getTLSKind() == VarDecl::TLS_Dynamic &&
|
2015-11-12 07:08:18 +08:00
|
|
|
CGM.getTarget().getTriple().isOSDarwin();
|
2014-07-12 04:28:10 +08:00
|
|
|
}
|
|
|
|
|
2013-04-20 00:42:07 +08:00
|
|
|
/// Get the appropriate linkage for the wrapper function. This is essentially
|
2014-06-28 00:56:27 +08:00
|
|
|
/// the weak form of the variable's linkage; every translation unit which needs
|
2013-04-20 00:42:07 +08:00
|
|
|
/// the wrapper emits a copy, and we want the linker to merge them.
|
2014-06-11 12:08:55 +08:00
|
|
|
static llvm::GlobalValue::LinkageTypes
|
|
|
|
getThreadLocalWrapperLinkage(const VarDecl *VD, CodeGen::CodeGenModule &CGM) {
|
|
|
|
llvm::GlobalValue::LinkageTypes VarLinkage =
|
2019-07-16 12:46:31 +08:00
|
|
|
CGM.getLLVMLinkageVarDefinition(VD, /*IsConstant=*/false);
|
2014-06-11 12:08:55 +08:00
|
|
|
|
2013-04-20 00:42:07 +08:00
|
|
|
// For internal linkage variables, we don't need an external or weak wrapper.
|
|
|
|
if (llvm::GlobalValue::isLocalLinkage(VarLinkage))
|
|
|
|
return VarLinkage;
|
2014-06-11 12:08:55 +08:00
|
|
|
|
2014-07-12 04:28:10 +08:00
|
|
|
// If the thread wrapper is replaceable, give it appropriate linkage.
|
2015-11-12 06:42:31 +08:00
|
|
|
if (isThreadWrapperReplaceable(VD, CGM))
|
|
|
|
if (!llvm::GlobalVariable::isLinkOnceLinkage(VarLinkage) &&
|
|
|
|
!llvm::GlobalVariable::isWeakODRLinkage(VarLinkage))
|
|
|
|
return VarLinkage;
|
2013-04-20 00:42:07 +08:00
|
|
|
return llvm::GlobalValue::WeakODRLinkage;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Function *
|
|
|
|
ItaniumCXXABI::getOrCreateThreadLocalWrapper(const VarDecl *VD,
|
2014-09-26 14:28:25 +08:00
|
|
|
llvm::Value *Val) {
|
2013-04-20 00:42:07 +08:00
|
|
|
// Mangle the name for the thread_local wrapper function.
|
|
|
|
SmallString<256> WrapperName;
|
|
|
|
{
|
|
|
|
llvm::raw_svector_ostream Out(WrapperName);
|
|
|
|
getMangleContext().mangleItaniumThreadLocalWrapper(VD, Out);
|
|
|
|
}
|
|
|
|
|
2016-01-15 11:34:06 +08:00
|
|
|
// FIXME: If VD is a definition, we should regenerate the function attributes
|
|
|
|
// before returning.
|
2014-09-26 14:28:25 +08:00
|
|
|
if (llvm::Value *V = CGM.getModule().getNamedValue(WrapperName))
|
2013-04-20 00:42:07 +08:00
|
|
|
return cast<llvm::Function>(V);
|
|
|
|
|
2016-01-15 11:34:06 +08:00
|
|
|
QualType RetQT = VD->getType();
|
|
|
|
if (RetQT->isReferenceType())
|
|
|
|
RetQT = RetQT.getNonReferenceType();
|
2013-04-20 00:42:07 +08:00
|
|
|
|
2016-03-11 12:30:31 +08:00
|
|
|
const CGFunctionInfo &FI = CGM.getTypes().arrangeBuiltinFunctionDeclaration(
|
|
|
|
getContext().getPointerType(RetQT), FunctionArgList());
|
2016-01-15 11:34:06 +08:00
|
|
|
|
|
|
|
llvm::FunctionType *FnTy = CGM.getTypes().GetFunctionType(FI);
|
2014-06-11 12:08:55 +08:00
|
|
|
llvm::Function *Wrapper =
|
|
|
|
llvm::Function::Create(FnTy, getThreadLocalWrapperLinkage(VD, CGM),
|
|
|
|
WrapperName.str(), &CGM.getModule());
|
2016-01-15 11:34:06 +08:00
|
|
|
|
2019-12-17 06:20:32 +08:00
|
|
|
if (CGM.supportsCOMDAT() && Wrapper->isWeakForLinker())
|
|
|
|
Wrapper->setComdat(CGM.getModule().getOrInsertComdat(Wrapper->getName()));
|
|
|
|
|
2018-11-13 23:48:08 +08:00
|
|
|
CGM.SetLLVMFunctionAttributes(GlobalDecl(), FI, Wrapper);
|
2016-01-15 11:34:06 +08:00
|
|
|
|
2013-04-20 00:42:07 +08:00
|
|
|
// Always resolve references to the wrapper at link time.
|
2019-01-18 01:53:45 +08:00
|
|
|
if (!Wrapper->hasLocalLinkage())
|
|
|
|
if (!isThreadWrapperReplaceable(VD, CGM) ||
|
|
|
|
llvm::GlobalVariable::isLinkOnceLinkage(Wrapper->getLinkage()) ||
|
|
|
|
llvm::GlobalVariable::isWeakODRLinkage(Wrapper->getLinkage()) ||
|
|
|
|
VD->getVisibility() == HiddenVisibility)
|
|
|
|
Wrapper->setVisibility(llvm::GlobalValue::HiddenVisibility);
|
2015-12-17 08:42:36 +08:00
|
|
|
|
|
|
|
if (isThreadWrapperReplaceable(VD, CGM)) {
|
|
|
|
Wrapper->setCallingConv(llvm::CallingConv::CXX_FAST_TLS);
|
|
|
|
Wrapper->addFnAttr(llvm::Attribute::NoUnwind);
|
|
|
|
}
|
2019-09-13 04:00:24 +08:00
|
|
|
|
|
|
|
ThreadWrappers.push_back({VD, Wrapper});
|
2013-04-20 00:42:07 +08:00
|
|
|
return Wrapper;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumCXXABI::EmitThreadLocalInitFuncs(
|
2015-12-01 09:10:48 +08:00
|
|
|
CodeGenModule &CGM, ArrayRef<const VarDecl *> CXXThreadLocals,
|
|
|
|
ArrayRef<llvm::Function *> CXXThreadLocalInits,
|
|
|
|
ArrayRef<const VarDecl *> CXXThreadLocalInitVars) {
|
2014-10-05 13:05:40 +08:00
|
|
|
llvm::Function *InitFunc = nullptr;
|
2017-01-13 08:43:31 +08:00
|
|
|
|
|
|
|
// Separate initializers into those with ordered (or partially-ordered)
|
|
|
|
// initialization and those with unordered initialization.
|
|
|
|
llvm::SmallVector<llvm::Function *, 8> OrderedInits;
|
|
|
|
llvm::SmallDenseMap<const VarDecl *, llvm::Function *> UnorderedInits;
|
|
|
|
for (unsigned I = 0; I != CXXThreadLocalInits.size(); ++I) {
|
|
|
|
if (isTemplateInstantiation(
|
|
|
|
CXXThreadLocalInitVars[I]->getTemplateSpecializationKind()))
|
|
|
|
UnorderedInits[CXXThreadLocalInitVars[I]->getCanonicalDecl()] =
|
|
|
|
CXXThreadLocalInits[I];
|
|
|
|
else
|
|
|
|
OrderedInits.push_back(CXXThreadLocalInits[I]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!OrderedInits.empty()) {
|
2014-10-05 13:05:40 +08:00
|
|
|
// Generate a guarded initialization function.
|
|
|
|
llvm::FunctionType *FTy =
|
|
|
|
llvm::FunctionType::get(CGM.VoidTy, /*isVarArg=*/false);
|
2015-10-31 09:28:07 +08:00
|
|
|
const CGFunctionInfo &FI = CGM.getTypes().arrangeNullaryFunction();
|
|
|
|
InitFunc = CGM.CreateGlobalInitOrDestructFunction(FTy, "__tls_init", FI,
|
SanitizerBlacklist: blacklist functions by their source location.
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
2014-10-17 08:20:19 +08:00
|
|
|
SourceLocation(),
|
2014-10-05 13:05:40 +08:00
|
|
|
/*TLS=*/true);
|
|
|
|
llvm::GlobalVariable *Guard = new llvm::GlobalVariable(
|
|
|
|
CGM.getModule(), CGM.Int8Ty, /*isConstant=*/false,
|
|
|
|
llvm::GlobalVariable::InternalLinkage,
|
|
|
|
llvm::ConstantInt::get(CGM.Int8Ty, 0), "__tls_guard");
|
|
|
|
Guard->setThreadLocal(true);
|
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
|
|
|
|
|
|
|
CharUnits GuardAlign = CharUnits::One();
|
2019-10-03 21:00:29 +08:00
|
|
|
Guard->setAlignment(GuardAlign.getAsAlign());
|
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
|
|
|
|
2018-11-01 04:39:26 +08:00
|
|
|
CodeGenFunction(CGM).GenerateCXXGlobalInitFunc(
|
|
|
|
InitFunc, OrderedInits, ConstantAddress(Guard, GuardAlign));
|
2016-03-19 07:35:21 +08:00
|
|
|
// On Darwin platforms, use CXX_FAST_TLS calling convention.
|
|
|
|
if (CGM.getTarget().getTriple().isOSDarwin()) {
|
|
|
|
InitFunc->setCallingConv(llvm::CallingConv::CXX_FAST_TLS);
|
|
|
|
InitFunc->addFnAttr(llvm::Attribute::NoUnwind);
|
|
|
|
}
|
2014-10-05 13:05:40 +08:00
|
|
|
}
|
2017-01-13 08:43:31 +08:00
|
|
|
|
2019-09-13 04:00:24 +08:00
|
|
|
// Create declarations for thread wrappers for all thread-local variables
|
|
|
|
// with non-discardable definitions in this translation unit.
|
2015-12-01 09:10:48 +08:00
|
|
|
for (const VarDecl *VD : CXXThreadLocals) {
|
2019-09-13 04:00:24 +08:00
|
|
|
if (VD->hasDefinition() &&
|
|
|
|
!isDiscardableGVALinkage(getContext().GetGVALinkageForVariable(VD))) {
|
|
|
|
llvm::GlobalValue *GV = CGM.GetGlobalValue(CGM.getMangledName(VD));
|
|
|
|
getOrCreateThreadLocalWrapper(VD, GV);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit all referenced thread wrappers.
|
|
|
|
for (auto VDAndWrapper : ThreadWrappers) {
|
|
|
|
const VarDecl *VD = VDAndWrapper.first;
|
2015-12-01 09:10:48 +08:00
|
|
|
llvm::GlobalVariable *Var =
|
|
|
|
cast<llvm::GlobalVariable>(CGM.GetGlobalValue(CGM.getMangledName(VD)));
|
2019-09-13 04:00:24 +08:00
|
|
|
llvm::Function *Wrapper = VDAndWrapper.second;
|
2013-04-20 00:42:07 +08:00
|
|
|
|
2014-07-12 04:28:10 +08:00
|
|
|
// Some targets require that all access to thread local variables go through
|
|
|
|
// the thread wrapper. This means that we cannot attempt to create a thread
|
|
|
|
// wrapper or a thread helper.
|
2019-09-13 04:00:24 +08:00
|
|
|
if (!VD->hasDefinition()) {
|
|
|
|
if (isThreadWrapperReplaceable(VD, CGM)) {
|
|
|
|
Wrapper->setLinkage(llvm::Function::ExternalLinkage);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If this isn't a TU in which this variable is defined, the thread
|
|
|
|
// wrapper is discardable.
|
|
|
|
if (Wrapper->getLinkage() == llvm::Function::WeakODRLinkage)
|
|
|
|
Wrapper->setLinkage(llvm::Function::LinkOnceODRLinkage);
|
2017-01-13 08:43:31 +08:00
|
|
|
}
|
2014-07-12 04:28:10 +08:00
|
|
|
|
2019-09-13 04:00:24 +08:00
|
|
|
CGM.SetLLVMFunctionAttributesForDefinition(nullptr, Wrapper);
|
|
|
|
|
2013-04-20 00:42:07 +08:00
|
|
|
// Mangle the name for the thread_local initialization function.
|
|
|
|
SmallString<256> InitFnName;
|
|
|
|
{
|
|
|
|
llvm::raw_svector_ostream Out(InitFnName);
|
|
|
|
getMangleContext().mangleItaniumThreadLocalInit(VD, Out);
|
|
|
|
}
|
|
|
|
|
2019-02-07 09:14:17 +08:00
|
|
|
llvm::FunctionType *InitFnTy = llvm::FunctionType::get(CGM.VoidTy, false);
|
|
|
|
|
2013-04-20 00:42:07 +08:00
|
|
|
// If we have a definition for the variable, emit the initialization
|
|
|
|
// function as an alias to the global Init function (if any). Otherwise,
|
|
|
|
// produce a declaration of the initialization function.
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::GlobalValue *Init = nullptr;
|
2013-04-20 00:42:07 +08:00
|
|
|
bool InitIsInitFunc = false;
|
2019-09-13 04:00:24 +08:00
|
|
|
bool HasConstantInitialization = false;
|
2019-10-01 09:23:23 +08:00
|
|
|
if (!usesThreadWrapperFunction(VD)) {
|
2019-09-13 04:00:24 +08:00
|
|
|
HasConstantInitialization = true;
|
|
|
|
} else if (VD->hasDefinition()) {
|
2013-04-20 00:42:07 +08:00
|
|
|
InitIsInitFunc = true;
|
2017-01-13 08:43:31 +08:00
|
|
|
llvm::Function *InitFuncToUse = InitFunc;
|
|
|
|
if (isTemplateInstantiation(VD->getTemplateSpecializationKind()))
|
|
|
|
InitFuncToUse = UnorderedInits.lookup(VD->getCanonicalDecl());
|
|
|
|
if (InitFuncToUse)
|
2014-05-18 05:30:14 +08:00
|
|
|
Init = llvm::GlobalAlias::create(Var->getLinkage(), InitFnName.str(),
|
2017-01-13 08:43:31 +08:00
|
|
|
InitFuncToUse);
|
2013-04-20 00:42:07 +08:00
|
|
|
} else {
|
|
|
|
// Emit a weak global function referring to the initialization function.
|
|
|
|
// This function will not exist if the TU defining the thread_local
|
|
|
|
// variable in question does not need any dynamic initialization for
|
|
|
|
// its thread_local variables.
|
2019-02-07 09:14:17 +08:00
|
|
|
Init = llvm::Function::Create(InitFnTy,
|
2017-01-13 08:43:31 +08:00
|
|
|
llvm::GlobalVariable::ExternalWeakLinkage,
|
|
|
|
InitFnName.str(), &CGM.getModule());
|
2016-03-11 12:30:31 +08:00
|
|
|
const CGFunctionInfo &FI = CGM.getTypes().arrangeNullaryFunction();
|
2018-11-13 23:48:08 +08:00
|
|
|
CGM.SetLLVMFunctionAttributes(GlobalDecl(), FI,
|
|
|
|
cast<llvm::Function>(Init));
|
2013-04-20 00:42:07 +08:00
|
|
|
}
|
|
|
|
|
2018-03-08 07:18:06 +08:00
|
|
|
if (Init) {
|
2013-04-20 00:42:07 +08:00
|
|
|
Init->setVisibility(Var->getVisibility());
|
2019-12-19 19:57:47 +08:00
|
|
|
// Don't mark an extern_weak function DSO local on windows.
|
|
|
|
if (!CGM.getTriple().isOSWindows() || !Init->hasExternalWeakLinkage())
|
|
|
|
Init->setDSOLocal(Var->isDSOLocal());
|
2018-03-08 07:18:06 +08:00
|
|
|
}
|
2013-04-20 00:42:07 +08:00
|
|
|
|
|
|
|
llvm::LLVMContext &Context = CGM.getModule().getContext();
|
|
|
|
llvm::BasicBlock *Entry = llvm::BasicBlock::Create(Context, "", Wrapper);
|
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
|
|
|
CGBuilderTy Builder(CGM, Entry);
|
2019-09-13 04:00:24 +08:00
|
|
|
if (HasConstantInitialization) {
|
|
|
|
// No dynamic initialization to invoke.
|
|
|
|
} else if (InitIsInitFunc) {
|
2016-03-19 07:35:21 +08:00
|
|
|
if (Init) {
|
2019-02-07 09:14:17 +08:00
|
|
|
llvm::CallInst *CallVal = Builder.CreateCall(InitFnTy, Init);
|
2018-05-30 02:28:49 +08:00
|
|
|
if (isThreadWrapperReplaceable(VD, CGM)) {
|
2016-03-19 07:35:21 +08:00
|
|
|
CallVal->setCallingConv(llvm::CallingConv::CXX_FAST_TLS);
|
2018-05-30 02:28:49 +08:00
|
|
|
llvm::Function *Fn =
|
|
|
|
cast<llvm::Function>(cast<llvm::GlobalAlias>(Init)->getAliasee());
|
|
|
|
Fn->setCallingConv(llvm::CallingConv::CXX_FAST_TLS);
|
|
|
|
}
|
2016-03-19 07:35:21 +08:00
|
|
|
}
|
2013-04-20 00:42:07 +08:00
|
|
|
} else {
|
|
|
|
// Don't know whether we have an init function. Call it if it exists.
|
|
|
|
llvm::Value *Have = Builder.CreateIsNotNull(Init);
|
|
|
|
llvm::BasicBlock *InitBB = llvm::BasicBlock::Create(Context, "", Wrapper);
|
|
|
|
llvm::BasicBlock *ExitBB = llvm::BasicBlock::Create(Context, "", Wrapper);
|
|
|
|
Builder.CreateCondBr(Have, InitBB, ExitBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(InitBB);
|
2019-02-07 09:14:17 +08:00
|
|
|
Builder.CreateCall(InitFnTy, Init);
|
2013-04-20 00:42:07 +08:00
|
|
|
Builder.CreateBr(ExitBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ExitBB);
|
|
|
|
}
|
|
|
|
|
|
|
|
// For a reference, the result of the wrapper function is a pointer to
|
|
|
|
// the referenced object.
|
|
|
|
llvm::Value *Val = Var;
|
|
|
|
if (VD->getType()->isReferenceType()) {
|
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
|
|
|
CharUnits Align = CGM.getContext().getDeclAlign(VD);
|
|
|
|
Val = Builder.CreateAlignedLoad(Val, Align);
|
2013-04-20 00:42:07 +08:00
|
|
|
}
|
2014-09-26 14:28:25 +08:00
|
|
|
if (Val->getType() != Wrapper->getReturnType())
|
|
|
|
Val = Builder.CreatePointerBitCastOrAddrSpaceCast(
|
|
|
|
Val, Wrapper->getReturnType(), "");
|
2013-04-20 00:42:07 +08:00
|
|
|
Builder.CreateRet(Val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-27 06:48:22 +08:00
|
|
|
LValue ItaniumCXXABI::EmitThreadLocalVarDeclLValue(CodeGenFunction &CGF,
|
|
|
|
const VarDecl *VD,
|
|
|
|
QualType LValType) {
|
2015-12-01 09:10:48 +08:00
|
|
|
llvm::Value *Val = CGF.CGM.GetAddrOfGlobalVar(VD);
|
2014-09-26 14:28:25 +08:00
|
|
|
llvm::Function *Wrapper = getOrCreateThreadLocalWrapper(VD, Val);
|
2013-04-20 00:42:07 +08:00
|
|
|
|
2015-12-17 08:42:36 +08:00
|
|
|
llvm::CallInst *CallVal = CGF.Builder.CreateCall(Wrapper);
|
2016-08-02 05:31:24 +08:00
|
|
|
CallVal->setCallingConv(Wrapper->getCallingConv());
|
2013-04-20 00:42:07 +08:00
|
|
|
|
|
|
|
LValue LV;
|
|
|
|
if (VD->getType()->isReferenceType())
|
2015-12-17 08:42:36 +08:00
|
|
|
LV = CGF.MakeNaturalAlignAddrLValue(CallVal, LValType);
|
2013-04-20 00:42:07 +08:00
|
|
|
else
|
2015-12-17 08:42:36 +08:00
|
|
|
LV = CGF.MakeAddrLValue(CallVal, LValType,
|
|
|
|
CGF.getContext().getDeclAlign(VD));
|
2013-04-20 00:42:07 +08:00
|
|
|
// FIXME: need setObjCGCLValueClass?
|
|
|
|
return LV;
|
|
|
|
}
|
2013-06-29 04:45:28 +08:00
|
|
|
|
|
|
|
/// Return whether the given global decl needs a VTT parameter, which it does
|
|
|
|
/// if it's a base constructor or destructor with virtual bases.
|
|
|
|
bool ItaniumCXXABI::NeedsVTTParameter(GlobalDecl GD) {
|
|
|
|
const CXXMethodDecl *MD = cast<CXXMethodDecl>(GD.getDecl());
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2013-06-29 04:45:28 +08:00
|
|
|
// We don't have any virtual bases, just return early.
|
|
|
|
if (!MD->getParent()->getNumVBases())
|
|
|
|
return false;
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2013-06-29 04:45:28 +08:00
|
|
|
// Check if we have a base constructor.
|
|
|
|
if (isa<CXXConstructorDecl>(MD) && GD.getCtorType() == Ctor_Base)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Check if we have a base destructor.
|
|
|
|
if (isa<CXXDestructorDecl>(MD) && GD.getDtorType() == Dtor_Base)
|
|
|
|
return true;
|
2017-11-11 09:15:41 +08:00
|
|
|
|
2013-06-29 04:45:28 +08:00
|
|
|
return false;
|
|
|
|
}
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
class ItaniumRTTIBuilder {
|
|
|
|
CodeGenModule &CGM; // Per-module state.
|
|
|
|
llvm::LLVMContext &VMContext;
|
|
|
|
const ItaniumCXXABI &CXXABI; // Per-module state.
|
|
|
|
|
|
|
|
/// Fields - The fields of the RTTI descriptor currently being built.
|
|
|
|
SmallVector<llvm::Constant *, 16> Fields;
|
|
|
|
|
|
|
|
/// GetAddrOfTypeName - Returns the mangled type name of the given type.
|
|
|
|
llvm::GlobalVariable *
|
|
|
|
GetAddrOfTypeName(QualType Ty, llvm::GlobalVariable::LinkageTypes Linkage);
|
|
|
|
|
|
|
|
/// GetAddrOfExternalRTTIDescriptor - Returns the constant for the RTTI
|
|
|
|
/// descriptor of the given type.
|
|
|
|
llvm::Constant *GetAddrOfExternalRTTIDescriptor(QualType Ty);
|
|
|
|
|
|
|
|
/// BuildVTablePointer - Build the vtable pointer for the given type.
|
|
|
|
void BuildVTablePointer(const Type *Ty);
|
|
|
|
|
|
|
|
/// BuildSIClassTypeInfo - Build an abi::__si_class_type_info, used for single
|
|
|
|
/// inheritance, according to the Itanium C++ ABI, 2.9.5p6b.
|
|
|
|
void BuildSIClassTypeInfo(const CXXRecordDecl *RD);
|
|
|
|
|
|
|
|
/// BuildVMIClassTypeInfo - Build an abi::__vmi_class_type_info, used for
|
|
|
|
/// classes with bases that do not satisfy the abi::__si_class_type_info
|
|
|
|
/// constraints, according ti the Itanium C++ ABI, 2.9.5p5c.
|
|
|
|
void BuildVMIClassTypeInfo(const CXXRecordDecl *RD);
|
|
|
|
|
|
|
|
/// BuildPointerTypeInfo - Build an abi::__pointer_type_info struct, used
|
|
|
|
/// for pointer types.
|
|
|
|
void BuildPointerTypeInfo(QualType PointeeTy);
|
|
|
|
|
|
|
|
/// BuildObjCObjectTypeInfo - Build the appropriate kind of
|
|
|
|
/// type_info for an object type.
|
|
|
|
void BuildObjCObjectTypeInfo(const ObjCObjectType *Ty);
|
|
|
|
|
|
|
|
/// BuildPointerToMemberTypeInfo - Build an abi::__pointer_to_member_type_info
|
|
|
|
/// struct, used for member pointer types.
|
|
|
|
void BuildPointerToMemberTypeInfo(const MemberPointerType *Ty);
|
|
|
|
|
|
|
|
public:
|
|
|
|
ItaniumRTTIBuilder(const ItaniumCXXABI &ABI)
|
|
|
|
: CGM(ABI.CGM), VMContext(CGM.getModule().getContext()), CXXABI(ABI) {}
|
|
|
|
|
|
|
|
// Pointer type info flags.
|
|
|
|
enum {
|
|
|
|
/// PTI_Const - Type has const qualifier.
|
|
|
|
PTI_Const = 0x1,
|
|
|
|
|
|
|
|
/// PTI_Volatile - Type has volatile qualifier.
|
|
|
|
PTI_Volatile = 0x2,
|
|
|
|
|
|
|
|
/// PTI_Restrict - Type has restrict qualifier.
|
|
|
|
PTI_Restrict = 0x4,
|
|
|
|
|
|
|
|
/// PTI_Incomplete - Type is incomplete.
|
|
|
|
PTI_Incomplete = 0x8,
|
|
|
|
|
|
|
|
/// PTI_ContainingClassIncomplete - Containing class is incomplete.
|
|
|
|
/// (in pointer to member).
|
2016-12-01 11:32:42 +08:00
|
|
|
PTI_ContainingClassIncomplete = 0x10,
|
|
|
|
|
|
|
|
/// PTI_TransactionSafe - Pointee is transaction_safe function (C++ TM TS).
|
|
|
|
//PTI_TransactionSafe = 0x20,
|
|
|
|
|
|
|
|
/// PTI_Noexcept - Pointee is noexcept function (C++1z).
|
|
|
|
PTI_Noexcept = 0x40,
|
2014-07-07 14:20:47 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// VMI type info flags.
|
|
|
|
enum {
|
|
|
|
/// VMI_NonDiamondRepeat - Class has non-diamond repeated inheritance.
|
|
|
|
VMI_NonDiamondRepeat = 0x1,
|
|
|
|
|
|
|
|
/// VMI_DiamondShaped - Class is diamond shaped.
|
|
|
|
VMI_DiamondShaped = 0x2
|
|
|
|
};
|
|
|
|
|
|
|
|
// Base class type info flags.
|
|
|
|
enum {
|
|
|
|
/// BCTI_Virtual - Base class is virtual.
|
|
|
|
BCTI_Virtual = 0x1,
|
|
|
|
|
|
|
|
/// BCTI_Public - Base class is public.
|
|
|
|
BCTI_Public = 0x2
|
|
|
|
};
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
/// BuildTypeInfo - Build the RTTI type info struct for the given type, or
|
|
|
|
/// link to an existing RTTI descriptor if one already exists.
|
|
|
|
llvm::Constant *BuildTypeInfo(QualType Ty);
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
/// BuildTypeInfo - Build the RTTI type info struct for the given type.
|
2018-07-24 08:43:47 +08:00
|
|
|
llvm::Constant *BuildTypeInfo(
|
|
|
|
QualType Ty,
|
|
|
|
llvm::GlobalVariable::LinkageTypes Linkage,
|
|
|
|
llvm::GlobalValue::VisibilityTypes Visibility,
|
|
|
|
llvm::GlobalValue::DLLStorageClassTypes DLLStorageClass);
|
2014-07-07 14:20:47 +08:00
|
|
|
};
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
llvm::GlobalVariable *ItaniumRTTIBuilder::GetAddrOfTypeName(
|
|
|
|
QualType Ty, llvm::GlobalVariable::LinkageTypes Linkage) {
|
2015-07-29 22:21:47 +08:00
|
|
|
SmallString<256> Name;
|
|
|
|
llvm::raw_svector_ostream Out(Name);
|
2014-07-07 14:20:47 +08:00
|
|
|
CGM.getCXXABI().getMangleContext().mangleCXXRTTIName(Ty, Out);
|
|
|
|
|
|
|
|
// We know that the mangled name of the type starts at index 4 of the
|
|
|
|
// mangled name of the typename, so we can just index into it in order to
|
|
|
|
// get the mangled name of the type.
|
|
|
|
llvm::Constant *Init = llvm::ConstantDataArray::getString(VMContext,
|
|
|
|
Name.substr(4));
|
2018-09-12 22:09:06 +08:00
|
|
|
auto Align = CGM.getContext().getTypeAlignInChars(CGM.getContext().CharTy);
|
2014-07-07 14:20:47 +08:00
|
|
|
|
2018-09-12 22:09:06 +08:00
|
|
|
llvm::GlobalVariable *GV = CGM.CreateOrReplaceCXXRuntimeVariable(
|
|
|
|
Name, Init->getType(), Linkage, Align.getQuantity());
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
GV->setInitializer(Init);
|
|
|
|
|
|
|
|
return GV;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *
|
|
|
|
ItaniumRTTIBuilder::GetAddrOfExternalRTTIDescriptor(QualType Ty) {
|
|
|
|
// Mangle the RTTI name.
|
2015-07-29 22:21:47 +08:00
|
|
|
SmallString<256> Name;
|
|
|
|
llvm::raw_svector_ostream Out(Name);
|
2014-07-07 14:20:47 +08:00
|
|
|
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty, Out);
|
|
|
|
|
|
|
|
// Look for an existing global.
|
|
|
|
llvm::GlobalVariable *GV = CGM.getModule().getNamedGlobal(Name);
|
|
|
|
|
|
|
|
if (!GV) {
|
|
|
|
// Create a new global variable.
|
2017-06-01 16:04:05 +08:00
|
|
|
// Note for the future: If we would ever like to do deferred emission of
|
|
|
|
// RTTI, check if emitting vtables opportunistically need any adjustment.
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
GV = new llvm::GlobalVariable(CGM.getModule(), CGM.Int8PtrTy,
|
2019-07-16 12:46:31 +08:00
|
|
|
/*isConstant=*/true,
|
2014-07-07 14:20:47 +08:00
|
|
|
llvm::GlobalValue::ExternalLinkage, nullptr,
|
|
|
|
Name);
|
2018-03-15 02:14:46 +08:00
|
|
|
const CXXRecordDecl *RD = Ty->getAsCXXRecordDecl();
|
|
|
|
CGM.setGVProperties(GV, RD);
|
2014-07-07 14:20:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return llvm::ConstantExpr::getBitCast(GV, CGM.Int8PtrTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// TypeInfoIsInStandardLibrary - Given a builtin type, returns whether the type
|
|
|
|
/// info for that type is defined in the standard library.
|
|
|
|
static bool TypeInfoIsInStandardLibrary(const BuiltinType *Ty) {
|
|
|
|
// Itanium C++ ABI 2.9.2:
|
|
|
|
// Basic type information (e.g. for "int", "bool", etc.) will be kept in
|
|
|
|
// the run-time support library. Specifically, the run-time support
|
|
|
|
// library should contain type_info objects for the types X, X* and
|
|
|
|
// X const*, for every X in: void, std::nullptr_t, bool, wchar_t, char,
|
|
|
|
// unsigned char, signed char, short, unsigned short, int, unsigned int,
|
|
|
|
// long, unsigned long, long long, unsigned long long, float, double,
|
|
|
|
// long double, char16_t, char32_t, and the IEEE 754r decimal and
|
|
|
|
// half-precision floating point types.
|
2016-02-03 09:32:42 +08:00
|
|
|
//
|
|
|
|
// GCC also emits RTTI for __int128.
|
|
|
|
// FIXME: We do not emit RTTI information for decimal types here.
|
|
|
|
|
|
|
|
// Types added here must also be added to EmitFundamentalRTTIDescriptors.
|
2014-07-07 14:20:47 +08:00
|
|
|
switch (Ty->getKind()) {
|
|
|
|
case BuiltinType::Void:
|
|
|
|
case BuiltinType::NullPtr:
|
|
|
|
case BuiltinType::Bool:
|
|
|
|
case BuiltinType::WChar_S:
|
|
|
|
case BuiltinType::WChar_U:
|
|
|
|
case BuiltinType::Char_U:
|
|
|
|
case BuiltinType::Char_S:
|
|
|
|
case BuiltinType::UChar:
|
|
|
|
case BuiltinType::SChar:
|
|
|
|
case BuiltinType::Short:
|
|
|
|
case BuiltinType::UShort:
|
|
|
|
case BuiltinType::Int:
|
|
|
|
case BuiltinType::UInt:
|
|
|
|
case BuiltinType::Long:
|
|
|
|
case BuiltinType::ULong:
|
|
|
|
case BuiltinType::LongLong:
|
|
|
|
case BuiltinType::ULongLong:
|
|
|
|
case BuiltinType::Half:
|
|
|
|
case BuiltinType::Float:
|
|
|
|
case BuiltinType::Double:
|
|
|
|
case BuiltinType::LongDouble:
|
2017-09-08 23:15:00 +08:00
|
|
|
case BuiltinType::Float16:
|
2016-05-09 16:52:33 +08:00
|
|
|
case BuiltinType::Float128:
|
2018-05-01 13:02:45 +08:00
|
|
|
case BuiltinType::Char8:
|
2014-07-07 14:20:47 +08:00
|
|
|
case BuiltinType::Char16:
|
|
|
|
case BuiltinType::Char32:
|
|
|
|
case BuiltinType::Int128:
|
|
|
|
case BuiltinType::UInt128:
|
2016-02-03 09:32:42 +08:00
|
|
|
return true;
|
|
|
|
|
2016-04-08 21:40:33 +08:00
|
|
|
#define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) \
|
|
|
|
case BuiltinType::Id:
|
2016-04-13 16:33:41 +08:00
|
|
|
#include "clang/Basic/OpenCLImageTypes.def"
|
2018-11-08 19:25:41 +08:00
|
|
|
#define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
|
|
|
|
case BuiltinType::Id:
|
|
|
|
#include "clang/Basic/OpenCLExtensionTypes.def"
|
2014-07-07 14:20:47 +08:00
|
|
|
case BuiltinType::OCLSampler:
|
|
|
|
case BuiltinType::OCLEvent:
|
2015-09-15 19:18:52 +08:00
|
|
|
case BuiltinType::OCLClkEvent:
|
|
|
|
case BuiltinType::OCLQueue:
|
|
|
|
case BuiltinType::OCLReserveID:
|
2019-08-09 16:52:54 +08:00
|
|
|
#define SVE_TYPE(Name, Id, SingletonId) \
|
|
|
|
case BuiltinType::Id:
|
|
|
|
#include "clang/Basic/AArch64SVEACLETypes.def"
|
2018-06-05 00:07:52 +08:00
|
|
|
case BuiltinType::ShortAccum:
|
|
|
|
case BuiltinType::Accum:
|
|
|
|
case BuiltinType::LongAccum:
|
|
|
|
case BuiltinType::UShortAccum:
|
|
|
|
case BuiltinType::UAccum:
|
|
|
|
case BuiltinType::ULongAccum:
|
2018-06-14 22:53:51 +08:00
|
|
|
case BuiltinType::ShortFract:
|
|
|
|
case BuiltinType::Fract:
|
|
|
|
case BuiltinType::LongFract:
|
|
|
|
case BuiltinType::UShortFract:
|
|
|
|
case BuiltinType::UFract:
|
|
|
|
case BuiltinType::ULongFract:
|
|
|
|
case BuiltinType::SatShortAccum:
|
|
|
|
case BuiltinType::SatAccum:
|
|
|
|
case BuiltinType::SatLongAccum:
|
|
|
|
case BuiltinType::SatUShortAccum:
|
|
|
|
case BuiltinType::SatUAccum:
|
|
|
|
case BuiltinType::SatULongAccum:
|
|
|
|
case BuiltinType::SatShortFract:
|
|
|
|
case BuiltinType::SatFract:
|
|
|
|
case BuiltinType::SatLongFract:
|
|
|
|
case BuiltinType::SatUShortFract:
|
|
|
|
case BuiltinType::SatUFract:
|
|
|
|
case BuiltinType::SatULongFract:
|
2016-02-03 09:32:42 +08:00
|
|
|
return false;
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
case BuiltinType::Dependent:
|
|
|
|
#define BUILTIN_TYPE(Id, SingletonId)
|
|
|
|
#define PLACEHOLDER_TYPE(Id, SingletonId) \
|
|
|
|
case BuiltinType::Id:
|
|
|
|
#include "clang/AST/BuiltinTypes.def"
|
|
|
|
llvm_unreachable("asking for RRTI for a placeholder type!");
|
|
|
|
|
|
|
|
case BuiltinType::ObjCId:
|
|
|
|
case BuiltinType::ObjCClass:
|
|
|
|
case BuiltinType::ObjCSel:
|
|
|
|
llvm_unreachable("FIXME: Objective-C types are unsupported!");
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm_unreachable("Invalid BuiltinType Kind!");
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool TypeInfoIsInStandardLibrary(const PointerType *PointerTy) {
|
|
|
|
QualType PointeeTy = PointerTy->getPointeeType();
|
|
|
|
const BuiltinType *BuiltinTy = dyn_cast<BuiltinType>(PointeeTy);
|
|
|
|
if (!BuiltinTy)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Check the qualifiers.
|
|
|
|
Qualifiers Quals = PointeeTy.getQualifiers();
|
|
|
|
Quals.removeConst();
|
|
|
|
|
|
|
|
if (!Quals.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return TypeInfoIsInStandardLibrary(BuiltinTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// IsStandardLibraryRTTIDescriptor - Returns whether the type
|
|
|
|
/// information for the given type exists in the standard library.
|
|
|
|
static bool IsStandardLibraryRTTIDescriptor(QualType Ty) {
|
|
|
|
// Type info for builtin types is defined in the standard library.
|
|
|
|
if (const BuiltinType *BuiltinTy = dyn_cast<BuiltinType>(Ty))
|
|
|
|
return TypeInfoIsInStandardLibrary(BuiltinTy);
|
|
|
|
|
|
|
|
// Type info for some pointer types to builtin types is defined in the
|
|
|
|
// standard library.
|
|
|
|
if (const PointerType *PointerTy = dyn_cast<PointerType>(Ty))
|
|
|
|
return TypeInfoIsInStandardLibrary(PointerTy);
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ShouldUseExternalRTTIDescriptor - Returns whether the type information for
|
|
|
|
/// the given type exists somewhere else, and that we should not emit the type
|
|
|
|
/// information in this translation unit. Assumes that it is not a
|
|
|
|
/// standard-library type.
|
|
|
|
static bool ShouldUseExternalRTTIDescriptor(CodeGenModule &CGM,
|
|
|
|
QualType Ty) {
|
|
|
|
ASTContext &Context = CGM.getContext();
|
|
|
|
|
|
|
|
// If RTTI is disabled, assume it might be disabled in the
|
|
|
|
// translation unit that defines any potential key function, too.
|
|
|
|
if (!Context.getLangOpts().RTTI) return false;
|
|
|
|
|
|
|
|
if (const RecordType *RecordTy = dyn_cast<RecordType>(Ty)) {
|
|
|
|
const CXXRecordDecl *RD = cast<CXXRecordDecl>(RecordTy->getDecl());
|
|
|
|
if (!RD->hasDefinition())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!RD->isDynamicClass())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// FIXME: this may need to be reconsidered if the key function
|
|
|
|
// changes.
|
2015-08-07 04:56:55 +08:00
|
|
|
// N.B. We must always emit the RTTI data ourselves if there exists a key
|
|
|
|
// function.
|
|
|
|
bool IsDLLImport = RD->hasAttr<DLLImportAttr>();
|
2018-02-02 14:22:35 +08:00
|
|
|
|
|
|
|
// Don't import the RTTI but emit it locally.
|
2019-04-27 03:31:51 +08:00
|
|
|
if (CGM.getTriple().isWindowsGNUEnvironment())
|
2018-02-02 14:22:35 +08:00
|
|
|
return false;
|
|
|
|
|
2014-11-07 15:26:38 +08:00
|
|
|
if (CGM.getVTables().isVTableExternal(RD))
|
2017-07-04 09:02:19 +08:00
|
|
|
return IsDLLImport && !CGM.getTriple().isWindowsItaniumEnvironment()
|
|
|
|
? false
|
|
|
|
: true;
|
2014-11-07 15:26:38 +08:00
|
|
|
|
2015-08-07 04:56:55 +08:00
|
|
|
if (IsDLLImport)
|
2014-11-07 15:26:38 +08:00
|
|
|
return true;
|
2014-07-07 14:20:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// IsIncompleteClassType - Returns whether the given record type is incomplete.
|
|
|
|
static bool IsIncompleteClassType(const RecordType *RecordTy) {
|
|
|
|
return !RecordTy->getDecl()->isCompleteDefinition();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ContainsIncompleteClassType - Returns whether the given type contains an
|
|
|
|
/// incomplete class type. This is true if
|
|
|
|
///
|
|
|
|
/// * The given type is an incomplete class type.
|
|
|
|
/// * The given type is a pointer type whose pointee type contains an
|
|
|
|
/// incomplete class type.
|
|
|
|
/// * The given type is a member pointer type whose class is an incomplete
|
|
|
|
/// class type.
|
|
|
|
/// * The given type is a member pointer type whoise pointee type contains an
|
|
|
|
/// incomplete class type.
|
|
|
|
/// is an indirect or direct pointer to an incomplete class type.
|
|
|
|
static bool ContainsIncompleteClassType(QualType Ty) {
|
|
|
|
if (const RecordType *RecordTy = dyn_cast<RecordType>(Ty)) {
|
|
|
|
if (IsIncompleteClassType(RecordTy))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const PointerType *PointerTy = dyn_cast<PointerType>(Ty))
|
|
|
|
return ContainsIncompleteClassType(PointerTy->getPointeeType());
|
|
|
|
|
|
|
|
if (const MemberPointerType *MemberPointerTy =
|
|
|
|
dyn_cast<MemberPointerType>(Ty)) {
|
|
|
|
// Check if the class type is incomplete.
|
|
|
|
const RecordType *ClassType = cast<RecordType>(MemberPointerTy->getClass());
|
|
|
|
if (IsIncompleteClassType(ClassType))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return ContainsIncompleteClassType(MemberPointerTy->getPointeeType());
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanUseSingleInheritance - Return whether the given record decl has a "single,
|
|
|
|
// public, non-virtual base at offset zero (i.e. the derived class is dynamic
|
|
|
|
// iff the base is)", according to Itanium C++ ABI, 2.95p6b.
|
|
|
|
static bool CanUseSingleInheritance(const CXXRecordDecl *RD) {
|
|
|
|
// Check the number of bases.
|
|
|
|
if (RD->getNumBases() != 1)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Get the base.
|
|
|
|
CXXRecordDecl::base_class_const_iterator Base = RD->bases_begin();
|
|
|
|
|
|
|
|
// Check that the base is not virtual.
|
|
|
|
if (Base->isVirtual())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Check that the base is public.
|
|
|
|
if (Base->getAccessSpecifier() != AS_public)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Check that the class is dynamic iff the base is.
|
2019-10-03 04:45:16 +08:00
|
|
|
auto *BaseDecl =
|
|
|
|
cast<CXXRecordDecl>(Base->getType()->castAs<RecordType>()->getDecl());
|
2014-07-07 14:20:47 +08:00
|
|
|
if (!BaseDecl->isEmpty() &&
|
|
|
|
BaseDecl->isDynamicClass() != RD->isDynamicClass())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ItaniumRTTIBuilder::BuildVTablePointer(const Type *Ty) {
|
|
|
|
// abi::__class_type_info.
|
|
|
|
static const char * const ClassTypeInfo =
|
|
|
|
"_ZTVN10__cxxabiv117__class_type_infoE";
|
|
|
|
// abi::__si_class_type_info.
|
|
|
|
static const char * const SIClassTypeInfo =
|
|
|
|
"_ZTVN10__cxxabiv120__si_class_type_infoE";
|
|
|
|
// abi::__vmi_class_type_info.
|
|
|
|
static const char * const VMIClassTypeInfo =
|
|
|
|
"_ZTVN10__cxxabiv121__vmi_class_type_infoE";
|
|
|
|
|
|
|
|
const char *VTableName = nullptr;
|
|
|
|
|
|
|
|
switch (Ty->getTypeClass()) {
|
|
|
|
#define TYPE(Class, Base)
|
|
|
|
#define ABSTRACT_TYPE(Class, Base)
|
|
|
|
#define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(Class, Base) case Type::Class:
|
|
|
|
#define NON_CANONICAL_TYPE(Class, Base) case Type::Class:
|
|
|
|
#define DEPENDENT_TYPE(Class, Base) case Type::Class:
|
2019-10-02 14:35:23 +08:00
|
|
|
#include "clang/AST/TypeNodes.inc"
|
2014-07-07 14:20:47 +08:00
|
|
|
llvm_unreachable("Non-canonical and dependent types shouldn't get here");
|
|
|
|
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
llvm_unreachable("References shouldn't get here");
|
|
|
|
|
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
|
|
|
llvm_unreachable("Undeduced type shouldn't get here");
|
2014-07-07 14:20:47 +08:00
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
case Type::Pipe:
|
|
|
|
llvm_unreachable("Pipe types shouldn't get here");
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
case Type::Builtin:
|
|
|
|
// GCC treats vector and complex types as fundamental types.
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::Complex:
|
|
|
|
case Type::Atomic:
|
|
|
|
// FIXME: GCC treats block pointers as fundamental types?!
|
|
|
|
case Type::BlockPointer:
|
|
|
|
// abi::__fundamental_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv123__fundamental_type_infoE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
case Type::VariableArray:
|
|
|
|
// abi::__array_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv117__array_type_infoE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::FunctionNoProto:
|
|
|
|
case Type::FunctionProto:
|
2016-12-01 11:04:07 +08:00
|
|
|
// abi::__function_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv120__function_type_infoE";
|
2014-07-07 14:20:47 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Enum:
|
|
|
|
// abi::__enum_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv116__enum_type_infoE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Record: {
|
2018-03-23 05:14:16 +08:00
|
|
|
const CXXRecordDecl *RD =
|
|
|
|
cast<CXXRecordDecl>(cast<RecordType>(Ty)->getDecl());
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
if (!RD->hasDefinition() || !RD->getNumBases()) {
|
|
|
|
VTableName = ClassTypeInfo;
|
|
|
|
} else if (CanUseSingleInheritance(RD)) {
|
|
|
|
VTableName = SIClassTypeInfo;
|
|
|
|
} else {
|
|
|
|
VTableName = VMIClassTypeInfo;
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case Type::ObjCObject:
|
|
|
|
// Ignore protocol qualifiers.
|
|
|
|
Ty = cast<ObjCObjectType>(Ty)->getBaseType().getTypePtr();
|
|
|
|
|
|
|
|
// Handle id and Class.
|
|
|
|
if (isa<BuiltinType>(Ty)) {
|
|
|
|
VTableName = ClassTypeInfo;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(isa<ObjCInterfaceType>(Ty));
|
Fix clang -Wimplicit-fallthrough warnings across llvm, NFC
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
2018-11-02 03:54:45 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
if (cast<ObjCInterfaceType>(Ty)->getDecl()->getSuperClass()) {
|
|
|
|
VTableName = SIClassTypeInfo;
|
|
|
|
} else {
|
|
|
|
VTableName = ClassTypeInfo;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::ObjCObjectPointer:
|
|
|
|
case Type::Pointer:
|
|
|
|
// abi::__pointer_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv119__pointer_type_infoE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::MemberPointer:
|
|
|
|
// abi::__pointer_to_member_type_info.
|
|
|
|
VTableName = "_ZTVN10__cxxabiv129__pointer_to_member_type_infoE";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *VTable =
|
|
|
|
CGM.getModule().getOrInsertGlobal(VTableName, CGM.Int8PtrTy);
|
2018-03-23 09:36:23 +08:00
|
|
|
CGM.setDSOLocal(cast<llvm::GlobalValue>(VTable->stripPointerCasts()));
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
llvm::Type *PtrDiffTy =
|
|
|
|
CGM.getTypes().ConvertType(CGM.getContext().getPointerDiffType());
|
|
|
|
|
|
|
|
// The vtable address point is 2.
|
|
|
|
llvm::Constant *Two = llvm::ConstantInt::get(PtrDiffTy, 2);
|
2015-04-03 02:55:21 +08:00
|
|
|
VTable =
|
|
|
|
llvm::ConstantExpr::getInBoundsGetElementPtr(CGM.Int8PtrTy, VTable, Two);
|
2014-07-07 14:20:47 +08:00
|
|
|
VTable = llvm::ConstantExpr::getBitCast(VTable, CGM.Int8PtrTy);
|
|
|
|
|
|
|
|
Fields.push_back(VTable);
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Return the linkage that the type info and type info name constants
|
2014-07-07 14:20:47 +08:00
|
|
|
/// should have for the given type.
|
2018-05-22 04:10:54 +08:00
|
|
|
static llvm::GlobalVariable::LinkageTypes getTypeInfoLinkage(CodeGenModule &CGM,
|
|
|
|
QualType Ty) {
|
2014-07-07 14:20:47 +08:00
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// In addition, it and all of the intermediate abi::__pointer_type_info
|
|
|
|
// structs in the chain down to the abi::__class_type_info for the
|
|
|
|
// incomplete class type must be prevented from resolving to the
|
|
|
|
// corresponding type_info structs for the complete class type, possibly
|
|
|
|
// by making them local static objects. Finally, a dummy class RTTI is
|
|
|
|
// generated for the incomplete type that will not resolve to the final
|
|
|
|
// complete class RTTI (because the latter need not exist), possibly by
|
|
|
|
// making it a local static object.
|
|
|
|
if (ContainsIncompleteClassType(Ty))
|
2018-05-22 04:10:54 +08:00
|
|
|
return llvm::GlobalValue::InternalLinkage;
|
|
|
|
|
|
|
|
switch (Ty->getLinkage()) {
|
|
|
|
case NoLinkage:
|
|
|
|
case InternalLinkage:
|
|
|
|
case UniqueExternalLinkage:
|
|
|
|
return llvm::GlobalValue::InternalLinkage;
|
|
|
|
|
|
|
|
case VisibleNoLinkage:
|
|
|
|
case ModuleInternalLinkage:
|
|
|
|
case ModuleLinkage:
|
|
|
|
case ExternalLinkage:
|
|
|
|
// RTTI is not enabled, which means that this type info struct is going
|
|
|
|
// to be used for exception handling. Give it linkonce_odr linkage.
|
|
|
|
if (!CGM.getLangOpts().RTTI)
|
|
|
|
return llvm::GlobalValue::LinkOnceODRLinkage;
|
|
|
|
|
|
|
|
if (const RecordType *Record = dyn_cast<RecordType>(Ty)) {
|
|
|
|
const CXXRecordDecl *RD = cast<CXXRecordDecl>(Record->getDecl());
|
|
|
|
if (RD->hasAttr<WeakAttr>())
|
|
|
|
return llvm::GlobalValue::WeakODRLinkage;
|
|
|
|
if (CGM.getTriple().isWindowsItaniumEnvironment())
|
|
|
|
if (RD->hasAttr<DLLImportAttr>() &&
|
|
|
|
ShouldUseExternalRTTIDescriptor(CGM, Ty))
|
|
|
|
return llvm::GlobalValue::ExternalLinkage;
|
|
|
|
// MinGW always uses LinkOnceODRLinkage for type info.
|
|
|
|
if (RD->isDynamicClass() &&
|
|
|
|
!CGM.getContext()
|
|
|
|
.getTargetInfo()
|
|
|
|
.getTriple()
|
|
|
|
.isWindowsGNUEnvironment())
|
|
|
|
return CGM.getVTableLinkage(RD);
|
|
|
|
}
|
|
|
|
|
|
|
|
return llvm::GlobalValue::LinkOnceODRLinkage;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm_unreachable("Invalid linkage!");
|
2014-07-07 14:20:47 +08:00
|
|
|
}
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
llvm::Constant *ItaniumRTTIBuilder::BuildTypeInfo(QualType Ty) {
|
2014-07-07 14:20:47 +08:00
|
|
|
// We want to operate on the canonical type.
|
2016-03-16 20:14:43 +08:00
|
|
|
Ty = Ty.getCanonicalType();
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
// Check if we've already emitted an RTTI descriptor for this type.
|
2015-07-29 22:21:47 +08:00
|
|
|
SmallString<256> Name;
|
|
|
|
llvm::raw_svector_ostream Out(Name);
|
2014-07-07 14:20:47 +08:00
|
|
|
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty, Out);
|
|
|
|
|
|
|
|
llvm::GlobalVariable *OldGV = CGM.getModule().getNamedGlobal(Name);
|
|
|
|
if (OldGV && !OldGV->isDeclaration()) {
|
|
|
|
assert(!OldGV->hasAvailableExternallyLinkage() &&
|
|
|
|
"available_externally typeinfos not yet implemented");
|
|
|
|
|
|
|
|
return llvm::ConstantExpr::getBitCast(OldGV, CGM.Int8PtrTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if there is already an external RTTI descriptor for this type.
|
2018-07-24 08:43:47 +08:00
|
|
|
if (IsStandardLibraryRTTIDescriptor(Ty) ||
|
|
|
|
ShouldUseExternalRTTIDescriptor(CGM, Ty))
|
2014-07-07 14:20:47 +08:00
|
|
|
return GetAddrOfExternalRTTIDescriptor(Ty);
|
|
|
|
|
|
|
|
// Emit the standard library with external linkage.
|
2018-07-24 08:43:47 +08:00
|
|
|
llvm::GlobalVariable::LinkageTypes Linkage = getTypeInfoLinkage(CGM, Ty);
|
|
|
|
|
|
|
|
// Give the type_info object and name the formal visibility of the
|
|
|
|
// type itself.
|
|
|
|
llvm::GlobalValue::VisibilityTypes llvmVisibility;
|
|
|
|
if (llvm::GlobalValue::isLocalLinkage(Linkage))
|
|
|
|
// If the linkage is local, only default visibility makes sense.
|
|
|
|
llvmVisibility = llvm::GlobalValue::DefaultVisibility;
|
|
|
|
else if (CXXABI.classifyRTTIUniqueness(Ty, Linkage) ==
|
|
|
|
ItaniumCXXABI::RUK_NonUniqueHidden)
|
|
|
|
llvmVisibility = llvm::GlobalValue::HiddenVisibility;
|
2018-05-22 04:10:54 +08:00
|
|
|
else
|
2018-07-24 08:43:47 +08:00
|
|
|
llvmVisibility = CodeGenModule::GetLLVMVisibility(Ty->getVisibility());
|
|
|
|
|
|
|
|
llvm::GlobalValue::DLLStorageClassTypes DLLStorageClass =
|
|
|
|
llvm::GlobalValue::DefaultStorageClass;
|
|
|
|
if (CGM.getTriple().isWindowsItaniumEnvironment()) {
|
|
|
|
auto RD = Ty->getAsCXXRecordDecl();
|
|
|
|
if (RD && RD->hasAttr<DLLExportAttr>())
|
|
|
|
DLLStorageClass = llvm::GlobalValue::DLLExportStorageClass;
|
|
|
|
}
|
2018-05-22 04:10:54 +08:00
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
return BuildTypeInfo(Ty, Linkage, llvmVisibility, DLLStorageClass);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *ItaniumRTTIBuilder::BuildTypeInfo(
|
|
|
|
QualType Ty,
|
|
|
|
llvm::GlobalVariable::LinkageTypes Linkage,
|
|
|
|
llvm::GlobalValue::VisibilityTypes Visibility,
|
|
|
|
llvm::GlobalValue::DLLStorageClassTypes DLLStorageClass) {
|
2014-07-07 14:20:47 +08:00
|
|
|
// Add the vtable pointer.
|
|
|
|
BuildVTablePointer(cast<Type>(Ty));
|
|
|
|
|
|
|
|
// And the name.
|
2018-05-22 04:10:54 +08:00
|
|
|
llvm::GlobalVariable *TypeName = GetAddrOfTypeName(Ty, Linkage);
|
2014-07-07 14:20:47 +08:00
|
|
|
llvm::Constant *TypeNameField;
|
|
|
|
|
|
|
|
// If we're supposed to demote the visibility, be sure to set a flag
|
|
|
|
// to use a string comparison for type_info comparisons.
|
|
|
|
ItaniumCXXABI::RTTIUniquenessKind RTTIUniqueness =
|
2018-05-22 04:10:54 +08:00
|
|
|
CXXABI.classifyRTTIUniqueness(Ty, Linkage);
|
2014-07-07 14:20:47 +08:00
|
|
|
if (RTTIUniqueness != ItaniumCXXABI::RUK_Unique) {
|
|
|
|
// The flag is the sign bit, which on ARM64 is defined to be clear
|
|
|
|
// for global pointers. This is very ARM64-specific.
|
|
|
|
TypeNameField = llvm::ConstantExpr::getPtrToInt(TypeName, CGM.Int64Ty);
|
|
|
|
llvm::Constant *flag =
|
|
|
|
llvm::ConstantInt::get(CGM.Int64Ty, ((uint64_t)1) << 63);
|
|
|
|
TypeNameField = llvm::ConstantExpr::getAdd(TypeNameField, flag);
|
|
|
|
TypeNameField =
|
|
|
|
llvm::ConstantExpr::getIntToPtr(TypeNameField, CGM.Int8PtrTy);
|
|
|
|
} else {
|
|
|
|
TypeNameField = llvm::ConstantExpr::getBitCast(TypeName, CGM.Int8PtrTy);
|
|
|
|
}
|
|
|
|
Fields.push_back(TypeNameField);
|
|
|
|
|
|
|
|
switch (Ty->getTypeClass()) {
|
|
|
|
#define TYPE(Class, Base)
|
|
|
|
#define ABSTRACT_TYPE(Class, Base)
|
|
|
|
#define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(Class, Base) case Type::Class:
|
|
|
|
#define NON_CANONICAL_TYPE(Class, Base) case Type::Class:
|
|
|
|
#define DEPENDENT_TYPE(Class, Base) case Type::Class:
|
2019-10-02 14:35:23 +08:00
|
|
|
#include "clang/AST/TypeNodes.inc"
|
2014-07-07 14:20:47 +08:00
|
|
|
llvm_unreachable("Non-canonical and dependent types shouldn't get here");
|
|
|
|
|
|
|
|
// GCC treats vector types as fundamental types.
|
|
|
|
case Type::Builtin:
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::Complex:
|
|
|
|
case Type::BlockPointer:
|
|
|
|
// Itanium C++ ABI 2.9.5p4:
|
|
|
|
// abi::__fundamental_type_info adds no data members to std::type_info.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
llvm_unreachable("References shouldn't get here");
|
|
|
|
|
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
|
|
|
llvm_unreachable("Undeduced type shouldn't get here");
|
2014-07-07 14:20:47 +08:00
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
case Type::Pipe:
|
|
|
|
llvm_unreachable("Pipe type shouldn't get here");
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
case Type::VariableArray:
|
|
|
|
// Itanium C++ ABI 2.9.5p5:
|
|
|
|
// abi::__array_type_info adds no data members to std::type_info.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::FunctionNoProto:
|
2016-12-01 11:04:07 +08:00
|
|
|
case Type::FunctionProto:
|
2014-07-07 14:20:47 +08:00
|
|
|
// Itanium C++ ABI 2.9.5p5:
|
|
|
|
// abi::__function_type_info adds no data members to std::type_info.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Enum:
|
|
|
|
// Itanium C++ ABI 2.9.5p5:
|
|
|
|
// abi::__enum_type_info adds no data members to std::type_info.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Record: {
|
|
|
|
const CXXRecordDecl *RD =
|
|
|
|
cast<CXXRecordDecl>(cast<RecordType>(Ty)->getDecl());
|
|
|
|
if (!RD->hasDefinition() || !RD->getNumBases()) {
|
|
|
|
// We don't need to emit any fields.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CanUseSingleInheritance(RD))
|
|
|
|
BuildSIClassTypeInfo(RD);
|
|
|
|
else
|
|
|
|
BuildVMIClassTypeInfo(RD);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case Type::ObjCObject:
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
BuildObjCObjectTypeInfo(cast<ObjCObjectType>(Ty));
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::ObjCObjectPointer:
|
|
|
|
BuildPointerTypeInfo(cast<ObjCObjectPointerType>(Ty)->getPointeeType());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Pointer:
|
|
|
|
BuildPointerTypeInfo(cast<PointerType>(Ty)->getPointeeType());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::MemberPointer:
|
|
|
|
BuildPointerToMemberTypeInfo(cast<MemberPointerType>(Ty));
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Atomic:
|
|
|
|
// No fields, at least for the moment.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *Init = llvm::ConstantStruct::getAnon(Fields);
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
SmallString<256> Name;
|
|
|
|
llvm::raw_svector_ostream Out(Name);
|
|
|
|
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty, Out);
|
2015-01-16 07:18:01 +08:00
|
|
|
llvm::Module &M = CGM.getModule();
|
2018-07-24 08:43:47 +08:00
|
|
|
llvm::GlobalVariable *OldGV = M.getNamedGlobal(Name);
|
2014-07-07 14:20:47 +08:00
|
|
|
llvm::GlobalVariable *GV =
|
2015-01-16 07:18:01 +08:00
|
|
|
new llvm::GlobalVariable(M, Init->getType(),
|
2019-07-16 12:46:31 +08:00
|
|
|
/*isConstant=*/true, Linkage, Init, Name);
|
2015-01-16 07:18:01 +08:00
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
// If there's already an old global variable, replace it with the new one.
|
|
|
|
if (OldGV) {
|
|
|
|
GV->takeName(OldGV);
|
|
|
|
llvm::Constant *NewPtr =
|
|
|
|
llvm::ConstantExpr::getBitCast(GV, OldGV->getType());
|
|
|
|
OldGV->replaceAllUsesWith(NewPtr);
|
|
|
|
OldGV->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
2015-07-29 23:42:28 +08:00
|
|
|
if (CGM.supportsCOMDAT() && GV->isWeakForLinker())
|
|
|
|
GV->setComdat(M.getOrInsertComdat(GV->getName()));
|
|
|
|
|
2018-09-12 22:09:06 +08:00
|
|
|
CharUnits Align =
|
|
|
|
CGM.getContext().toCharUnitsFromBits(CGM.getTarget().getPointerAlign(0));
|
2019-10-03 21:00:29 +08:00
|
|
|
GV->setAlignment(Align.getAsAlign());
|
2018-09-12 22:09:06 +08:00
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
// The Itanium ABI specifies that type_info objects must be globally
|
|
|
|
// unique, with one exception: if the type is an incomplete class
|
|
|
|
// type or a (possibly indirect) pointer to one. That exception
|
|
|
|
// affects the general case of comparing type_info objects produced
|
|
|
|
// by the typeid operator, which is why the comparison operators on
|
|
|
|
// std::type_info generally use the type_info name pointers instead
|
|
|
|
// of the object addresses. However, the language's built-in uses
|
|
|
|
// of RTTI generally require class types to be complete, even when
|
|
|
|
// manipulating pointers to those class types. This allows the
|
|
|
|
// implementation of dynamic_cast to rely on address equality tests,
|
|
|
|
// which is much faster.
|
|
|
|
|
|
|
|
// All of this is to say that it's important that both the type_info
|
|
|
|
// object and the type_info name be uniqued when weakly emitted.
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
TypeName->setVisibility(Visibility);
|
2018-02-23 08:22:15 +08:00
|
|
|
CGM.setDSOLocal(TypeName);
|
2018-02-08 06:15:33 +08:00
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
GV->setVisibility(Visibility);
|
2018-02-23 08:22:15 +08:00
|
|
|
CGM.setDSOLocal(GV);
|
2016-12-03 06:46:18 +08:00
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
TypeName->setDLLStorageClass(DLLStorageClass);
|
|
|
|
GV->setDLLStorageClass(DLLStorageClass);
|
2014-07-07 14:20:47 +08:00
|
|
|
|
2019-06-08 03:10:08 +08:00
|
|
|
TypeName->setPartition(CGM.getCodeGenOpts().SymbolPartition);
|
|
|
|
GV->setPartition(CGM.getCodeGenOpts().SymbolPartition);
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
return llvm::ConstantExpr::getBitCast(GV, CGM.Int8PtrTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// BuildObjCObjectTypeInfo - Build the appropriate kind of type_info
|
|
|
|
/// for the given Objective-C object type.
|
|
|
|
void ItaniumRTTIBuilder::BuildObjCObjectTypeInfo(const ObjCObjectType *OT) {
|
|
|
|
// Drop qualifiers.
|
|
|
|
const Type *T = OT->getBaseType().getTypePtr();
|
|
|
|
assert(isa<BuiltinType>(T) || isa<ObjCInterfaceType>(T));
|
|
|
|
|
|
|
|
// The builtin types are abi::__class_type_infos and don't require
|
|
|
|
// extra fields.
|
|
|
|
if (isa<BuiltinType>(T)) return;
|
|
|
|
|
|
|
|
ObjCInterfaceDecl *Class = cast<ObjCInterfaceType>(T)->getDecl();
|
|
|
|
ObjCInterfaceDecl *Super = Class->getSuperClass();
|
|
|
|
|
|
|
|
// Root classes are also __class_type_info.
|
|
|
|
if (!Super) return;
|
|
|
|
|
|
|
|
QualType SuperTy = CGM.getContext().getObjCInterfaceType(Super);
|
|
|
|
|
|
|
|
// Everything else is single inheritance.
|
|
|
|
llvm::Constant *BaseTypeInfo =
|
|
|
|
ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(SuperTy);
|
|
|
|
Fields.push_back(BaseTypeInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// BuildSIClassTypeInfo - Build an abi::__si_class_type_info, used for single
|
|
|
|
/// inheritance, according to the Itanium C++ ABI, 2.95p6b.
|
|
|
|
void ItaniumRTTIBuilder::BuildSIClassTypeInfo(const CXXRecordDecl *RD) {
|
|
|
|
// Itanium C++ ABI 2.9.5p6b:
|
|
|
|
// It adds to abi::__class_type_info a single member pointing to the
|
|
|
|
// type_info structure for the base type,
|
|
|
|
llvm::Constant *BaseTypeInfo =
|
|
|
|
ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(RD->bases_begin()->getType());
|
|
|
|
Fields.push_back(BaseTypeInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// SeenBases - Contains virtual and non-virtual bases seen when traversing
|
|
|
|
/// a class hierarchy.
|
|
|
|
struct SeenBases {
|
|
|
|
llvm::SmallPtrSet<const CXXRecordDecl *, 16> NonVirtualBases;
|
|
|
|
llvm::SmallPtrSet<const CXXRecordDecl *, 16> VirtualBases;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ComputeVMIClassTypeInfoFlags - Compute the value of the flags member in
|
|
|
|
/// abi::__vmi_class_type_info.
|
|
|
|
///
|
|
|
|
static unsigned ComputeVMIClassTypeInfoFlags(const CXXBaseSpecifier *Base,
|
|
|
|
SeenBases &Bases) {
|
|
|
|
|
|
|
|
unsigned Flags = 0;
|
|
|
|
|
2019-10-03 04:45:16 +08:00
|
|
|
auto *BaseDecl =
|
|
|
|
cast<CXXRecordDecl>(Base->getType()->castAs<RecordType>()->getDecl());
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
if (Base->isVirtual()) {
|
|
|
|
// Mark the virtual base as seen.
|
2014-11-19 15:49:47 +08:00
|
|
|
if (!Bases.VirtualBases.insert(BaseDecl).second) {
|
2014-07-07 14:20:47 +08:00
|
|
|
// If this virtual base has been seen before, then the class is diamond
|
|
|
|
// shaped.
|
|
|
|
Flags |= ItaniumRTTIBuilder::VMI_DiamondShaped;
|
|
|
|
} else {
|
|
|
|
if (Bases.NonVirtualBases.count(BaseDecl))
|
|
|
|
Flags |= ItaniumRTTIBuilder::VMI_NonDiamondRepeat;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Mark the non-virtual base as seen.
|
2014-11-19 15:49:47 +08:00
|
|
|
if (!Bases.NonVirtualBases.insert(BaseDecl).second) {
|
2014-07-07 14:20:47 +08:00
|
|
|
// If this non-virtual base has been seen before, then the class has non-
|
|
|
|
// diamond shaped repeated inheritance.
|
|
|
|
Flags |= ItaniumRTTIBuilder::VMI_NonDiamondRepeat;
|
|
|
|
} else {
|
|
|
|
if (Bases.VirtualBases.count(BaseDecl))
|
|
|
|
Flags |= ItaniumRTTIBuilder::VMI_NonDiamondRepeat;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Walk all bases.
|
|
|
|
for (const auto &I : BaseDecl->bases())
|
|
|
|
Flags |= ComputeVMIClassTypeInfoFlags(&I, Bases);
|
|
|
|
|
|
|
|
return Flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned ComputeVMIClassTypeInfoFlags(const CXXRecordDecl *RD) {
|
|
|
|
unsigned Flags = 0;
|
|
|
|
SeenBases Bases;
|
|
|
|
|
|
|
|
// Walk all bases.
|
|
|
|
for (const auto &I : RD->bases())
|
|
|
|
Flags |= ComputeVMIClassTypeInfoFlags(&I, Bases);
|
|
|
|
|
|
|
|
return Flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// BuildVMIClassTypeInfo - Build an abi::__vmi_class_type_info, used for
|
|
|
|
/// classes with bases that do not satisfy the abi::__si_class_type_info
|
|
|
|
/// constraints, according ti the Itanium C++ ABI, 2.9.5p5c.
|
|
|
|
void ItaniumRTTIBuilder::BuildVMIClassTypeInfo(const CXXRecordDecl *RD) {
|
|
|
|
llvm::Type *UnsignedIntLTy =
|
|
|
|
CGM.getTypes().ConvertType(CGM.getContext().UnsignedIntTy);
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p6c:
|
|
|
|
// __flags is a word with flags describing details about the class
|
|
|
|
// structure, which may be referenced by using the __flags_masks
|
|
|
|
// enumeration. These flags refer to both direct and indirect bases.
|
|
|
|
unsigned Flags = ComputeVMIClassTypeInfoFlags(RD);
|
|
|
|
Fields.push_back(llvm::ConstantInt::get(UnsignedIntLTy, Flags));
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p6c:
|
|
|
|
// __base_count is a word with the number of direct proper base class
|
|
|
|
// descriptions that follow.
|
|
|
|
Fields.push_back(llvm::ConstantInt::get(UnsignedIntLTy, RD->getNumBases()));
|
|
|
|
|
|
|
|
if (!RD->getNumBases())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Now add the base class descriptions.
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p6c:
|
|
|
|
// __base_info[] is an array of base class descriptions -- one for every
|
|
|
|
// direct proper base. Each description is of the type:
|
|
|
|
//
|
|
|
|
// struct abi::__base_class_type_info {
|
|
|
|
// public:
|
|
|
|
// const __class_type_info *__base_type;
|
|
|
|
// long __offset_flags;
|
|
|
|
//
|
|
|
|
// enum __offset_flags_masks {
|
|
|
|
// __virtual_mask = 0x1,
|
|
|
|
// __public_mask = 0x2,
|
|
|
|
// __offset_shift = 8
|
|
|
|
// };
|
|
|
|
// };
|
2016-08-26 06:16:30 +08:00
|
|
|
|
|
|
|
// If we're in mingw and 'long' isn't wide enough for a pointer, use 'long
|
|
|
|
// long' instead of 'long' for __offset_flags. libstdc++abi uses long long on
|
|
|
|
// LLP64 platforms.
|
|
|
|
// FIXME: Consider updating libc++abi to match, and extend this logic to all
|
|
|
|
// LLP64 platforms.
|
|
|
|
QualType OffsetFlagsTy = CGM.getContext().LongTy;
|
|
|
|
const TargetInfo &TI = CGM.getContext().getTargetInfo();
|
|
|
|
if (TI.getTriple().isOSCygMing() && TI.getPointerWidth(0) > TI.getLongWidth())
|
|
|
|
OffsetFlagsTy = CGM.getContext().LongLongTy;
|
|
|
|
llvm::Type *OffsetFlagsLTy =
|
|
|
|
CGM.getTypes().ConvertType(OffsetFlagsTy);
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
for (const auto &Base : RD->bases()) {
|
|
|
|
// The __base_type member points to the RTTI for the base type.
|
|
|
|
Fields.push_back(ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(Base.getType()));
|
|
|
|
|
2019-10-03 04:45:16 +08:00
|
|
|
auto *BaseDecl =
|
|
|
|
cast<CXXRecordDecl>(Base.getType()->castAs<RecordType>()->getDecl());
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
int64_t OffsetFlags = 0;
|
|
|
|
|
|
|
|
// All but the lower 8 bits of __offset_flags are a signed offset.
|
|
|
|
// For a non-virtual base, this is the offset in the object of the base
|
|
|
|
// subobject. For a virtual base, this is the offset in the virtual table of
|
|
|
|
// the virtual base offset for the virtual base referenced (negative).
|
|
|
|
CharUnits Offset;
|
|
|
|
if (Base.isVirtual())
|
|
|
|
Offset =
|
|
|
|
CGM.getItaniumVTableContext().getVirtualBaseOffsetOffset(RD, BaseDecl);
|
|
|
|
else {
|
|
|
|
const ASTRecordLayout &Layout = CGM.getContext().getASTRecordLayout(RD);
|
|
|
|
Offset = Layout.getBaseClassOffset(BaseDecl);
|
|
|
|
};
|
|
|
|
|
|
|
|
OffsetFlags = uint64_t(Offset.getQuantity()) << 8;
|
|
|
|
|
|
|
|
// The low-order byte of __offset_flags contains flags, as given by the
|
|
|
|
// masks from the enumeration __offset_flags_masks.
|
|
|
|
if (Base.isVirtual())
|
|
|
|
OffsetFlags |= BCTI_Virtual;
|
|
|
|
if (Base.getAccessSpecifier() == AS_public)
|
|
|
|
OffsetFlags |= BCTI_Public;
|
|
|
|
|
2016-08-26 06:16:30 +08:00
|
|
|
Fields.push_back(llvm::ConstantInt::get(OffsetFlagsLTy, OffsetFlags));
|
2014-07-07 14:20:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-01 11:32:42 +08:00
|
|
|
/// Compute the flags for a __pbase_type_info, and remove the corresponding
|
|
|
|
/// pieces from \p Type.
|
|
|
|
static unsigned extractPBaseFlags(ASTContext &Ctx, QualType &Type) {
|
|
|
|
unsigned Flags = 0;
|
|
|
|
|
|
|
|
if (Type.isConstQualified())
|
|
|
|
Flags |= ItaniumRTTIBuilder::PTI_Const;
|
|
|
|
if (Type.isVolatileQualified())
|
|
|
|
Flags |= ItaniumRTTIBuilder::PTI_Volatile;
|
|
|
|
if (Type.isRestrictQualified())
|
|
|
|
Flags |= ItaniumRTTIBuilder::PTI_Restrict;
|
|
|
|
Type = Type.getUnqualifiedType();
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// When the abi::__pbase_type_info is for a direct or indirect pointer to an
|
|
|
|
// incomplete class type, the incomplete target type flag is set.
|
|
|
|
if (ContainsIncompleteClassType(Type))
|
|
|
|
Flags |= ItaniumRTTIBuilder::PTI_Incomplete;
|
|
|
|
|
|
|
|
if (auto *Proto = Type->getAs<FunctionProtoType>()) {
|
2018-05-03 11:58:32 +08:00
|
|
|
if (Proto->isNothrow()) {
|
2016-12-01 11:32:42 +08:00
|
|
|
Flags |= ItaniumRTTIBuilder::PTI_Noexcept;
|
2018-01-05 15:57:12 +08:00
|
|
|
Type = Ctx.getFunctionTypeWithExceptionSpec(Type, EST_None);
|
2016-12-01 11:32:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Flags;
|
|
|
|
}
|
|
|
|
|
2014-07-07 14:20:47 +08:00
|
|
|
/// BuildPointerTypeInfo - Build an abi::__pointer_type_info struct,
|
|
|
|
/// used for pointer types.
|
|
|
|
void ItaniumRTTIBuilder::BuildPointerTypeInfo(QualType PointeeTy) {
|
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// __flags is a flag word describing the cv-qualification and other
|
|
|
|
// attributes of the type pointed to
|
2016-12-01 11:32:42 +08:00
|
|
|
unsigned Flags = extractPBaseFlags(CGM.getContext(), PointeeTy);
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
llvm::Type *UnsignedIntLTy =
|
|
|
|
CGM.getTypes().ConvertType(CGM.getContext().UnsignedIntTy);
|
|
|
|
Fields.push_back(llvm::ConstantInt::get(UnsignedIntLTy, Flags));
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// __pointee is a pointer to the std::type_info derivation for the
|
|
|
|
// unqualified type being pointed to.
|
|
|
|
llvm::Constant *PointeeTypeInfo =
|
2016-12-01 11:32:42 +08:00
|
|
|
ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(PointeeTy);
|
2014-07-07 14:20:47 +08:00
|
|
|
Fields.push_back(PointeeTypeInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// BuildPointerToMemberTypeInfo - Build an abi::__pointer_to_member_type_info
|
|
|
|
/// struct, used for member pointer types.
|
|
|
|
void
|
|
|
|
ItaniumRTTIBuilder::BuildPointerToMemberTypeInfo(const MemberPointerType *Ty) {
|
|
|
|
QualType PointeeTy = Ty->getPointeeType();
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// __flags is a flag word describing the cv-qualification and other
|
|
|
|
// attributes of the type pointed to.
|
2016-12-01 11:32:42 +08:00
|
|
|
unsigned Flags = extractPBaseFlags(CGM.getContext(), PointeeTy);
|
2014-07-07 14:20:47 +08:00
|
|
|
|
|
|
|
const RecordType *ClassType = cast<RecordType>(Ty->getClass());
|
|
|
|
if (IsIncompleteClassType(ClassType))
|
|
|
|
Flags |= PTI_ContainingClassIncomplete;
|
|
|
|
|
|
|
|
llvm::Type *UnsignedIntLTy =
|
|
|
|
CGM.getTypes().ConvertType(CGM.getContext().UnsignedIntTy);
|
|
|
|
Fields.push_back(llvm::ConstantInt::get(UnsignedIntLTy, Flags));
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p7:
|
|
|
|
// __pointee is a pointer to the std::type_info derivation for the
|
|
|
|
// unqualified type being pointed to.
|
|
|
|
llvm::Constant *PointeeTypeInfo =
|
2016-12-01 11:32:42 +08:00
|
|
|
ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(PointeeTy);
|
2014-07-07 14:20:47 +08:00
|
|
|
Fields.push_back(PointeeTypeInfo);
|
|
|
|
|
|
|
|
// Itanium C++ ABI 2.9.5p9:
|
|
|
|
// __context is a pointer to an abi::__class_type_info corresponding to the
|
|
|
|
// class type containing the member pointed to
|
|
|
|
// (e.g., the "A" in "int A::*").
|
|
|
|
Fields.push_back(
|
|
|
|
ItaniumRTTIBuilder(CXXABI).BuildTypeInfo(QualType(ClassType, 0)));
|
|
|
|
}
|
|
|
|
|
2015-03-18 04:35:00 +08:00
|
|
|
llvm::Constant *ItaniumCXXABI::getAddrOfRTTIDescriptor(QualType Ty) {
|
2014-07-07 14:20:47 +08:00
|
|
|
return ItaniumRTTIBuilder(*this).BuildTypeInfo(Ty);
|
|
|
|
}
|
|
|
|
|
2018-07-24 08:43:47 +08:00
|
|
|
void ItaniumCXXABI::EmitFundamentalRTTIDescriptors(const CXXRecordDecl *RD) {
|
2016-02-03 09:32:42 +08:00
|
|
|
// Types added here must also be added to TypeInfoIsInStandardLibrary.
|
2014-07-07 14:20:47 +08:00
|
|
|
QualType FundamentalTypes[] = {
|
|
|
|
getContext().VoidTy, getContext().NullPtrTy,
|
|
|
|
getContext().BoolTy, getContext().WCharTy,
|
|
|
|
getContext().CharTy, getContext().UnsignedCharTy,
|
|
|
|
getContext().SignedCharTy, getContext().ShortTy,
|
|
|
|
getContext().UnsignedShortTy, getContext().IntTy,
|
|
|
|
getContext().UnsignedIntTy, getContext().LongTy,
|
|
|
|
getContext().UnsignedLongTy, getContext().LongLongTy,
|
2016-02-03 09:32:42 +08:00
|
|
|
getContext().UnsignedLongLongTy, getContext().Int128Ty,
|
|
|
|
getContext().UnsignedInt128Ty, getContext().HalfTy,
|
2014-07-07 14:20:47 +08:00
|
|
|
getContext().FloatTy, getContext().DoubleTy,
|
2016-05-09 16:52:33 +08:00
|
|
|
getContext().LongDoubleTy, getContext().Float128Ty,
|
2018-05-01 13:02:45 +08:00
|
|
|
getContext().Char8Ty, getContext().Char16Ty,
|
|
|
|
getContext().Char32Ty
|
2014-07-07 14:20:47 +08:00
|
|
|
};
|
2018-07-24 08:43:47 +08:00
|
|
|
llvm::GlobalValue::DLLStorageClassTypes DLLStorageClass =
|
|
|
|
RD->hasAttr<DLLExportAttr>()
|
|
|
|
? llvm::GlobalValue::DLLExportStorageClass
|
|
|
|
: llvm::GlobalValue::DefaultStorageClass;
|
|
|
|
llvm::GlobalValue::VisibilityTypes Visibility =
|
|
|
|
CodeGenModule::GetLLVMVisibility(RD->getVisibility());
|
|
|
|
for (const QualType &FundamentalType : FundamentalTypes) {
|
|
|
|
QualType PointerType = getContext().getPointerType(FundamentalType);
|
|
|
|
QualType PointerTypeConst = getContext().getPointerType(
|
|
|
|
FundamentalType.withConst());
|
|
|
|
for (QualType Type : {FundamentalType, PointerType, PointerTypeConst})
|
|
|
|
ItaniumRTTIBuilder(*this).BuildTypeInfo(
|
|
|
|
Type, llvm::GlobalValue::ExternalLinkage,
|
|
|
|
Visibility, DLLStorageClass);
|
|
|
|
}
|
2014-07-07 14:20:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// What sort of uniqueness rules should we use for the RTTI for the
|
|
|
|
/// given type?
|
|
|
|
ItaniumCXXABI::RTTIUniquenessKind ItaniumCXXABI::classifyRTTIUniqueness(
|
|
|
|
QualType CanTy, llvm::GlobalValue::LinkageTypes Linkage) const {
|
|
|
|
if (shouldRTTIBeUnique())
|
|
|
|
return RUK_Unique;
|
|
|
|
|
|
|
|
// It's only necessary for linkonce_odr or weak_odr linkage.
|
|
|
|
if (Linkage != llvm::GlobalValue::LinkOnceODRLinkage &&
|
|
|
|
Linkage != llvm::GlobalValue::WeakODRLinkage)
|
|
|
|
return RUK_Unique;
|
|
|
|
|
|
|
|
// It's only necessary with default visibility.
|
|
|
|
if (CanTy->getVisibility() != DefaultVisibility)
|
|
|
|
return RUK_Unique;
|
|
|
|
|
|
|
|
// If we're not required to publish this symbol, hide it.
|
|
|
|
if (Linkage == llvm::GlobalValue::LinkOnceODRLinkage)
|
|
|
|
return RUK_NonUniqueHidden;
|
|
|
|
|
|
|
|
// If we're required to publish this symbol, as we might be under an
|
|
|
|
// explicit instantiation, leave it with default visibility but
|
|
|
|
// enable string-comparisons.
|
|
|
|
assert(Linkage == llvm::GlobalValue::WeakODRLinkage);
|
|
|
|
return RUK_NonUniqueVisible;
|
|
|
|
}
|
2014-09-16 03:20:10 +08:00
|
|
|
|
2014-09-16 23:18:21 +08:00
|
|
|
// Find out how to codegen the complete destructor and constructor
|
|
|
|
namespace {
|
|
|
|
enum class StructorCodegen { Emit, RAUW, Alias, COMDAT };
|
|
|
|
}
|
|
|
|
static StructorCodegen getCodegenToUse(CodeGenModule &CGM,
|
|
|
|
const CXXMethodDecl *MD) {
|
|
|
|
if (!CGM.getCodeGenOpts().CXXCtorDtorAliases)
|
|
|
|
return StructorCodegen::Emit;
|
|
|
|
|
|
|
|
// The complete and base structors are not equivalent if there are any virtual
|
|
|
|
// bases, so emit separate functions.
|
|
|
|
if (MD->getParent()->getNumVBases())
|
|
|
|
return StructorCodegen::Emit;
|
|
|
|
|
|
|
|
GlobalDecl AliasDecl;
|
|
|
|
if (const auto *DD = dyn_cast<CXXDestructorDecl>(MD)) {
|
|
|
|
AliasDecl = GlobalDecl(DD, Dtor_Complete);
|
|
|
|
} else {
|
|
|
|
const auto *CD = cast<CXXConstructorDecl>(MD);
|
|
|
|
AliasDecl = GlobalDecl(CD, Ctor_Complete);
|
|
|
|
}
|
|
|
|
llvm::GlobalValue::LinkageTypes Linkage = CGM.getFunctionLinkage(AliasDecl);
|
|
|
|
|
2018-07-29 11:05:07 +08:00
|
|
|
if (llvm::GlobalValue::isDiscardableIfUnused(Linkage))
|
|
|
|
return StructorCodegen::RAUW;
|
2018-05-21 19:47:45 +08:00
|
|
|
|
2018-05-14 19:35:44 +08:00
|
|
|
// FIXME: Should we allow available_externally aliases?
|
2018-07-29 11:05:07 +08:00
|
|
|
if (!llvm::GlobalAlias::isValidLinkage(Linkage))
|
|
|
|
return StructorCodegen::RAUW;
|
2014-09-16 23:18:21 +08:00
|
|
|
|
2014-09-17 04:19:43 +08:00
|
|
|
if (llvm::GlobalValue::isWeakForLinker(Linkage)) {
|
2017-01-18 05:46:38 +08:00
|
|
|
// Only ELF and wasm support COMDATs with arbitrary names (C5/D5).
|
|
|
|
if (CGM.getTarget().getTriple().isOSBinFormatELF() ||
|
|
|
|
CGM.getTarget().getTriple().isOSBinFormatWasm())
|
2014-09-17 04:19:43 +08:00
|
|
|
return StructorCodegen::COMDAT;
|
|
|
|
return StructorCodegen::Emit;
|
|
|
|
}
|
2014-09-16 23:18:21 +08:00
|
|
|
|
|
|
|
return StructorCodegen::Alias;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void emitConstructorDestructorAlias(CodeGenModule &CGM,
|
|
|
|
GlobalDecl AliasDecl,
|
|
|
|
GlobalDecl TargetDecl) {
|
|
|
|
llvm::GlobalValue::LinkageTypes Linkage = CGM.getFunctionLinkage(AliasDecl);
|
|
|
|
|
|
|
|
StringRef MangledName = CGM.getMangledName(AliasDecl);
|
|
|
|
llvm::GlobalValue *Entry = CGM.GetGlobalValue(MangledName);
|
|
|
|
if (Entry && !Entry->isDeclaration())
|
|
|
|
return;
|
|
|
|
|
|
|
|
auto *Aliasee = cast<llvm::GlobalValue>(CGM.GetAddrOfGlobal(TargetDecl));
|
|
|
|
|
|
|
|
// Create the alias with no name.
|
2015-09-15 02:38:22 +08:00
|
|
|
auto *Alias = llvm::GlobalAlias::create(Linkage, "", Aliasee);
|
2014-09-16 23:18:21 +08:00
|
|
|
|
2018-06-19 04:58:54 +08:00
|
|
|
// Constructors and destructors are always unnamed_addr.
|
|
|
|
Alias->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
|
|
|
|
|
2014-09-16 23:18:21 +08:00
|
|
|
// Switch any previous uses to the alias.
|
|
|
|
if (Entry) {
|
2015-09-15 09:39:27 +08:00
|
|
|
assert(Entry->getType() == Aliasee->getType() &&
|
2014-09-16 23:18:21 +08:00
|
|
|
"declaration exists with different type");
|
|
|
|
Alias->takeName(Entry);
|
|
|
|
Entry->replaceAllUsesWith(Alias);
|
|
|
|
Entry->eraseFromParent();
|
|
|
|
} else {
|
|
|
|
Alias->setName(MangledName);
|
2014-09-16 03:20:10 +08:00
|
|
|
}
|
|
|
|
|
2014-09-16 23:18:21 +08:00
|
|
|
// Finally, set up the alias with its proper name and attributes.
|
2018-03-01 08:35:47 +08:00
|
|
|
CGM.SetCommonAttributes(AliasDecl, Alias);
|
2014-09-16 23:18:21 +08:00
|
|
|
}
|
|
|
|
|
2019-03-23 07:05:10 +08:00
|
|
|
void ItaniumCXXABI::emitCXXStructor(GlobalDecl GD) {
|
|
|
|
auto *MD = cast<CXXMethodDecl>(GD.getDecl());
|
2014-09-16 23:18:21 +08:00
|
|
|
auto *CD = dyn_cast<CXXConstructorDecl>(MD);
|
|
|
|
const CXXDestructorDecl *DD = CD ? nullptr : cast<CXXDestructorDecl>(MD);
|
|
|
|
|
|
|
|
StructorCodegen CGType = getCodegenToUse(CGM, MD);
|
|
|
|
|
2019-03-23 07:05:10 +08:00
|
|
|
if (CD ? GD.getCtorType() == Ctor_Complete
|
|
|
|
: GD.getDtorType() == Dtor_Complete) {
|
2014-09-16 23:18:21 +08:00
|
|
|
GlobalDecl BaseDecl;
|
2019-03-23 07:05:10 +08:00
|
|
|
if (CD)
|
|
|
|
BaseDecl = GD.getWithCtorType(Ctor_Base);
|
|
|
|
else
|
|
|
|
BaseDecl = GD.getWithDtorType(Dtor_Base);
|
2014-09-16 23:18:21 +08:00
|
|
|
|
|
|
|
if (CGType == StructorCodegen::Alias || CGType == StructorCodegen::COMDAT) {
|
2019-03-23 07:05:10 +08:00
|
|
|
emitConstructorDestructorAlias(CGM, GD, BaseDecl);
|
2014-09-16 23:18:21 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CGType == StructorCodegen::RAUW) {
|
2019-03-23 07:05:10 +08:00
|
|
|
StringRef MangledName = CGM.getMangledName(GD);
|
2015-08-31 21:20:44 +08:00
|
|
|
auto *Aliasee = CGM.GetAddrOfGlobal(BaseDecl);
|
2014-09-16 23:18:21 +08:00
|
|
|
CGM.addReplacement(MangledName, Aliasee);
|
|
|
|
return;
|
2014-09-16 03:20:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The base destructor is equivalent to the base destructor of its
|
|
|
|
// base class if there is exactly one non-virtual base class with a
|
|
|
|
// non-trivial destructor, there are no fields with a non-trivial
|
|
|
|
// destructor, and the body of the destructor is trivial.
|
2019-03-23 07:05:10 +08:00
|
|
|
if (DD && GD.getDtorType() == Dtor_Base &&
|
|
|
|
CGType != StructorCodegen::COMDAT &&
|
2014-09-16 23:18:21 +08:00
|
|
|
!CGM.TryEmitBaseDestructorAsAlias(DD))
|
2014-09-16 03:20:10 +08:00
|
|
|
return;
|
|
|
|
|
2017-10-13 09:55:36 +08:00
|
|
|
// FIXME: The deleting destructor is equivalent to the selected operator
|
|
|
|
// delete if:
|
|
|
|
// * either the delete is a destroying operator delete or the destructor
|
|
|
|
// would be trivial if it weren't virtual,
|
|
|
|
// * the conversion from the 'this' parameter to the first parameter of the
|
|
|
|
// destructor is equivalent to a bitcast,
|
|
|
|
// * the destructor does not have an implicit "this" return, and
|
|
|
|
// * the operator delete has the same calling convention and IR function type
|
|
|
|
// as the destructor.
|
|
|
|
// In such cases we should try to emit the deleting dtor as an alias to the
|
|
|
|
// selected 'operator delete'.
|
|
|
|
|
2019-03-23 07:05:10 +08:00
|
|
|
llvm::Function *Fn = CGM.codegenCXXStructor(GD);
|
2014-09-16 03:20:10 +08:00
|
|
|
|
2014-09-16 23:18:21 +08:00
|
|
|
if (CGType == StructorCodegen::COMDAT) {
|
|
|
|
SmallString<256> Buffer;
|
|
|
|
llvm::raw_svector_ostream Out(Buffer);
|
|
|
|
if (DD)
|
|
|
|
getMangleContext().mangleCXXDtorComdat(DD, Out);
|
|
|
|
else
|
|
|
|
getMangleContext().mangleCXXCtorComdat(CD, Out);
|
|
|
|
llvm::Comdat *C = CGM.getModule().getOrInsertComdat(Out.str());
|
|
|
|
Fn->setComdat(C);
|
2015-01-16 05:36:08 +08:00
|
|
|
} else {
|
|
|
|
CGM.maybeSetTrivialComdat(*MD, *Fn);
|
2014-09-16 03:20:10 +08:00
|
|
|
}
|
|
|
|
}
|
2015-03-04 03:21:04 +08:00
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getBeginCatchFn(CodeGenModule &CGM) {
|
2015-03-04 03:21:04 +08:00
|
|
|
// void *__cxa_begin_catch(void*);
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(
|
2019-07-16 12:46:31 +08:00
|
|
|
CGM.Int8PtrTy, CGM.Int8PtrTy, /*isVarArg=*/false);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
return CGM.CreateRuntimeFunction(FTy, "__cxa_begin_catch");
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getEndCatchFn(CodeGenModule &CGM) {
|
2015-03-04 03:21:04 +08:00
|
|
|
// void __cxa_end_catch();
|
|
|
|
llvm::FunctionType *FTy =
|
2019-07-16 12:46:31 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, /*isVarArg=*/false);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
return CGM.CreateRuntimeFunction(FTy, "__cxa_end_catch");
|
|
|
|
}
|
|
|
|
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getGetExceptionPtrFn(CodeGenModule &CGM) {
|
2015-03-04 03:21:04 +08:00
|
|
|
// void *__cxa_get_exception_ptr(void*);
|
|
|
|
llvm::FunctionType *FTy = llvm::FunctionType::get(
|
2019-07-16 12:46:31 +08:00
|
|
|
CGM.Int8PtrTy, CGM.Int8PtrTy, /*isVarArg=*/false);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
return CGM.CreateRuntimeFunction(FTy, "__cxa_get_exception_ptr");
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// A cleanup to call __cxa_end_catch. In many cases, the caught
|
|
|
|
/// exception type lets us state definitively that the thrown exception
|
|
|
|
/// type does not have a destructor. In particular:
|
|
|
|
/// - Catch-alls tell us nothing, so we have to conservatively
|
|
|
|
/// assume that the thrown exception might have a destructor.
|
|
|
|
/// - Catches by reference behave according to their base types.
|
|
|
|
/// - Catches of non-record types will only trigger for exceptions
|
|
|
|
/// of non-record types, which never have destructors.
|
|
|
|
/// - Catches of record types can trigger for arbitrary subclasses
|
|
|
|
/// of the caught type, so we have to assume the actual thrown
|
|
|
|
/// exception type might have a throwing destructor, even if the
|
|
|
|
/// caught type's destructor is trivial or nothrow.
|
2015-08-19 06:40:54 +08:00
|
|
|
struct CallEndCatch final : EHScopeStack::Cleanup {
|
2015-03-04 03:21:04 +08:00
|
|
|
CallEndCatch(bool MightThrow) : MightThrow(MightThrow) {}
|
|
|
|
bool MightThrow;
|
|
|
|
|
|
|
|
void Emit(CodeGenFunction &CGF, Flags flags) override {
|
|
|
|
if (!MightThrow) {
|
|
|
|
CGF.EmitNounwindRuntimeCall(getEndCatchFn(CGF.CGM));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
CGF.EmitRuntimeCallOrInvoke(getEndCatchFn(CGF.CGM));
|
|
|
|
}
|
|
|
|
};
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
/// Emits a call to __cxa_begin_catch and enters a cleanup to call
|
|
|
|
/// __cxa_end_catch.
|
|
|
|
///
|
|
|
|
/// \param EndMightThrow - true if __cxa_end_catch might throw
|
|
|
|
static llvm::Value *CallBeginCatch(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *Exn,
|
|
|
|
bool EndMightThrow) {
|
|
|
|
llvm::CallInst *call =
|
|
|
|
CGF.EmitNounwindRuntimeCall(getBeginCatchFn(CGF.CGM), Exn);
|
|
|
|
|
|
|
|
CGF.EHStack.pushCleanup<CallEndCatch>(NormalAndEHCleanup, EndMightThrow);
|
|
|
|
|
|
|
|
return call;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A "special initializer" callback for initializing a catch
|
|
|
|
/// parameter during catch initialization.
|
|
|
|
static void InitCatchParam(CodeGenFunction &CGF,
|
|
|
|
const VarDecl &CatchParam,
|
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 ParamAddr,
|
2015-03-04 03:21:04 +08:00
|
|
|
SourceLocation Loc) {
|
|
|
|
// Load the exception from where the landing pad saved it.
|
|
|
|
llvm::Value *Exn = CGF.getExceptionFromSlot();
|
|
|
|
|
|
|
|
CanQualType CatchType =
|
|
|
|
CGF.CGM.getContext().getCanonicalType(CatchParam.getType());
|
|
|
|
llvm::Type *LLVMCatchTy = CGF.ConvertTypeForMem(CatchType);
|
|
|
|
|
|
|
|
// If we're catching by reference, we can just cast the object
|
|
|
|
// pointer to the appropriate pointer.
|
|
|
|
if (isa<ReferenceType>(CatchType)) {
|
|
|
|
QualType CaughtType = cast<ReferenceType>(CatchType)->getPointeeType();
|
|
|
|
bool EndCatchMightThrow = CaughtType->isRecordType();
|
|
|
|
|
|
|
|
// __cxa_begin_catch returns the adjusted object pointer.
|
|
|
|
llvm::Value *AdjustedExn = CallBeginCatch(CGF, Exn, EndCatchMightThrow);
|
|
|
|
|
|
|
|
// We have no way to tell the personality function that we're
|
|
|
|
// catching by reference, so if we're catching a pointer,
|
|
|
|
// __cxa_begin_catch will actually return that pointer by value.
|
|
|
|
if (const PointerType *PT = dyn_cast<PointerType>(CaughtType)) {
|
|
|
|
QualType PointeeType = PT->getPointeeType();
|
|
|
|
|
|
|
|
// When catching by reference, generally we should just ignore
|
|
|
|
// this by-value pointer and use the exception object instead.
|
|
|
|
if (!PointeeType->isRecordType()) {
|
|
|
|
|
|
|
|
// Exn points to the struct _Unwind_Exception header, which
|
|
|
|
// we have to skip past in order to reach the exception data.
|
|
|
|
unsigned HeaderSize =
|
|
|
|
CGF.CGM.getTargetCodeGenInfo().getSizeOfUnwindException();
|
|
|
|
AdjustedExn = CGF.Builder.CreateConstGEP1_32(Exn, HeaderSize);
|
|
|
|
|
|
|
|
// However, if we're catching a pointer-to-record type that won't
|
|
|
|
// work, because the personality function might have adjusted
|
|
|
|
// the pointer. There's actually no way for us to fully satisfy
|
|
|
|
// the language/ABI contract here: we can't use Exn because it
|
|
|
|
// might have the wrong adjustment, but we can't use the by-value
|
|
|
|
// pointer because it's off by a level of abstraction.
|
|
|
|
//
|
|
|
|
// The current solution is to dump the adjusted pointer into an
|
|
|
|
// alloca, which breaks language semantics (because changing the
|
|
|
|
// pointer doesn't change the exception) but at least works.
|
|
|
|
// The better solution would be to filter out non-exact matches
|
|
|
|
// and rethrow them, but this is tricky because the rethrow
|
|
|
|
// really needs to be catchable by other sites at this landing
|
|
|
|
// pad. The best solution is to fix the personality function.
|
|
|
|
} else {
|
|
|
|
// Pull the pointer for the reference type off.
|
|
|
|
llvm::Type *PtrTy =
|
|
|
|
cast<llvm::PointerType>(LLVMCatchTy)->getElementType();
|
|
|
|
|
|
|
|
// Create the temporary and write the adjusted pointer into it.
|
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 ExnPtrTmp =
|
|
|
|
CGF.CreateTempAlloca(PtrTy, CGF.getPointerAlign(), "exn.byref.tmp");
|
2015-03-04 03:21:04 +08:00
|
|
|
llvm::Value *Casted = CGF.Builder.CreateBitCast(AdjustedExn, PtrTy);
|
|
|
|
CGF.Builder.CreateStore(Casted, ExnPtrTmp);
|
|
|
|
|
|
|
|
// Bind the reference to the temporary.
|
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
|
|
|
AdjustedExn = ExnPtrTmp.getPointer();
|
2015-03-04 03:21:04 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *ExnCast =
|
|
|
|
CGF.Builder.CreateBitCast(AdjustedExn, LLVMCatchTy, "exn.byref");
|
|
|
|
CGF.Builder.CreateStore(ExnCast, ParamAddr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Scalars and complexes.
|
|
|
|
TypeEvaluationKind TEK = CGF.getEvaluationKind(CatchType);
|
|
|
|
if (TEK != TEK_Aggregate) {
|
|
|
|
llvm::Value *AdjustedExn = CallBeginCatch(CGF, Exn, false);
|
|
|
|
|
|
|
|
// If the catch type is a pointer type, __cxa_begin_catch returns
|
|
|
|
// the pointer by value.
|
|
|
|
if (CatchType->hasPointerRepresentation()) {
|
|
|
|
llvm::Value *CastExn =
|
|
|
|
CGF.Builder.CreateBitCast(AdjustedExn, LLVMCatchTy, "exn.casted");
|
|
|
|
|
|
|
|
switch (CatchType.getQualifiers().getObjCLifetime()) {
|
|
|
|
case Qualifiers::OCL_Strong:
|
|
|
|
CastExn = CGF.EmitARCRetainNonBlock(CastExn);
|
Fix clang -Wimplicit-fallthrough warnings across llvm, NFC
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
2018-11-02 03:54:45 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
case Qualifiers::OCL_None:
|
|
|
|
case Qualifiers::OCL_ExplicitNone:
|
|
|
|
case Qualifiers::OCL_Autoreleasing:
|
|
|
|
CGF.Builder.CreateStore(CastExn, ParamAddr);
|
|
|
|
return;
|
|
|
|
|
|
|
|
case Qualifiers::OCL_Weak:
|
|
|
|
CGF.EmitARCInitWeak(ParamAddr, CastExn);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad ownership qualifier!");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, it returns a pointer into the exception object.
|
|
|
|
|
|
|
|
llvm::Type *PtrTy = LLVMCatchTy->getPointerTo(0); // addrspace 0 ok
|
|
|
|
llvm::Value *Cast = CGF.Builder.CreateBitCast(AdjustedExn, PtrTy);
|
|
|
|
|
|
|
|
LValue srcLV = CGF.MakeNaturalAlignAddrLValue(Cast, CatchType);
|
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
|
|
|
LValue destLV = CGF.MakeAddrLValue(ParamAddr, CatchType);
|
2015-03-04 03:21:04 +08:00
|
|
|
switch (TEK) {
|
|
|
|
case TEK_Complex:
|
|
|
|
CGF.EmitStoreOfComplex(CGF.EmitLoadOfComplex(srcLV, Loc), destLV,
|
|
|
|
/*init*/ true);
|
|
|
|
return;
|
|
|
|
case TEK_Scalar: {
|
|
|
|
llvm::Value *ExnLoad = CGF.EmitLoadOfScalar(srcLV, Loc);
|
|
|
|
CGF.EmitStoreOfScalar(ExnLoad, destLV, /*init*/ true);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
case TEK_Aggregate:
|
|
|
|
llvm_unreachable("evaluation kind filtered out!");
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad evaluation kind");
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(isa<RecordType>(CatchType) && "unexpected catch type!");
|
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
|
|
|
auto catchRD = CatchType->getAsCXXRecordDecl();
|
|
|
|
CharUnits caughtExnAlignment = CGF.CGM.getClassPointerAlignment(catchRD);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
llvm::Type *PtrTy = LLVMCatchTy->getPointerTo(0); // addrspace 0 ok
|
|
|
|
|
|
|
|
// Check for a copy expression. If we don't have a copy expression,
|
|
|
|
// that means a trivial copy is okay.
|
|
|
|
const Expr *copyExpr = CatchParam.getInit();
|
|
|
|
if (!copyExpr) {
|
|
|
|
llvm::Value *rawAdjustedExn = CallBeginCatch(CGF, Exn, true);
|
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 adjustedExn(CGF.Builder.CreateBitCast(rawAdjustedExn, PtrTy),
|
|
|
|
caughtExnAlignment);
|
2018-01-25 22:21:55 +08:00
|
|
|
LValue Dest = CGF.MakeAddrLValue(ParamAddr, CatchType);
|
|
|
|
LValue Src = CGF.MakeAddrLValue(adjustedExn, CatchType);
|
2018-04-06 04:52:58 +08:00
|
|
|
CGF.EmitAggregateCopy(Dest, Src, CatchType, AggValueSlot::DoesNotOverlap);
|
2015-03-04 03:21:04 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We have to call __cxa_get_exception_ptr to get the adjusted
|
|
|
|
// pointer before copying.
|
|
|
|
llvm::CallInst *rawAdjustedExn =
|
|
|
|
CGF.EmitNounwindRuntimeCall(getGetExceptionPtrFn(CGF.CGM), Exn);
|
|
|
|
|
|
|
|
// Cast that to the appropriate type.
|
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 adjustedExn(CGF.Builder.CreateBitCast(rawAdjustedExn, PtrTy),
|
|
|
|
caughtExnAlignment);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
// The copy expression is defined in terms of an OpaqueValueExpr.
|
|
|
|
// Find it and map it to the adjusted expression.
|
|
|
|
CodeGenFunction::OpaqueValueMapping
|
|
|
|
opaque(CGF, OpaqueValueExpr::findInCopyConstruct(copyExpr),
|
|
|
|
CGF.MakeAddrLValue(adjustedExn, CatchParam.getType()));
|
|
|
|
|
|
|
|
// Call the copy ctor in a terminate scope.
|
|
|
|
CGF.EHStack.pushTerminate();
|
|
|
|
|
|
|
|
// Perform the copy construction.
|
|
|
|
CGF.EmitAggExpr(copyExpr,
|
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
|
|
|
AggValueSlot::forAddr(ParamAddr, Qualifiers(),
|
2015-03-04 03:21:04 +08:00
|
|
|
AggValueSlot::IsNotDestructed,
|
|
|
|
AggValueSlot::DoesNotNeedGCBarriers,
|
2018-04-06 04:52:58 +08:00
|
|
|
AggValueSlot::IsNotAliased,
|
|
|
|
AggValueSlot::DoesNotOverlap));
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
// Leave the terminate scope.
|
|
|
|
CGF.EHStack.popTerminate();
|
|
|
|
|
|
|
|
// Undo the opaque value mapping.
|
|
|
|
opaque.pop();
|
|
|
|
|
|
|
|
// Finally we can call __cxa_begin_catch.
|
|
|
|
CallBeginCatch(CGF, Exn, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Begins a catch statement by initializing the catch variable and
|
|
|
|
/// calling __cxa_begin_catch.
|
|
|
|
void ItaniumCXXABI::emitBeginCatch(CodeGenFunction &CGF,
|
|
|
|
const CXXCatchStmt *S) {
|
|
|
|
// We have to be very careful with the ordering of cleanups here:
|
|
|
|
// C++ [except.throw]p4:
|
|
|
|
// The destruction [of the exception temporary] occurs
|
|
|
|
// immediately after the destruction of the object declared in
|
|
|
|
// the exception-declaration in the handler.
|
|
|
|
//
|
|
|
|
// So the precise ordering is:
|
|
|
|
// 1. Construct catch variable.
|
|
|
|
// 2. __cxa_begin_catch
|
|
|
|
// 3. Enter __cxa_end_catch cleanup
|
|
|
|
// 4. Enter dtor cleanup
|
|
|
|
//
|
|
|
|
// We do this by using a slightly abnormal initialization process.
|
|
|
|
// Delegation sequence:
|
|
|
|
// - ExitCXXTryStmt opens a RunCleanupsScope
|
|
|
|
// - EmitAutoVarAlloca creates the variable and debug info
|
|
|
|
// - InitCatchParam initializes the variable from the exception
|
|
|
|
// - CallBeginCatch calls __cxa_begin_catch
|
|
|
|
// - CallBeginCatch enters the __cxa_end_catch cleanup
|
|
|
|
// - EmitAutoVarCleanups enters the variable destructor cleanup
|
|
|
|
// - EmitCXXTryStmt emits the code for the catch body
|
|
|
|
// - EmitCXXTryStmt close the RunCleanupsScope
|
|
|
|
|
|
|
|
VarDecl *CatchParam = S->getExceptionDecl();
|
|
|
|
if (!CatchParam) {
|
|
|
|
llvm::Value *Exn = CGF.getExceptionFromSlot();
|
|
|
|
CallBeginCatch(CGF, Exn, true);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit the local.
|
|
|
|
CodeGenFunction::AutoVarEmission var = CGF.EmitAutoVarAlloca(*CatchParam);
|
2018-08-10 05:08:08 +08:00
|
|
|
InitCatchParam(CGF, *CatchParam, var.getObjectAddress(CGF), S->getBeginLoc());
|
2015-03-04 03:21:04 +08:00
|
|
|
CGF.EmitAutoVarCleanups(var);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Get or define the following function:
|
|
|
|
/// void @__clang_call_terminate(i8* %exn) nounwind noreturn
|
|
|
|
/// This code is used only in C++.
|
2019-02-06 00:42:33 +08:00
|
|
|
static llvm::FunctionCallee getClangCallTerminateFn(CodeGenModule &CGM) {
|
2015-03-04 03:21:04 +08:00
|
|
|
llvm::FunctionType *fnTy =
|
2019-07-16 12:46:31 +08:00
|
|
|
llvm::FunctionType::get(CGM.VoidTy, CGM.Int8PtrTy, /*isVarArg=*/false);
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::FunctionCallee fnRef = CGM.CreateRuntimeFunction(
|
2019-07-16 12:46:31 +08:00
|
|
|
fnTy, "__clang_call_terminate", llvm::AttributeList(), /*Local=*/true);
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::Function *fn =
|
|
|
|
cast<llvm::Function>(fnRef.getCallee()->stripPointerCasts());
|
|
|
|
if (fn->empty()) {
|
2015-03-04 03:21:04 +08:00
|
|
|
fn->setDoesNotThrow();
|
|
|
|
fn->setDoesNotReturn();
|
|
|
|
|
|
|
|
// What we really want is to massively penalize inlining without
|
|
|
|
// forbidding it completely. The difference between that and
|
|
|
|
// 'noinline' is negligible.
|
|
|
|
fn->addFnAttr(llvm::Attribute::NoInline);
|
|
|
|
|
|
|
|
// Allow this function to be shared across translation units, but
|
|
|
|
// we don't want it to turn into an exported symbol.
|
|
|
|
fn->setLinkage(llvm::Function::LinkOnceODRLinkage);
|
|
|
|
fn->setVisibility(llvm::Function::HiddenVisibility);
|
2015-05-10 05:10:07 +08:00
|
|
|
if (CGM.supportsCOMDAT())
|
|
|
|
fn->setComdat(CGM.getModule().getOrInsertComdat(fn->getName()));
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
// Set up the function.
|
|
|
|
llvm::BasicBlock *entry =
|
2019-02-06 00:42:33 +08:00
|
|
|
llvm::BasicBlock::Create(CGM.getLLVMContext(), "", fn);
|
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
|
|
|
CGBuilderTy builder(CGM, entry);
|
2015-03-04 03:21:04 +08:00
|
|
|
|
|
|
|
// Pull the exception pointer out of the parameter list.
|
|
|
|
llvm::Value *exn = &*fn->arg_begin();
|
|
|
|
|
|
|
|
// Call __cxa_begin_catch(exn).
|
|
|
|
llvm::CallInst *catchCall = builder.CreateCall(getBeginCatchFn(CGM), exn);
|
|
|
|
catchCall->setDoesNotThrow();
|
|
|
|
catchCall->setCallingConv(CGM.getRuntimeCC());
|
|
|
|
|
|
|
|
// Call std::terminate().
|
2015-07-15 01:27:39 +08:00
|
|
|
llvm::CallInst *termCall = builder.CreateCall(CGM.getTerminateFn());
|
2015-03-04 03:21:04 +08:00
|
|
|
termCall->setDoesNotThrow();
|
|
|
|
termCall->setDoesNotReturn();
|
|
|
|
termCall->setCallingConv(CGM.getRuntimeCC());
|
|
|
|
|
|
|
|
// std::terminate cannot return.
|
|
|
|
builder.CreateUnreachable();
|
|
|
|
}
|
|
|
|
return fnRef;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::CallInst *
|
|
|
|
ItaniumCXXABI::emitTerminateForUnexpectedException(CodeGenFunction &CGF,
|
|
|
|
llvm::Value *Exn) {
|
|
|
|
// In C++, we want to call __cxa_begin_catch() before terminating.
|
|
|
|
if (Exn) {
|
|
|
|
assert(CGF.CGM.getLangOpts().CPlusPlus);
|
|
|
|
return CGF.EmitNounwindRuntimeCall(getClangCallTerminateFn(CGF.CGM), Exn);
|
|
|
|
}
|
|
|
|
return CGF.EmitNounwindRuntimeCall(CGF.CGM.getTerminateFn());
|
|
|
|
}
|
2017-12-14 05:53:04 +08:00
|
|
|
|
|
|
|
std::pair<llvm::Value *, const CXXRecordDecl *>
|
|
|
|
ItaniumCXXABI::LoadVTablePtr(CodeGenFunction &CGF, Address This,
|
|
|
|
const CXXRecordDecl *RD) {
|
|
|
|
return {CGF.GetVTablePtr(This, CGM.Int8PtrTy, RD), RD};
|
|
|
|
}
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
|
|
|
|
void WebAssemblyCXXABI::emitBeginCatch(CodeGenFunction &CGF,
|
|
|
|
const CXXCatchStmt *C) {
|
2018-06-01 09:01:37 +08:00
|
|
|
if (CGF.getTarget().hasFeature("exception-handling"))
|
|
|
|
CGF.EHStack.pushCleanup<CatchRetScope>(
|
|
|
|
NormalCleanup, cast<llvm::CatchPadInst>(CGF.CurrentFuncletPad));
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
ItaniumCXXABI::emitBeginCatch(CGF, C);
|
|
|
|
}
|