2008-07-30 07:18:29 +08:00
|
|
|
//===-- CodeGenFunction.h - Per-Function state for LLVM CodeGen -*- C++ -*-===//
|
2007-05-24 14:29:05 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 03:59:25 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-05-24 14:29:05 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2009-02-09 07:14:22 +08:00
|
|
|
// This is the internal per-function state used for llvm translation.
|
2007-05-24 14:29:05 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:25:19 +08:00
|
|
|
#ifndef LLVM_CLANG_LIB_CODEGEN_CODEGENFUNCTION_H
|
|
|
|
#define LLVM_CLANG_LIB_CODEGEN_CODEGENFUNCTION_H
|
2007-05-24 14:29:05 +08:00
|
|
|
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "CGBuilder.h"
|
|
|
|
#include "CGDebugInfo.h"
|
2014-05-22 16:54:05 +08:00
|
|
|
#include "CGLoopInfo.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "CGValue.h"
|
|
|
|
#include "CodeGenModule.h"
|
2014-01-07 06:27:43 +08:00
|
|
|
#include "CodeGenPGO.h"
|
2014-01-07 19:51:46 +08:00
|
|
|
#include "EHScopeStack.h"
|
2016-10-26 13:42:30 +08:00
|
|
|
#include "VarBypassDetector.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/AST/CharUnits.h"
|
2008-09-10 10:36:38 +08:00
|
|
|
#include "clang/AST/ExprCXX.h"
|
This patch is motivated by numerous strict-aliasing warnings when compiling
clang as a Release build.
The big change is that all AST nodes (subclasses of Stmt) whose children are
Expr* store their children as Stmt* or arrays of Stmt*. This is to remove
strict-aliasing warnings when using StmtIterator. None of the interfaces of any
of the classes have changed (except those with arg_iterators, see below), as the
accessor methods introduce the needed casts (via cast<>). While this extra
casting may seem cumbersome, it actually adds some important sanity checks
throughout the codebase, as clients using StmtIterator can potentially overwrite
children that are expected to be Expr* with Stmt* (that aren't Expr*). The casts
provide extra sanity checks that are operational in debug builds to catch
invariant violations such as these.
For classes that have arg_iterators (e.g., CallExpr), the definition of
arg_iterator has been replaced. Instead of it being Expr**, it is an actual
class (called ExprIterator) that wraps a Stmt**, and provides the necessary
operators for iteration. The nice thing about this class is that it also uses
cast<> to type-checking, which introduces extra sanity checks throughout the
codebase that are useful for debugging.
A few of the CodeGen functions that use arg_iterator (especially from
OverloadExpr) have been modified to take begin and end iterators instead of a
base Expr** and the number of arguments. This matches more with the abstraction
of iteration. This still needs to be cleaned up a little bit, as clients expect
that ExprIterator is a RandomAccessIterator (which we may or may not wish to
allow for efficiency of representation).
This is a fairly large patch. It passes the tests (except CodeGen/bitfield.c,
which was already broken) on both a Debug and Release build, but it should
obviously be reviewed.
llvm-svn: 52378
2008-06-17 10:43:46 +08:00
|
|
|
#include "clang/AST/ExprObjC.h"
|
2015-08-31 15:32:19 +08:00
|
|
|
#include "clang/AST/ExprOpenMP.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/AST/Type.h"
|
2011-01-14 02:57:25 +08:00
|
|
|
#include "clang/Basic/ABI.h"
|
2013-05-10 03:17:11 +08:00
|
|
|
#include "clang/Basic/CapturedStmt.h"
|
2015-01-22 16:49:35 +08:00
|
|
|
#include "clang/Basic/OpenMPKinds.h"
|
2009-04-01 06:17:44 +08:00
|
|
|
#include "clang/Basic/TargetInfo.h"
|
2016-04-09 00:52:00 +08:00
|
|
|
#include "clang/Frontend/CodeGenOptions.h"
|
2011-07-15 16:37:34 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2009-04-01 06:17:44 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2014-03-04 19:18:19 +08:00
|
|
|
#include "llvm/IR/ValueHandle.h"
|
2011-10-19 08:43:52 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2016-01-16 08:31:22 +08:00
|
|
|
#include "llvm/Transforms/Utils/SanitizerStats.h"
|
2008-08-23 11:46:30 +08:00
|
|
|
|
2007-05-24 14:29:05 +08:00
|
|
|
namespace llvm {
|
2014-05-09 08:57:59 +08:00
|
|
|
class BasicBlock;
|
|
|
|
class LLVMContext;
|
|
|
|
class MDNode;
|
|
|
|
class Module;
|
|
|
|
class SwitchInst;
|
|
|
|
class Twine;
|
|
|
|
class Value;
|
|
|
|
class CallSite;
|
2007-06-16 07:05:46 +08:00
|
|
|
}
|
|
|
|
|
2007-05-24 14:29:05 +08:00
|
|
|
namespace clang {
|
2014-05-09 08:57:59 +08:00
|
|
|
class ASTContext;
|
|
|
|
class BlockDecl;
|
|
|
|
class CXXDestructorDecl;
|
|
|
|
class CXXForRangeStmt;
|
|
|
|
class CXXTryStmt;
|
|
|
|
class Decl;
|
|
|
|
class LabelDecl;
|
|
|
|
class EnumConstantDecl;
|
|
|
|
class FunctionDecl;
|
|
|
|
class FunctionProtoType;
|
|
|
|
class LabelStmt;
|
|
|
|
class ObjCContainerDecl;
|
|
|
|
class ObjCInterfaceDecl;
|
|
|
|
class ObjCIvarDecl;
|
|
|
|
class ObjCMethodDecl;
|
|
|
|
class ObjCImplementationDecl;
|
|
|
|
class ObjCPropertyImplDecl;
|
|
|
|
class TargetInfo;
|
|
|
|
class VarDecl;
|
|
|
|
class ObjCForCollectionStmt;
|
|
|
|
class ObjCAtTryStmt;
|
|
|
|
class ObjCAtThrowStmt;
|
|
|
|
class ObjCAtSynchronizedStmt;
|
|
|
|
class ObjCAutoreleasePoolStmt;
|
This patch is motivated by numerous strict-aliasing warnings when compiling
clang as a Release build.
The big change is that all AST nodes (subclasses of Stmt) whose children are
Expr* store their children as Stmt* or arrays of Stmt*. This is to remove
strict-aliasing warnings when using StmtIterator. None of the interfaces of any
of the classes have changed (except those with arg_iterators, see below), as the
accessor methods introduce the needed casts (via cast<>). While this extra
casting may seem cumbersome, it actually adds some important sanity checks
throughout the codebase, as clients using StmtIterator can potentially overwrite
children that are expected to be Expr* with Stmt* (that aren't Expr*). The casts
provide extra sanity checks that are operational in debug builds to catch
invariant violations such as these.
For classes that have arg_iterators (e.g., CallExpr), the definition of
arg_iterator has been replaced. Instead of it being Expr**, it is an actual
class (called ExprIterator) that wraps a Stmt**, and provides the necessary
operators for iteration. The nice thing about this class is that it also uses
cast<> to type-checking, which introduces extra sanity checks throughout the
codebase that are useful for debugging.
A few of the CodeGen functions that use arg_iterator (especially from
OverloadExpr) have been modified to take begin and end iterators instead of a
base Expr** and the number of arguments. This matches more with the abstraction
of iteration. This still needs to be cleaned up a little bit, as clients expect
that ExprIterator is a RandomAccessIterator (which we may or may not wish to
allow for efficiency of representation).
This is a fairly large patch. It passes the tests (except CodeGen/bitfield.c,
which was already broken) on both a Debug and Release build, but it should
obviously be reviewed.
llvm-svn: 52378
2008-06-17 10:43:46 +08:00
|
|
|
|
2007-05-24 14:29:05 +08:00
|
|
|
namespace CodeGen {
|
2014-05-09 08:57:59 +08:00
|
|
|
class CodeGenTypes;
|
2016-10-27 07:46:34 +08:00
|
|
|
class CGCallee;
|
2014-05-09 08:57:59 +08:00
|
|
|
class CGFunctionInfo;
|
|
|
|
class CGRecordLayout;
|
|
|
|
class CGBlockInfo;
|
|
|
|
class CGCXXABI;
|
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
|
|
|
class BlockByrefHelpers;
|
|
|
|
class BlockByrefInfo;
|
2014-05-09 08:57:59 +08:00
|
|
|
class BlockFlags;
|
|
|
|
class BlockFieldFlags;
|
[OPENMP 4.5] Codegen for 'taskloop' directive.
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
2016-04-25 20:22:29 +08:00
|
|
|
class RegionCodeGenTy;
|
2016-04-05 02:33:08 +08:00
|
|
|
class TargetCodeGenInfo;
|
2016-04-28 17:23:51 +08:00
|
|
|
struct OMPTaskDataTy;
|
2016-10-04 06:44:48 +08:00
|
|
|
struct CGCoroData;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
/// The kind of evaluation to perform on values of a particular
|
|
|
|
/// type. Basically, is the code in CGExprScalar, CGExprComplex, or
|
|
|
|
/// CGExprAgg?
|
|
|
|
///
|
|
|
|
/// TODO: should vectors maybe be split out into their own thing?
|
|
|
|
enum TypeEvaluationKind {
|
|
|
|
TEK_Scalar,
|
|
|
|
TEK_Complex,
|
|
|
|
TEK_Aggregate
|
|
|
|
};
|
|
|
|
|
2016-12-13 00:18:40 +08:00
|
|
|
#define LIST_SANITIZER_CHECKS \
|
|
|
|
SANITIZER_CHECK(AddOverflow, add_overflow, 0) \
|
|
|
|
SANITIZER_CHECK(BuiltinUnreachable, builtin_unreachable, 0) \
|
|
|
|
SANITIZER_CHECK(CFICheckFail, cfi_check_fail, 0) \
|
|
|
|
SANITIZER_CHECK(DivremOverflow, divrem_overflow, 0) \
|
|
|
|
SANITIZER_CHECK(DynamicTypeCacheMiss, dynamic_type_cache_miss, 0) \
|
|
|
|
SANITIZER_CHECK(FloatCastOverflow, float_cast_overflow, 0) \
|
|
|
|
SANITIZER_CHECK(FunctionTypeMismatch, function_type_mismatch, 0) \
|
2017-07-29 08:19:51 +08:00
|
|
|
SANITIZER_CHECK(InvalidBuiltin, invalid_builtin, 0) \
|
2016-12-13 00:18:40 +08:00
|
|
|
SANITIZER_CHECK(LoadInvalidValue, load_invalid_value, 0) \
|
|
|
|
SANITIZER_CHECK(MissingReturn, missing_return, 0) \
|
|
|
|
SANITIZER_CHECK(MulOverflow, mul_overflow, 0) \
|
|
|
|
SANITIZER_CHECK(NegateOverflow, negate_overflow, 0) \
|
2017-03-15 00:48:29 +08:00
|
|
|
SANITIZER_CHECK(NullabilityArg, nullability_arg, 0) \
|
2017-06-24 05:32:38 +08:00
|
|
|
SANITIZER_CHECK(NullabilityReturn, nullability_return, 1) \
|
2016-12-13 00:18:40 +08:00
|
|
|
SANITIZER_CHECK(NonnullArg, nonnull_arg, 0) \
|
2017-06-24 05:32:38 +08:00
|
|
|
SANITIZER_CHECK(NonnullReturn, nonnull_return, 1) \
|
2016-12-13 00:18:40 +08:00
|
|
|
SANITIZER_CHECK(OutOfBounds, out_of_bounds, 0) \
|
2017-06-02 03:22:18 +08:00
|
|
|
SANITIZER_CHECK(PointerOverflow, pointer_overflow, 0) \
|
2016-12-13 00:18:40 +08:00
|
|
|
SANITIZER_CHECK(ShiftOutOfBounds, shift_out_of_bounds, 0) \
|
|
|
|
SANITIZER_CHECK(SubOverflow, sub_overflow, 0) \
|
2017-01-06 22:40:12 +08:00
|
|
|
SANITIZER_CHECK(TypeMismatch, type_mismatch, 1) \
|
2016-12-13 00:18:40 +08:00
|
|
|
SANITIZER_CHECK(VLABoundNotPositive, vla_bound_not_positive, 0)
|
|
|
|
|
|
|
|
enum SanitizerHandler {
|
|
|
|
#define SANITIZER_CHECK(Enum, Name, Version) Enum,
|
|
|
|
LIST_SANITIZER_CHECKS
|
|
|
|
#undef SANITIZER_CHECK
|
|
|
|
};
|
|
|
|
|
2007-05-28 09:07:47 +08:00
|
|
|
/// CodeGenFunction - This class organizes the per-function state that is used
|
|
|
|
/// while generating LLVM code.
|
2011-02-15 17:22:45 +08:00
|
|
|
class CodeGenFunction : public CodeGenTypeCache {
|
2015-02-16 06:54:08 +08:00
|
|
|
CodeGenFunction(const CodeGenFunction &) = delete;
|
|
|
|
void operator=(const CodeGenFunction &) = delete;
|
2010-08-31 15:33:07 +08:00
|
|
|
|
|
|
|
friend class CGCXXABI;
|
2007-08-27 07:13:56 +08:00
|
|
|
public:
|
2010-07-24 05:56:41 +08:00
|
|
|
/// A jump destination is an abstract label, branching to which may
|
|
|
|
/// require a jump out through normal cleanups.
|
2010-07-06 09:34:17 +08:00
|
|
|
struct JumpDest {
|
2014-05-21 13:09:00 +08:00
|
|
|
JumpDest() : Block(nullptr), ScopeDepth(), Index(0) {}
|
2010-07-24 05:56:41 +08:00
|
|
|
JumpDest(llvm::BasicBlock *Block,
|
|
|
|
EHScopeStack::stable_iterator Depth,
|
|
|
|
unsigned Index)
|
|
|
|
: Block(Block), ScopeDepth(Depth), Index(Index) {}
|
|
|
|
|
2014-05-21 13:09:00 +08:00
|
|
|
bool isValid() const { return Block != nullptr; }
|
2010-07-24 05:56:41 +08:00
|
|
|
llvm::BasicBlock *getBlock() const { return Block; }
|
|
|
|
EHScopeStack::stable_iterator getScopeDepth() const { return ScopeDepth; }
|
|
|
|
unsigned getDestIndex() const { return Index; }
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
// This should be used cautiously.
|
|
|
|
void setScopeDepth(EHScopeStack::stable_iterator depth) {
|
|
|
|
ScopeDepth = depth;
|
|
|
|
}
|
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
private:
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::BasicBlock *Block;
|
|
|
|
EHScopeStack::stable_iterator ScopeDepth;
|
2010-07-24 05:56:41 +08:00
|
|
|
unsigned Index;
|
|
|
|
};
|
|
|
|
|
2007-05-28 09:07:47 +08:00
|
|
|
CodeGenModule &CGM; // Per-module state.
|
2009-11-13 13:51:54 +08:00
|
|
|
const TargetInfo &Target;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2007-08-22 00:57:55 +08:00
|
|
|
typedef std::pair<llvm::Value *, llvm::Value *> ComplexPairTy;
|
2014-05-22 16:54:05 +08:00
|
|
|
LoopInfoStack LoopStack;
|
2008-11-01 09:53:16 +08:00
|
|
|
CGBuilderTy Builder;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2016-10-26 13:42:30 +08:00
|
|
|
// Stores variables for which we can't generate correct lifetime markers
|
|
|
|
// because of jumps.
|
|
|
|
VarBypassDetector Bypasses;
|
|
|
|
|
2017-04-26 01:52:12 +08:00
|
|
|
// CodeGen lambda for loops and support for ordered clause
|
|
|
|
typedef llvm::function_ref<void(CodeGenFunction &, const OMPLoopDirective &,
|
|
|
|
JumpDest)>
|
|
|
|
CodeGenLoopTy;
|
|
|
|
typedef llvm::function_ref<void(CodeGenFunction &, SourceLocation,
|
|
|
|
const unsigned, const bool)>
|
|
|
|
CodeGenOrderedTy;
|
|
|
|
|
|
|
|
// Codegen lambda for loop bounds in worksharing loop constructs
|
|
|
|
typedef llvm::function_ref<std::pair<LValue, LValue>(
|
|
|
|
CodeGenFunction &, const OMPExecutableDirective &S)>
|
|
|
|
CodeGenLoopBoundsTy;
|
|
|
|
|
|
|
|
// Codegen lambda for loop bounds in dispatch-based loop implementation
|
|
|
|
typedef llvm::function_ref<std::pair<llvm::Value *, llvm::Value *>(
|
|
|
|
CodeGenFunction &, const OMPExecutableDirective &S, Address LB,
|
|
|
|
Address UB)>
|
|
|
|
CodeGenDispatchBoundsTy;
|
|
|
|
|
2014-05-22 16:54:05 +08:00
|
|
|
/// \brief CGBuilder insert helper. This function is called after an
|
|
|
|
/// instruction is created using Builder.
|
|
|
|
void InsertHelper(llvm::Instruction *I, const llvm::Twine &Name,
|
|
|
|
llvm::BasicBlock *BB,
|
|
|
|
llvm::BasicBlock::iterator InsertPt) const;
|
|
|
|
|
2013-05-03 15:33:41 +08:00
|
|
|
/// CurFuncDecl - Holds the Decl for the current outermost
|
|
|
|
/// non-closure context.
|
2008-06-18 02:05:57 +08:00
|
|
|
const Decl *CurFuncDecl;
|
2009-04-23 13:30:27 +08:00
|
|
|
/// CurCodeDecl - This is the inner-most code context, which includes blocks.
|
|
|
|
const Decl *CurCodeDecl;
|
2009-02-03 06:03:45 +08:00
|
|
|
const CGFunctionInfo *CurFnInfo;
|
2008-03-31 07:03:07 +08:00
|
|
|
QualType FnRetTy;
|
2007-05-30 08:13:02 +08:00
|
|
|
llvm::Function *CurFn;
|
|
|
|
|
2016-10-04 06:44:48 +08:00
|
|
|
// Holds coroutine data if the current function is a coroutine. We use a
|
|
|
|
// wrapper to manage its lifetime, so that we don't have to define CGCoroData
|
|
|
|
// in this header.
|
|
|
|
struct CGCoroInfo {
|
|
|
|
std::unique_ptr<CGCoroData> Data;
|
|
|
|
CGCoroInfo();
|
|
|
|
~CGCoroInfo();
|
|
|
|
};
|
|
|
|
CGCoroInfo CurCoro;
|
|
|
|
|
2009-12-05 07:26:17 +08:00
|
|
|
/// CurGD - The GlobalDecl for the current function being compiled.
|
|
|
|
GlobalDecl CurGD;
|
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
/// PrologueCleanupDepth - The cleanup depth enclosing all the
|
|
|
|
/// cleanups associated with the parameters.
|
|
|
|
EHScopeStack::stable_iterator PrologueCleanupDepth;
|
|
|
|
|
2008-09-10 05:00:17 +08:00
|
|
|
/// ReturnBlock - Unified return block.
|
2010-07-06 09:34:17 +08:00
|
|
|
JumpDest ReturnBlock;
|
|
|
|
|
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
|
|
|
/// ReturnValue - The temporary alloca to hold the return
|
|
|
|
/// value. This is invalid iff the function has no return value.
|
|
|
|
Address ReturnValue;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2017-01-26 06:55:13 +08:00
|
|
|
/// Return true if a label was seen in the current scope.
|
|
|
|
bool hasLabelBeenSeenInCurrentScope() const {
|
|
|
|
if (CurLexicalScope)
|
|
|
|
return CurLexicalScope->hasLabels();
|
|
|
|
return !LabelMap.empty();
|
|
|
|
}
|
|
|
|
|
2007-06-02 12:53:11 +08:00
|
|
|
/// AllocaInsertPoint - This is an instruction in the entry block before which
|
|
|
|
/// we prefer to insert allocas.
|
2009-04-01 06:17:44 +08:00
|
|
|
llvm::AssertingVH<llvm::Instruction> AllocaInsertPt;
|
2008-08-05 00:51:22 +08:00
|
|
|
|
2013-05-10 03:17:11 +08:00
|
|
|
/// \brief API for captured statement code generation.
|
|
|
|
class CGCapturedStmtInfo {
|
|
|
|
public:
|
2014-12-16 15:00:22 +08:00
|
|
|
explicit CGCapturedStmtInfo(CapturedRegionKind K = CR_Default)
|
|
|
|
: Kind(K), ThisValue(nullptr), CXXThisFieldDecl(nullptr) {}
|
2013-05-10 03:17:11 +08:00
|
|
|
explicit CGCapturedStmtInfo(const CapturedStmt &S,
|
|
|
|
CapturedRegionKind K = CR_Default)
|
2014-05-21 13:09:00 +08:00
|
|
|
: Kind(K), ThisValue(nullptr), CXXThisFieldDecl(nullptr) {
|
2013-05-10 03:17:11 +08:00
|
|
|
|
|
|
|
RecordDecl::field_iterator Field =
|
|
|
|
S.getCapturedRecordDecl()->field_begin();
|
|
|
|
for (CapturedStmt::const_capture_iterator I = S.capture_begin(),
|
|
|
|
E = S.capture_end();
|
|
|
|
I != E; ++I, ++Field) {
|
|
|
|
if (I->capturesThis())
|
|
|
|
CXXThisFieldDecl = *Field;
|
2014-10-29 20:21:55 +08:00
|
|
|
else if (I->capturesVariable())
|
2017-09-23 00:56:13 +08:00
|
|
|
CaptureFields[I->getCapturedVar()->getCanonicalDecl()] = *Field;
|
2016-05-17 16:55:33 +08:00
|
|
|
else if (I->capturesVariableByCopy())
|
2017-09-23 00:56:13 +08:00
|
|
|
CaptureFields[I->getCapturedVar()->getCanonicalDecl()] = *Field;
|
2013-05-10 03:17:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual ~CGCapturedStmtInfo();
|
|
|
|
|
|
|
|
CapturedRegionKind getKind() const { return Kind; }
|
|
|
|
|
2015-04-10 12:50:10 +08:00
|
|
|
virtual void setContextValue(llvm::Value *V) { ThisValue = V; }
|
2013-05-10 03:17:11 +08:00
|
|
|
// \brief Retrieve the value of the context parameter.
|
2015-02-26 18:27:34 +08:00
|
|
|
virtual llvm::Value *getContextValue() const { return ThisValue; }
|
2013-05-10 03:17:11 +08:00
|
|
|
|
|
|
|
/// \brief Lookup the captured field decl for a variable.
|
2015-02-26 18:27:34 +08:00
|
|
|
virtual const FieldDecl *lookup(const VarDecl *VD) const {
|
2017-09-23 00:56:13 +08:00
|
|
|
return CaptureFields.lookup(VD->getCanonicalDecl());
|
2013-05-10 03:17:11 +08:00
|
|
|
}
|
|
|
|
|
2015-02-26 18:27:34 +08:00
|
|
|
bool isCXXThisExprCaptured() const { return getThisFieldDecl() != nullptr; }
|
|
|
|
virtual FieldDecl *getThisFieldDecl() const { return CXXThisFieldDecl; }
|
2013-05-10 03:17:11 +08:00
|
|
|
|
2014-10-10 20:19:54 +08:00
|
|
|
static bool classof(const CGCapturedStmtInfo *) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-05-10 03:17:11 +08:00
|
|
|
/// \brief Emit the captured statement body.
|
2015-02-26 18:27:34 +08:00
|
|
|
virtual void EmitBody(CodeGenFunction &CGF, const Stmt *S) {
|
2015-04-24 07:06:47 +08:00
|
|
|
CGF.incrementProfileCounter(S);
|
2013-05-10 03:17:11 +08:00
|
|
|
CGF.EmitStmt(S);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Get the name of the capture helper.
|
|
|
|
virtual StringRef getHelperName() const { return "__captured_stmt"; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
/// \brief The kind of captured statement being generated.
|
|
|
|
CapturedRegionKind Kind;
|
|
|
|
|
|
|
|
/// \brief Keep the map between VarDecl and FieldDecl.
|
|
|
|
llvm::SmallDenseMap<const VarDecl *, FieldDecl *> CaptureFields;
|
|
|
|
|
|
|
|
/// \brief The base address of the captured record, passed in as the first
|
|
|
|
/// argument of the parallel region function.
|
|
|
|
llvm::Value *ThisValue;
|
|
|
|
|
|
|
|
/// \brief Captured 'this' type.
|
|
|
|
FieldDecl *CXXThisFieldDecl;
|
|
|
|
};
|
|
|
|
CGCapturedStmtInfo *CapturedStmtInfo;
|
|
|
|
|
2015-06-24 11:35:38 +08:00
|
|
|
/// \brief RAII for correct setting/restoring of CapturedStmtInfo.
|
|
|
|
class CGCapturedStmtRAII {
|
|
|
|
private:
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
CGCapturedStmtInfo *PrevCapturedStmtInfo;
|
|
|
|
public:
|
|
|
|
CGCapturedStmtRAII(CodeGenFunction &CGF,
|
|
|
|
CGCapturedStmtInfo *NewCapturedStmtInfo)
|
|
|
|
: CGF(CGF), PrevCapturedStmtInfo(CGF.CapturedStmtInfo) {
|
|
|
|
CGF.CapturedStmtInfo = NewCapturedStmtInfo;
|
|
|
|
}
|
|
|
|
~CGCapturedStmtRAII() { CGF.CapturedStmtInfo = PrevCapturedStmtInfo; }
|
|
|
|
};
|
|
|
|
|
2017-03-06 13:28:22 +08:00
|
|
|
/// An abstract representation of regular/ObjC call/message targets.
|
|
|
|
class AbstractCallee {
|
|
|
|
/// The function declaration of the callee.
|
|
|
|
const Decl *CalleeDecl;
|
|
|
|
|
|
|
|
public:
|
|
|
|
AbstractCallee() : CalleeDecl(nullptr) {}
|
|
|
|
AbstractCallee(const FunctionDecl *FD) : CalleeDecl(FD) {}
|
|
|
|
AbstractCallee(const ObjCMethodDecl *OMD) : CalleeDecl(OMD) {}
|
|
|
|
bool hasFunctionDecl() const {
|
|
|
|
return dyn_cast_or_null<FunctionDecl>(CalleeDecl);
|
|
|
|
}
|
|
|
|
const Decl *getDecl() const { return CalleeDecl; }
|
|
|
|
unsigned getNumParams() const {
|
|
|
|
if (const auto *FD = dyn_cast<FunctionDecl>(CalleeDecl))
|
|
|
|
return FD->getNumParams();
|
|
|
|
return cast<ObjCMethodDecl>(CalleeDecl)->param_size();
|
|
|
|
}
|
|
|
|
const ParmVarDecl *getParamDecl(unsigned I) const {
|
|
|
|
if (const auto *FD = dyn_cast<FunctionDecl>(CalleeDecl))
|
|
|
|
return FD->getParamDecl(I);
|
|
|
|
return *(cast<ObjCMethodDecl>(CalleeDecl)->param_begin() + I);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-11-11 09:26:14 +08:00
|
|
|
/// \brief Sanitizers enabled for this function.
|
|
|
|
SanitizerSet SanOpts;
|
2013-01-18 19:30:38 +08:00
|
|
|
|
2014-07-18 02:46:27 +08:00
|
|
|
/// \brief True if CodeGen currently emits code implementing sanitizer checks.
|
|
|
|
bool IsSanitizerScope;
|
|
|
|
|
|
|
|
/// \brief RAII object to set/unset CodeGenFunction::IsSanitizerScope.
|
|
|
|
class SanitizerScope {
|
|
|
|
CodeGenFunction *CGF;
|
|
|
|
public:
|
|
|
|
SanitizerScope(CodeGenFunction *CGF);
|
|
|
|
~SanitizerScope();
|
|
|
|
};
|
|
|
|
|
2014-07-26 05:39:46 +08:00
|
|
|
/// In C++, whether we are code generating a thunk. This controls whether we
|
|
|
|
/// should emit cleanups.
|
|
|
|
bool CurFuncIsThunk;
|
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
/// In ARC, whether we should autorelease the return value.
|
|
|
|
bool AutoreleaseResult;
|
|
|
|
|
2014-09-05 04:04:38 +08:00
|
|
|
/// Whether we processed a Microsoft-style asm block during CodeGen. These can
|
|
|
|
/// potentially set the return value.
|
|
|
|
bool SawAsmBlock;
|
|
|
|
|
2016-03-02 03:42:53 +08:00
|
|
|
const FunctionDecl *CurSEHParent = nullptr;
|
|
|
|
|
2015-04-15 04:59:00 +08:00
|
|
|
/// True if the current function is an outlined SEH helper. This can be a
|
|
|
|
/// finally block or filter expression.
|
|
|
|
bool IsOutlinedSEHHelper;
|
|
|
|
|
2011-02-08 16:22:06 +08:00
|
|
|
const CodeGen::CGBlockInfo *BlockInfo;
|
|
|
|
llvm::Value *BlockPointer;
|
|
|
|
|
2012-02-11 10:57:39 +08:00
|
|
|
llvm::DenseMap<const VarDecl *, FieldDecl *> LambdaCaptureFields;
|
|
|
|
FieldDecl *LambdaThisCaptureField;
|
|
|
|
|
2010-05-17 23:52:46 +08:00
|
|
|
/// \brief A mapping from NRVO variables to the flags used to indicate
|
|
|
|
/// when the NRVO has been applied to this variable.
|
|
|
|
llvm::DenseMap<const VarDecl *, llvm::Value *> NRVOFlags;
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
EHScopeStack EHStack;
|
2013-06-13 04:42:33 +08:00
|
|
|
llvm::SmallVector<char, 256> LifetimeExtendedCleanupStack;
|
2015-02-13 07:16:11 +08:00
|
|
|
llvm::SmallVector<const JumpDest *, 2> SEHTryEpilogueStack;
|
2013-06-13 04:42:33 +08:00
|
|
|
|
2015-12-12 13:39:21 +08:00
|
|
|
llvm::Instruction *CurrentFuncletPad = nullptr;
|
|
|
|
|
2016-07-02 05:08:47 +08:00
|
|
|
class CallLifetimeEnd final : public EHScopeStack::Cleanup {
|
|
|
|
llvm::Value *Addr;
|
|
|
|
llvm::Value *Size;
|
|
|
|
|
|
|
|
public:
|
|
|
|
CallLifetimeEnd(Address addr, llvm::Value *size)
|
|
|
|
: Addr(addr.getPointer()), Size(size) {}
|
|
|
|
|
|
|
|
void Emit(CodeGenFunction &CGF, Flags flags) override {
|
|
|
|
CGF.EmitLifetimeEnd(Size, Addr);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-06-13 04:42:33 +08:00
|
|
|
/// Header for data within LifetimeExtendedCleanupStack.
|
|
|
|
struct LifetimeExtendedCleanupHeader {
|
|
|
|
/// The size of the following cleanup object.
|
2015-07-01 08:59:27 +08:00
|
|
|
unsigned Size;
|
2013-06-13 04:42:33 +08:00
|
|
|
/// The kind of cleanup to push: a value from the CleanupKind enumeration.
|
2015-07-01 08:59:27 +08:00
|
|
|
CleanupKind Kind;
|
2013-06-13 04:42:33 +08:00
|
|
|
|
2015-07-01 08:59:27 +08:00
|
|
|
size_t getSize() const { return Size; }
|
|
|
|
CleanupKind getKind() const { return Kind; }
|
2013-06-13 04:42:33 +08:00
|
|
|
};
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
/// i32s containing the indexes of the cleanup destinations.
|
|
|
|
llvm::AllocaInst *NormalCleanupDest;
|
|
|
|
|
|
|
|
unsigned NextCleanupDestIndex;
|
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
/// FirstBlockInfo - The head of a singly-linked-list of block layouts.
|
|
|
|
CGBlockInfo *FirstBlockInfo;
|
|
|
|
|
2011-08-11 10:22:43 +08:00
|
|
|
/// EHResumeBlock - Unified block containing a call to llvm.eh.resume.
|
|
|
|
llvm::BasicBlock *EHResumeBlock;
|
|
|
|
|
2011-09-20 04:31:14 +08:00
|
|
|
/// The exception slot. All landing pads write the current exception pointer
|
|
|
|
/// into this alloca.
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::Value *ExceptionSlot;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-09-20 04:31:14 +08:00
|
|
|
/// The selector slot. Under the MandatoryCleanup model, all landing pads
|
|
|
|
/// write the current selector value into this alloca.
|
2011-05-29 05:13:02 +08:00
|
|
|
llvm::AllocaInst *EHSelectorSlot;
|
|
|
|
|
2015-07-07 08:36:30 +08:00
|
|
|
/// A stack of exception code slots. Entering an __except block pushes a slot
|
|
|
|
/// on the stack and leaving pops one. The __exception_code() intrinsic loads
|
|
|
|
/// a value from the top of the stack.
|
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
|
|
|
SmallVector<Address, 1> SEHCodeSlotStack;
|
2015-07-02 01:10:10 +08:00
|
|
|
|
2015-07-07 08:36:30 +08:00
|
|
|
/// Value returned by __exception_info intrinsic.
|
|
|
|
llvm::Value *SEHInfo = nullptr;
|
Initial support for Win64 SEH IR emission
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
2015-01-22 09:36:17 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// Emits a landing pad for the current EH stack.
|
|
|
|
llvm::BasicBlock *EmitLandingPad();
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::BasicBlock *getInvokeDestImpl();
|
2009-12-02 15:41:41 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
template <class T>
|
2011-01-28 18:53:53 +08:00
|
|
|
typename DominatingValue<T>::saved_type saveValueInCond(T value) {
|
|
|
|
return DominatingValue<T>::save(*this, value);
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
public:
|
|
|
|
/// ObjCEHValueStack - Stack of Objective-C exception values, used for
|
|
|
|
/// rethrows.
|
2011-07-20 14:58:45 +08:00
|
|
|
SmallVector<llvm::Value*, 8> ObjCEHValueStack;
|
2009-02-08 15:46:24 +08:00
|
|
|
|
2011-06-22 10:32:12 +08:00
|
|
|
/// A class controlling the emission of a finally block.
|
|
|
|
class FinallyInfo {
|
|
|
|
/// Where the catchall's edge through the cleanup should go.
|
|
|
|
JumpDest RethrowDest;
|
|
|
|
|
|
|
|
/// A function to call to enter the catch.
|
|
|
|
llvm::Constant *BeginCatchFn;
|
|
|
|
|
|
|
|
/// An i1 variable indicating whether or not the @finally is
|
|
|
|
/// running for an exception.
|
|
|
|
llvm::AllocaInst *ForEHVar;
|
2009-12-09 11:35:49 +08:00
|
|
|
|
2011-06-22 10:32:12 +08:00
|
|
|
/// An i8* variable into which the exception pointer to rethrow
|
|
|
|
/// has been saved.
|
|
|
|
llvm::AllocaInst *SavedExnVar;
|
|
|
|
|
|
|
|
public:
|
|
|
|
void enter(CodeGenFunction &CGF, const Stmt *Finally,
|
|
|
|
llvm::Constant *beginCatchFn, llvm::Constant *endCatchFn,
|
|
|
|
llvm::Constant *rethrowFn);
|
|
|
|
void exit(CodeGenFunction &CGF);
|
|
|
|
};
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2015-02-13 07:40:45 +08:00
|
|
|
/// Returns true inside SEH __try blocks.
|
|
|
|
bool isSEHTryScope() const { return !SEHTryEpilogueStack.empty(); }
|
|
|
|
|
2015-10-29 07:06:42 +08:00
|
|
|
/// Returns true while emitting a cleanuppad.
|
2015-12-12 13:39:21 +08:00
|
|
|
bool isCleanupPadScope() const {
|
|
|
|
return CurrentFuncletPad && isa<llvm::CleanupPadInst>(CurrentFuncletPad);
|
|
|
|
}
|
2015-10-29 07:06:42 +08:00
|
|
|
|
2011-01-28 16:37:24 +08:00
|
|
|
/// pushFullExprCleanup - Push a cleanup to be run at the end of the
|
|
|
|
/// current full-expression. Safe against the possibility that
|
|
|
|
/// we're currently inside a conditionally-evaluated expression.
|
2015-03-13 07:41:40 +08:00
|
|
|
template <class T, class... As>
|
|
|
|
void pushFullExprCleanup(CleanupKind kind, As... A) {
|
2011-01-28 16:37:24 +08:00
|
|
|
// If we're not in a conditional branch, or if none of the
|
|
|
|
// arguments requires saving, then use the unconditional cleanup.
|
2011-07-12 08:15:30 +08:00
|
|
|
if (!isInConditionalBranch())
|
2015-03-13 07:41:40 +08:00
|
|
|
return EHStack.pushCleanup<T>(kind, A...);
|
2011-01-28 16:37:24 +08:00
|
|
|
|
2015-03-13 07:41:40 +08:00
|
|
|
// Stash values in a tuple so we can guarantee the order of saves.
|
|
|
|
typedef std::tuple<typename DominatingValue<As>::saved_type...> SavedTuple;
|
|
|
|
SavedTuple Saved{saveValueInCond(A)...};
|
2011-01-28 16:37:24 +08:00
|
|
|
|
2015-03-13 07:41:40 +08:00
|
|
|
typedef EHScopeStack::ConditionalCleanup<T, As...> CleanupType;
|
2015-03-13 07:46:55 +08:00
|
|
|
EHStack.pushCleanupTuple<CleanupType>(kind, Saved);
|
2011-07-13 00:41:08 +08:00
|
|
|
initFullExprCleanup();
|
|
|
|
}
|
|
|
|
|
2013-06-13 04:42:33 +08:00
|
|
|
/// \brief Queue a cleanup to be pushed after finishing the current
|
|
|
|
/// full-expression.
|
2015-03-13 07:41:40 +08:00
|
|
|
template <class T, class... As>
|
|
|
|
void pushCleanupAfterFullExpr(CleanupKind Kind, As... A) {
|
2013-06-13 04:42:33 +08:00
|
|
|
assert(!isInConditionalBranch() && "can't defer conditional cleanup");
|
|
|
|
|
|
|
|
LifetimeExtendedCleanupHeader Header = { sizeof(T), Kind };
|
|
|
|
|
|
|
|
size_t OldSize = LifetimeExtendedCleanupStack.size();
|
|
|
|
LifetimeExtendedCleanupStack.resize(
|
|
|
|
LifetimeExtendedCleanupStack.size() + sizeof(Header) + Header.Size);
|
|
|
|
|
2016-10-20 22:27:22 +08:00
|
|
|
static_assert(sizeof(Header) % alignof(T) == 0,
|
2015-07-01 08:59:27 +08:00
|
|
|
"Cleanup will be allocated on misaligned address");
|
2013-06-13 04:42:33 +08:00
|
|
|
char *Buffer = &LifetimeExtendedCleanupStack[OldSize];
|
|
|
|
new (Buffer) LifetimeExtendedCleanupHeader(Header);
|
2015-03-13 07:41:40 +08:00
|
|
|
new (Buffer + sizeof(Header)) T(A...);
|
2013-06-13 04:42:33 +08:00
|
|
|
}
|
|
|
|
|
2011-11-10 18:43:54 +08:00
|
|
|
/// Set up the last cleaup that was pushed as a conditional
|
|
|
|
/// full-expression cleanup.
|
|
|
|
void initFullExprCleanup();
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// PushDestructorCleanup - Push a cleanup to call the
|
|
|
|
/// complete-object destructor of an object of the given type at the
|
|
|
|
/// given address. Does nothing if T is not a C++ class type with a
|
|
|
|
/// non-trivial destructor.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void PushDestructorCleanup(QualType T, Address Addr);
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2010-07-21 14:29:51 +08:00
|
|
|
/// PushDestructorCleanup - Push a cleanup to call the
|
|
|
|
/// complete-object variant of the given destructor on the object at
|
|
|
|
/// the given address.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void PushDestructorCleanup(const CXXDestructorDecl *Dtor, Address Addr);
|
2010-07-21 14:29:51 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// PopCleanupBlock - Will pop the cleanup entry on the stack and
|
|
|
|
/// process all branch fixups.
|
2013-05-16 08:41:26 +08:00
|
|
|
void PopCleanupBlock(bool FallThroughIsBranchThrough = false);
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2010-09-14 15:57:04 +08:00
|
|
|
/// DeactivateCleanupBlock - Deactivates the given cleanup block.
|
|
|
|
/// The block cannot be reactivated. Pops it if it's the top of the
|
|
|
|
/// stack.
|
2011-11-10 18:43:54 +08:00
|
|
|
///
|
|
|
|
/// \param DominatingIP - An instruction which is known to
|
|
|
|
/// dominate the current IP (if set) and which lies along
|
|
|
|
/// all paths of execution between the current IP and the
|
|
|
|
/// the point at which the cleanup comes into scope.
|
|
|
|
void DeactivateCleanupBlock(EHScopeStack::stable_iterator Cleanup,
|
|
|
|
llvm::Instruction *DominatingIP);
|
2010-09-14 15:57:04 +08:00
|
|
|
|
|
|
|
/// ActivateCleanupBlock - Activates an initially-inactive cleanup.
|
|
|
|
/// Cannot be used to resurrect a deactivated cleanup.
|
2011-11-10 18:43:54 +08:00
|
|
|
///
|
|
|
|
/// \param DominatingIP - An instruction which is known to
|
|
|
|
/// dominate the current IP (if set) and which lies along
|
|
|
|
/// all paths of execution between the current IP and the
|
|
|
|
/// the point at which the cleanup comes into scope.
|
|
|
|
void ActivateCleanupBlock(EHScopeStack::stable_iterator Cleanup,
|
|
|
|
llvm::Instruction *DominatingIP);
|
2010-08-14 05:20:51 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// \brief Enters a new scope for capturing cleanups, all of which
|
|
|
|
/// will be executed once the scope is exited.
|
|
|
|
class RunCleanupsScope {
|
|
|
|
EHScopeStack::stable_iterator CleanupStackDepth;
|
2013-06-13 04:42:33 +08:00
|
|
|
size_t LifetimeExtendedCleanupStackSize;
|
2009-11-25 00:43:22 +08:00
|
|
|
bool OldDidCallStackSave;
|
2013-03-01 09:24:35 +08:00
|
|
|
protected:
|
2009-11-25 05:15:44 +08:00
|
|
|
bool PerformCleanup;
|
2013-03-01 09:24:35 +08:00
|
|
|
private:
|
2009-11-25 00:43:22 +08:00
|
|
|
|
2015-02-16 06:54:08 +08:00
|
|
|
RunCleanupsScope(const RunCleanupsScope &) = delete;
|
|
|
|
void operator=(const RunCleanupsScope &) = delete;
|
2009-11-25 00:43:22 +08:00
|
|
|
|
2011-10-19 08:43:52 +08:00
|
|
|
protected:
|
|
|
|
CodeGenFunction& CGF;
|
2013-01-18 19:30:38 +08:00
|
|
|
|
2009-11-25 00:43:22 +08:00
|
|
|
public:
|
|
|
|
/// \brief Enter a new cleanup scope.
|
2010-10-19 14:39:39 +08:00
|
|
|
explicit RunCleanupsScope(CodeGenFunction &CGF)
|
2011-10-19 08:43:52 +08:00
|
|
|
: PerformCleanup(true), CGF(CGF)
|
2009-11-25 05:15:44 +08:00
|
|
|
{
|
2010-07-06 09:34:17 +08:00
|
|
|
CleanupStackDepth = CGF.EHStack.stable_begin();
|
2013-06-13 04:42:33 +08:00
|
|
|
LifetimeExtendedCleanupStackSize =
|
|
|
|
CGF.LifetimeExtendedCleanupStack.size();
|
2009-11-25 00:43:22 +08:00
|
|
|
OldDidCallStackSave = CGF.DidCallStackSave;
|
2010-09-14 08:42:34 +08:00
|
|
|
CGF.DidCallStackSave = false;
|
2009-11-25 00:43:22 +08:00
|
|
|
}
|
|
|
|
|
2017-03-07 06:18:34 +08:00
|
|
|
/// \brief Exit this cleanup scope, emitting any accumulated cleanups.
|
2010-07-06 09:34:17 +08:00
|
|
|
~RunCleanupsScope() {
|
2017-03-07 06:18:34 +08:00
|
|
|
if (PerformCleanup)
|
|
|
|
ForceCleanup();
|
2009-11-25 05:15:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Determine whether this scope requires any cleanups.
|
|
|
|
bool requiresCleanups() const {
|
2010-07-06 09:34:17 +08:00
|
|
|
return CGF.EHStack.stable_begin() != CleanupStackDepth;
|
2009-11-25 05:15:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Force the emission of cleanups now, instead of waiting
|
|
|
|
/// until this object is destroyed.
|
2017-03-07 06:18:34 +08:00
|
|
|
/// \param ValuesToReload - A list of values that need to be available at
|
|
|
|
/// the insertion point after cleanup emission. If cleanup emission created
|
|
|
|
/// a shared cleanup block, these value pointers will be rewritten.
|
|
|
|
/// Otherwise, they not will be modified.
|
|
|
|
void ForceCleanup(std::initializer_list<llvm::Value**> ValuesToReload = {}) {
|
2009-11-25 05:15:44 +08:00
|
|
|
assert(PerformCleanup && "Already forced cleanup");
|
2009-11-25 00:43:22 +08:00
|
|
|
CGF.DidCallStackSave = OldDidCallStackSave;
|
2017-03-07 06:18:34 +08:00
|
|
|
CGF.PopCleanupBlocks(CleanupStackDepth, LifetimeExtendedCleanupStackSize,
|
|
|
|
ValuesToReload);
|
2009-11-25 05:15:44 +08:00
|
|
|
PerformCleanup = false;
|
2009-11-25 00:43:22 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-08-23 05:37:04 +08:00
|
|
|
class LexicalScope : public RunCleanupsScope {
|
2011-10-19 08:43:52 +08:00
|
|
|
SourceRange Range;
|
2013-03-23 14:43:35 +08:00
|
|
|
SmallVector<const LabelDecl*, 4> Labels;
|
|
|
|
LexicalScope *ParentScope;
|
2011-10-19 08:43:52 +08:00
|
|
|
|
2015-02-16 06:54:08 +08:00
|
|
|
LexicalScope(const LexicalScope &) = delete;
|
|
|
|
void operator=(const LexicalScope &) = delete;
|
2011-10-19 08:43:52 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
/// \brief Enter a new cleanup scope.
|
|
|
|
explicit LexicalScope(CodeGenFunction &CGF, SourceRange Range)
|
2013-03-23 14:43:35 +08:00
|
|
|
: RunCleanupsScope(CGF), Range(Range), ParentScope(CGF.CurLexicalScope) {
|
|
|
|
CGF.CurLexicalScope = this;
|
2011-10-19 08:43:52 +08:00
|
|
|
if (CGDebugInfo *DI = CGF.getDebugInfo())
|
|
|
|
DI->EmitLexicalBlockStart(CGF.Builder, Range.getBegin());
|
|
|
|
}
|
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
void addLabel(const LabelDecl *label) {
|
|
|
|
assert(PerformCleanup && "adding label to dead scope?");
|
|
|
|
Labels.push_back(label);
|
|
|
|
}
|
|
|
|
|
2011-10-19 08:43:52 +08:00
|
|
|
/// \brief Exit this cleanup scope, emitting any accumulated
|
|
|
|
/// cleanups.
|
|
|
|
~LexicalScope() {
|
2013-04-02 03:02:06 +08:00
|
|
|
if (CGDebugInfo *DI = CGF.getDebugInfo())
|
|
|
|
DI->EmitLexicalBlockEnd(CGF.Builder, Range.getEnd());
|
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
// If we should perform a cleanup, force them now. Note that
|
|
|
|
// this ends the cleanup scope before rescoping any labels.
|
2015-02-05 03:47:54 +08:00
|
|
|
if (PerformCleanup) {
|
|
|
|
ApplyDebugLocation DL(CGF, Range.getEnd());
|
|
|
|
ForceCleanup();
|
|
|
|
}
|
2011-10-19 08:43:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Force the emission of cleanups now, instead of waiting
|
|
|
|
/// until this object is destroyed.
|
|
|
|
void ForceCleanup() {
|
2013-04-02 03:02:06 +08:00
|
|
|
CGF.CurLexicalScope = ParentScope;
|
2011-10-19 08:43:52 +08:00
|
|
|
RunCleanupsScope::ForceCleanup();
|
2013-03-01 09:24:35 +08:00
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
if (!Labels.empty())
|
|
|
|
rescopeLabels();
|
2011-10-19 08:43:52 +08:00
|
|
|
}
|
2013-03-23 14:43:35 +08:00
|
|
|
|
2017-01-26 06:55:13 +08:00
|
|
|
bool hasLabels() const {
|
|
|
|
return !Labels.empty();
|
|
|
|
}
|
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
void rescopeLabels();
|
2011-10-19 08:43:52 +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
|
|
|
typedef llvm::DenseMap<const Decl *, Address> DeclMapTy;
|
|
|
|
|
2014-10-10 17:48:26 +08:00
|
|
|
/// \brief The scope used to remap some variables as private in the OpenMP
|
|
|
|
/// loop body (or other captured region emitted without outlining), and to
|
|
|
|
/// restore old vars back on exit.
|
|
|
|
class OMPPrivateScope : public RunCleanupsScope {
|
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
|
|
|
DeclMapTy SavedLocals;
|
|
|
|
DeclMapTy SavedPrivates;
|
2014-10-10 17:48:26 +08:00
|
|
|
|
|
|
|
private:
|
2015-02-16 06:54:08 +08:00
|
|
|
OMPPrivateScope(const OMPPrivateScope &) = delete;
|
|
|
|
void operator=(const OMPPrivateScope &) = delete;
|
2014-10-10 17:48:26 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
/// \brief Enter a new OpenMP private scope.
|
|
|
|
explicit OMPPrivateScope(CodeGenFunction &CGF) : RunCleanupsScope(CGF) {}
|
|
|
|
|
|
|
|
/// \brief Registers \a LocalVD variable as a private and apply \a
|
|
|
|
/// PrivateGen function for it to generate corresponding private variable.
|
|
|
|
/// \a PrivateGen returns an address of the generated private variable.
|
|
|
|
/// \return true if the variable is registered as private, false if it has
|
|
|
|
/// been privatized already.
|
|
|
|
bool
|
|
|
|
addPrivate(const VarDecl *LocalVD,
|
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::function_ref<Address()> PrivateGen) {
|
2014-10-10 17:48:26 +08:00
|
|
|
assert(PerformCleanup && "adding private to dead scope");
|
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
|
|
|
|
2017-08-23 01:54:52 +08:00
|
|
|
LocalVD = LocalVD->getCanonicalDecl();
|
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
|
|
|
// Only save it once.
|
|
|
|
if (SavedLocals.count(LocalVD)) return false;
|
|
|
|
|
|
|
|
// Copy the existing local entry to SavedLocals.
|
|
|
|
auto it = CGF.LocalDeclMap.find(LocalVD);
|
|
|
|
if (it != CGF.LocalDeclMap.end()) {
|
|
|
|
SavedLocals.insert({LocalVD, it->second});
|
|
|
|
} else {
|
|
|
|
SavedLocals.insert({LocalVD, Address::invalid()});
|
|
|
|
}
|
|
|
|
|
|
|
|
// Generate the private entry.
|
|
|
|
Address Addr = PrivateGen();
|
2015-09-04 19:26:21 +08:00
|
|
|
QualType VarTy = LocalVD->getType();
|
|
|
|
if (VarTy->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
|
|
|
Address Temp = CGF.CreateMemTemp(VarTy);
|
|
|
|
CGF.Builder.CreateStore(Addr.getPointer(), Temp);
|
|
|
|
Addr = Temp;
|
2015-09-04 19:26:21 +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
|
|
|
SavedPrivates.insert({LocalVD, Addr});
|
|
|
|
|
2014-10-10 17:48:26 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Privatizes local variables previously registered as private.
|
|
|
|
/// Registration is separate from the actual privatization to allow
|
|
|
|
/// initializers use values of the original variables, not the private one.
|
|
|
|
/// This is important, for example, if the private variable is a class
|
|
|
|
/// variable initialized by a constructor that references other private
|
|
|
|
/// variables. But at initialization original variables must be used, not
|
|
|
|
/// private copies.
|
|
|
|
/// \return true if at least one variable was privatized, false otherwise.
|
|
|
|
bool Privatize() {
|
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
|
|
|
copyInto(SavedPrivates, CGF.LocalDeclMap);
|
2014-10-10 17:48:26 +08:00
|
|
|
SavedPrivates.clear();
|
|
|
|
return !SavedLocals.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
void ForceCleanup() {
|
|
|
|
RunCleanupsScope::ForceCleanup();
|
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
|
|
|
copyInto(SavedLocals, CGF.LocalDeclMap);
|
2014-10-10 17:48:26 +08:00
|
|
|
SavedLocals.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Exit scope - all the mapped variables are restored.
|
2015-03-23 14:18:07 +08:00
|
|
|
~OMPPrivateScope() {
|
|
|
|
if (PerformCleanup)
|
|
|
|
ForceCleanup();
|
|
|
|
}
|
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
|
|
|
|
2016-04-27 15:56:03 +08:00
|
|
|
/// Checks if the global variable is captured in current function.
|
|
|
|
bool isGlobalVarCaptured(const VarDecl *VD) const {
|
2017-08-23 01:54:52 +08:00
|
|
|
VD = VD->getCanonicalDecl();
|
2016-04-27 15:56:03 +08:00
|
|
|
return !VD->isLocalVarDeclOrParm() && CGF.LocalDeclMap.count(VD) > 0;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
private:
|
|
|
|
/// Copy all the entries in the source map over the corresponding
|
|
|
|
/// entries in the destination, which must exist.
|
|
|
|
static void copyInto(const DeclMapTy &src, DeclMapTy &dest) {
|
|
|
|
for (auto &pair : src) {
|
|
|
|
if (!pair.second.isValid()) {
|
|
|
|
dest.erase(pair.first);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto it = dest.find(pair.first);
|
|
|
|
if (it != dest.end()) {
|
|
|
|
it->second = pair.second;
|
|
|
|
} else {
|
|
|
|
dest.insert(pair);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-10-10 17:48:26 +08:00
|
|
|
};
|
2010-03-30 11:14:41 +08:00
|
|
|
|
2013-06-13 04:42:33 +08:00
|
|
|
/// \brief Takes the old cleanup stack size and emits the cleanup blocks
|
|
|
|
/// that have been added.
|
2017-03-07 06:18:34 +08:00
|
|
|
void
|
|
|
|
PopCleanupBlocks(EHScopeStack::stable_iterator OldCleanupStackSize,
|
|
|
|
std::initializer_list<llvm::Value **> ValuesToReload = {});
|
2010-03-30 11:14:41 +08:00
|
|
|
|
2013-06-13 04:42:33 +08:00
|
|
|
/// \brief Takes the old cleanup stack size and emits the cleanup blocks
|
|
|
|
/// that have been added, then adds all lifetime-extended cleanups from
|
|
|
|
/// the given position to the stack.
|
2017-03-07 06:18:34 +08:00
|
|
|
void
|
|
|
|
PopCleanupBlocks(EHScopeStack::stable_iterator OldCleanupStackSize,
|
|
|
|
size_t OldLifetimeExtendedStackSize,
|
|
|
|
std::initializer_list<llvm::Value **> ValuesToReload = {});
|
2013-06-13 04:42:33 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
void ResolveBranchFixups(llvm::BasicBlock *Target);
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// The given basic block lies in the current EH scope, but may be a
|
|
|
|
/// target of a potentially scope-crossing jump; get a stable handle
|
|
|
|
/// to which we can perform this jump later.
|
2010-07-24 05:56:41 +08:00
|
|
|
JumpDest getJumpDestInCurrentScope(llvm::BasicBlock *Target) {
|
2010-07-28 09:07:35 +08:00
|
|
|
return JumpDest(Target,
|
|
|
|
EHStack.getInnermostNormalCleanup(),
|
|
|
|
NextCleanupDestIndex++);
|
2010-07-06 09:34:17 +08:00
|
|
|
}
|
2009-02-08 07:50:39 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// The given basic block lies in the current EH scope, but may be a
|
|
|
|
/// target of a potentially scope-crossing jump; get a stable handle
|
|
|
|
/// to which we can perform this jump later.
|
2011-07-20 14:58:45 +08:00
|
|
|
JumpDest getJumpDestInCurrentScope(StringRef Name = StringRef()) {
|
2010-07-24 05:56:41 +08:00
|
|
|
return getJumpDestInCurrentScope(createBasicBlock(Name));
|
2010-07-06 09:34:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// EmitBranchThroughCleanup - Emit a branch from the current insert
|
|
|
|
/// block through the normal cleanup handling code (if any) and then
|
|
|
|
/// on to \arg Dest.
|
|
|
|
void EmitBranchThroughCleanup(JumpDest Dest);
|
2011-04-17 08:54:30 +08:00
|
|
|
|
2014-01-21 08:35:11 +08:00
|
|
|
/// isObviouslyBranchWithoutCleanups - Return true if a branch to the
|
|
|
|
/// specified destination obviously has no cleanups to run. 'false' is always
|
|
|
|
/// a conservatively correct answer for this method.
|
|
|
|
bool isObviouslyBranchWithoutCleanups(JumpDest Dest) const;
|
|
|
|
|
2011-08-11 10:22:43 +08:00
|
|
|
/// popCatchScope - Pops the catch scope at the top of the EHScope
|
|
|
|
/// stack, emitting any required code (other than the catch handlers
|
|
|
|
/// themselves).
|
|
|
|
void popCatchScope();
|
2010-07-24 05:56:41 +08:00
|
|
|
|
2012-11-08 00:50:40 +08:00
|
|
|
llvm::BasicBlock *getEHResumeBlock(bool isCleanup);
|
2011-08-11 10:22:43 +08:00
|
|
|
llvm::BasicBlock *getEHDispatchBlock(EHScopeStack::stable_iterator scope);
|
2015-08-01 01:58:45 +08:00
|
|
|
llvm::BasicBlock *getMSVCDispatchBlock(EHScopeStack::stable_iterator scope);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
/// An object to manage conditionally-evaluated expressions.
|
|
|
|
class ConditionalEvaluation {
|
|
|
|
llvm::BasicBlock *StartBB;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
public:
|
|
|
|
ConditionalEvaluation(CodeGenFunction &CGF)
|
|
|
|
: StartBB(CGF.Builder.GetInsertBlock()) {}
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
void begin(CodeGenFunction &CGF) {
|
|
|
|
assert(CGF.OutermostConditional != this);
|
|
|
|
if (!CGF.OutermostConditional)
|
|
|
|
CGF.OutermostConditional = this;
|
|
|
|
}
|
|
|
|
|
|
|
|
void end(CodeGenFunction &CGF) {
|
2014-05-21 13:09:00 +08:00
|
|
|
assert(CGF.OutermostConditional != nullptr);
|
2011-01-26 12:00:11 +08:00
|
|
|
if (CGF.OutermostConditional == this)
|
2014-05-21 13:09:00 +08:00
|
|
|
CGF.OutermostConditional = nullptr;
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns a block which will be executed prior to each
|
|
|
|
/// evaluation of the conditional code.
|
|
|
|
llvm::BasicBlock *getStartingBlock() const {
|
|
|
|
return StartBB;
|
|
|
|
}
|
|
|
|
};
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-09-17 08:50:28 +08:00
|
|
|
/// isInConditionalBranch - Return true if we're currently emitting
|
|
|
|
/// one branch or the other of a conditional expression.
|
2014-05-21 13:09:00 +08:00
|
|
|
bool isInConditionalBranch() const { return OutermostConditional != nullptr; }
|
2011-01-26 12:00:11 +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
|
|
|
void setBeforeOutermostConditional(llvm::Value *value, Address addr) {
|
2011-11-10 18:43:54 +08:00
|
|
|
assert(isInConditionalBranch());
|
|
|
|
llvm::BasicBlock *block = OutermostConditional->getStartingBlock();
|
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 store = new llvm::StoreInst(value, addr.getPointer(), &block->back());
|
|
|
|
store->setAlignment(addr.getAlignment().getQuantity());
|
2011-11-10 18:43:54 +08:00
|
|
|
}
|
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
/// An RAII object to record that we're evaluating a statement
|
|
|
|
/// expression.
|
|
|
|
class StmtExprEvaluation {
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
|
|
|
|
/// We have to save the outermost conditional: cleanups in a
|
|
|
|
/// statement expression aren't conditional just because the
|
|
|
|
/// StmtExpr is.
|
|
|
|
ConditionalEvaluation *SavedOutermostConditional;
|
|
|
|
|
|
|
|
public:
|
|
|
|
StmtExprEvaluation(CodeGenFunction &CGF)
|
|
|
|
: CGF(CGF), SavedOutermostConditional(CGF.OutermostConditional) {
|
2014-05-21 13:09:00 +08:00
|
|
|
CGF.OutermostConditional = nullptr;
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
~StmtExprEvaluation() {
|
|
|
|
CGF.OutermostConditional = SavedOutermostConditional;
|
|
|
|
CGF.EnsureInsertPoint();
|
|
|
|
}
|
|
|
|
};
|
2011-02-16 16:02:54 +08:00
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
/// An object which temporarily prevents a value from being
|
|
|
|
/// destroyed by aggressive peephole optimizations that assume that
|
|
|
|
/// all uses of a value have been realized in the IR.
|
|
|
|
class PeepholeProtection {
|
|
|
|
llvm::Instruction *Inst;
|
|
|
|
friend class CodeGenFunction;
|
|
|
|
|
|
|
|
public:
|
2014-05-21 13:09:00 +08:00
|
|
|
PeepholeProtection() : Inst(nullptr) {}
|
2011-11-06 17:01:30 +08:00
|
|
|
};
|
2011-02-17 18:25:35 +08:00
|
|
|
|
2011-11-06 17:01:30 +08:00
|
|
|
/// A non-RAII class containing all the information about a bound
|
|
|
|
/// opaque value. OpaqueValueMapping, below, is a RAII wrapper for
|
|
|
|
/// this which makes individual mappings very simple; using this
|
|
|
|
/// class directly is useful when you have a variable number of
|
|
|
|
/// opaque values or don't want the RAII functionality for some
|
|
|
|
/// reason.
|
|
|
|
class OpaqueValueMappingData {
|
2011-02-16 16:02:54 +08:00
|
|
|
const OpaqueValueExpr *OpaqueValue;
|
2011-02-17 18:25:35 +08:00
|
|
|
bool BoundLValue;
|
|
|
|
CodeGenFunction::PeepholeProtection Protection;
|
2011-02-16 16:02:54 +08:00
|
|
|
|
2011-11-06 17:01:30 +08:00
|
|
|
OpaqueValueMappingData(const OpaqueValueExpr *ov,
|
|
|
|
bool boundLValue)
|
|
|
|
: OpaqueValue(ov), BoundLValue(boundLValue) {}
|
2011-02-16 16:02:54 +08:00
|
|
|
public:
|
2014-05-21 13:09:00 +08:00
|
|
|
OpaqueValueMappingData() : OpaqueValue(nullptr) {}
|
2011-11-06 17:01:30 +08:00
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
static bool shouldBindAsLValue(const Expr *expr) {
|
2011-11-09 06:54:08 +08:00
|
|
|
// gl-values should be bound as l-values for obvious reasons.
|
|
|
|
// Records should be bound as l-values because IR generation
|
|
|
|
// always keeps them in memory. Expressions of function type
|
|
|
|
// act exactly like l-values but are formally required to be
|
|
|
|
// r-values in C.
|
|
|
|
return expr->isGLValue() ||
|
2014-02-15 03:37:25 +08:00
|
|
|
expr->getType()->isFunctionType() ||
|
|
|
|
hasAggregateEvaluationKind(expr->getType());
|
2011-02-17 18:25:35 +08:00
|
|
|
}
|
|
|
|
|
2011-11-06 17:01:30 +08:00
|
|
|
static OpaqueValueMappingData bind(CodeGenFunction &CGF,
|
|
|
|
const OpaqueValueExpr *ov,
|
|
|
|
const Expr *e) {
|
|
|
|
if (shouldBindAsLValue(ov))
|
|
|
|
return bind(CGF, ov, CGF.EmitLValue(e));
|
|
|
|
return bind(CGF, ov, CGF.EmitAnyExpr(e));
|
|
|
|
}
|
|
|
|
|
|
|
|
static OpaqueValueMappingData bind(CodeGenFunction &CGF,
|
|
|
|
const OpaqueValueExpr *ov,
|
|
|
|
const LValue &lv) {
|
|
|
|
assert(shouldBindAsLValue(ov));
|
|
|
|
CGF.OpaqueLValues.insert(std::make_pair(ov, lv));
|
|
|
|
return OpaqueValueMappingData(ov, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static OpaqueValueMappingData bind(CodeGenFunction &CGF,
|
|
|
|
const OpaqueValueExpr *ov,
|
|
|
|
const RValue &rv) {
|
|
|
|
assert(!shouldBindAsLValue(ov));
|
|
|
|
CGF.OpaqueRValues.insert(std::make_pair(ov, rv));
|
|
|
|
|
|
|
|
OpaqueValueMappingData data(ov, false);
|
|
|
|
|
|
|
|
// Work around an extremely aggressive peephole optimization in
|
|
|
|
// EmitScalarConversion which assumes that all other uses of a
|
|
|
|
// value are extant.
|
|
|
|
data.Protection = CGF.protectFromPeepholes(rv);
|
|
|
|
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
|
2014-05-21 13:09:00 +08:00
|
|
|
bool isValid() const { return OpaqueValue != nullptr; }
|
|
|
|
void clear() { OpaqueValue = nullptr; }
|
2011-11-06 17:01:30 +08:00
|
|
|
|
|
|
|
void unbind(CodeGenFunction &CGF) {
|
|
|
|
assert(OpaqueValue && "no data to unbind!");
|
|
|
|
|
|
|
|
if (BoundLValue) {
|
|
|
|
CGF.OpaqueLValues.erase(OpaqueValue);
|
|
|
|
} else {
|
|
|
|
CGF.OpaqueRValues.erase(OpaqueValue);
|
|
|
|
CGF.unprotectFromPeepholes(Protection);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/// An RAII object to set (and then clear) a mapping for an OpaqueValueExpr.
|
|
|
|
class OpaqueValueMapping {
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
OpaqueValueMappingData Data;
|
|
|
|
|
|
|
|
public:
|
|
|
|
static bool shouldBindAsLValue(const Expr *expr) {
|
|
|
|
return OpaqueValueMappingData::shouldBindAsLValue(expr);
|
|
|
|
}
|
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
/// Build the opaque value mapping for the given conditional
|
|
|
|
/// operator if it's the GNU ?: extension. This is a common
|
|
|
|
/// enough pattern that the convenience operator is really
|
|
|
|
/// helpful.
|
|
|
|
///
|
|
|
|
OpaqueValueMapping(CodeGenFunction &CGF,
|
|
|
|
const AbstractConditionalOperator *op) : CGF(CGF) {
|
2011-11-06 17:01:30 +08:00
|
|
|
if (isa<ConditionalOperator>(op))
|
|
|
|
// Leave Data empty.
|
2011-02-17 18:25:35 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
const BinaryConditionalOperator *e = cast<BinaryConditionalOperator>(op);
|
2011-11-06 17:01:30 +08:00
|
|
|
Data = OpaqueValueMappingData::bind(CGF, e->getOpaqueValue(),
|
|
|
|
e->getCommon());
|
2011-02-17 18:25:35 +08:00
|
|
|
}
|
|
|
|
|
2016-12-12 10:53:20 +08:00
|
|
|
/// Build the opaque value mapping for an OpaqueValueExpr whose source
|
|
|
|
/// expression is set to the expression the OVE represents.
|
|
|
|
OpaqueValueMapping(CodeGenFunction &CGF, const OpaqueValueExpr *OV)
|
|
|
|
: CGF(CGF) {
|
|
|
|
if (OV) {
|
|
|
|
assert(OV->getSourceExpr() && "wrong form of OpaqueValueMapping used "
|
|
|
|
"for OVE with no source expression");
|
|
|
|
Data = OpaqueValueMappingData::bind(CGF, OV, OV->getSourceExpr());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-16 16:02:54 +08:00
|
|
|
OpaqueValueMapping(CodeGenFunction &CGF,
|
|
|
|
const OpaqueValueExpr *opaqueValue,
|
2011-02-17 18:25:35 +08:00
|
|
|
LValue lvalue)
|
2011-11-06 17:01:30 +08:00
|
|
|
: CGF(CGF), Data(OpaqueValueMappingData::bind(CGF, opaqueValue, lvalue)) {
|
2011-02-17 18:25:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
OpaqueValueMapping(CodeGenFunction &CGF,
|
|
|
|
const OpaqueValueExpr *opaqueValue,
|
|
|
|
RValue rvalue)
|
2011-11-06 17:01:30 +08:00
|
|
|
: CGF(CGF), Data(OpaqueValueMappingData::bind(CGF, opaqueValue, rvalue)) {
|
2011-02-16 16:02:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void pop() {
|
2011-11-06 17:01:30 +08:00
|
|
|
Data.unbind(CGF);
|
|
|
|
Data.clear();
|
2011-02-16 16:02:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
~OpaqueValueMapping() {
|
2011-11-06 17:01:30 +08:00
|
|
|
if (Data.isValid()) Data.unbind(CGF);
|
2011-02-16 16:02:54 +08:00
|
|
|
}
|
|
|
|
};
|
2010-11-17 03:29:39 +08:00
|
|
|
|
2007-08-24 13:35:26 +08:00
|
|
|
private:
|
2009-10-29 07:59:40 +08:00
|
|
|
CGDebugInfo *DebugInfo;
|
2011-03-08 02:45:56 +08:00
|
|
|
bool DisableDebugInfo;
|
2009-02-18 01:00:02 +08:00
|
|
|
|
2011-05-29 05:13:02 +08:00
|
|
|
/// DidCallStackSave - Whether llvm.stacksave has been called. Used to avoid
|
|
|
|
/// calling llvm.stacksave for multiple VLAs in the same scope.
|
|
|
|
bool DidCallStackSave;
|
|
|
|
|
2009-12-01 04:08:49 +08:00
|
|
|
/// IndirectBranch - The first time an indirect goto is seen we create a block
|
|
|
|
/// with an indirect branch. Every time we see the address of a label taken,
|
|
|
|
/// we add the label to the indirect goto. Every subsequent indirect goto is
|
|
|
|
/// codegen'd as a jump to the IndirectBranch's basic block.
|
2009-10-29 07:59:40 +08:00
|
|
|
llvm::IndirectBrInst *IndirectBranch;
|
2008-08-05 00:51:22 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// LocalDeclMap - This keeps track of the LLVM allocas or globals for local C
|
|
|
|
/// decls.
|
2011-02-07 18:33:21 +08:00
|
|
|
DeclMapTy LocalDeclMap;
|
2007-06-02 12:16:21 +08:00
|
|
|
|
2015-12-03 05:58:08 +08:00
|
|
|
/// SizeArguments - If a ParmVarDecl had the pass_object_size attribute, this
|
|
|
|
/// will contain a mapping from said ParmVarDecl to its implicit "object_size"
|
|
|
|
/// parameter.
|
|
|
|
llvm::SmallDenseMap<const ParmVarDecl *, const ImplicitParamDecl *, 2>
|
|
|
|
SizeArguments;
|
|
|
|
|
2015-04-09 06:23:48 +08:00
|
|
|
/// Track escaped local variables with auto storage. Used during SEH
|
2015-07-08 06:26:07 +08:00
|
|
|
/// outlining to produce a call to llvm.localescape.
|
2015-04-09 06:23:48 +08:00
|
|
|
llvm::DenseMap<llvm::AllocaInst *, int> EscapedLocals;
|
|
|
|
|
2007-05-30 08:13:02 +08:00
|
|
|
/// LabelMap - This keeps track of the LLVM basic block for each C label.
|
2011-02-17 15:39:24 +08:00
|
|
|
llvm::DenseMap<const LabelDecl*, JumpDest> LabelMap;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
|
|
|
// BreakContinueStack - This keeps track of where break and continue
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// statements should jump to.
|
2007-07-17 05:28:45 +08:00
|
|
|
struct BreakContinue {
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
BreakContinue(JumpDest Break, JumpDest Continue)
|
|
|
|
: BreakBlock(Break), ContinueBlock(Continue) {}
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
JumpDest BreakBlock;
|
|
|
|
JumpDest ContinueBlock;
|
2009-02-09 07:14:22 +08:00
|
|
|
};
|
2011-07-20 14:58:45 +08:00
|
|
|
SmallVector<BreakContinue, 8> BreakContinueStack;
|
2008-09-28 09:03:14 +08:00
|
|
|
|
2016-11-17 23:12:05 +08:00
|
|
|
/// Handles cancellation exit points in OpenMP-related constructs.
|
|
|
|
class OpenMPCancelExitStack {
|
|
|
|
/// Tracks cancellation exit point and join point for cancel-related exit
|
|
|
|
/// and normal exit.
|
|
|
|
struct CancelExit {
|
|
|
|
CancelExit() = default;
|
|
|
|
CancelExit(OpenMPDirectiveKind Kind, JumpDest ExitBlock,
|
|
|
|
JumpDest ContBlock)
|
|
|
|
: Kind(Kind), ExitBlock(ExitBlock), ContBlock(ContBlock) {}
|
|
|
|
OpenMPDirectiveKind Kind = OMPD_unknown;
|
|
|
|
/// true if the exit block has been emitted already by the special
|
|
|
|
/// emitExit() call, false if the default codegen is used.
|
|
|
|
bool HasBeenEmitted = false;
|
|
|
|
JumpDest ExitBlock;
|
|
|
|
JumpDest ContBlock;
|
|
|
|
};
|
|
|
|
|
|
|
|
SmallVector<CancelExit, 8> Stack;
|
|
|
|
|
|
|
|
public:
|
|
|
|
OpenMPCancelExitStack() : Stack(1) {}
|
|
|
|
~OpenMPCancelExitStack() = default;
|
|
|
|
/// Fetches the exit block for the current OpenMP construct.
|
|
|
|
JumpDest getExitBlock() const { return Stack.back().ExitBlock; }
|
|
|
|
/// Emits exit block with special codegen procedure specific for the related
|
|
|
|
/// OpenMP construct + emits code for normal construct cleanup.
|
|
|
|
void emitExit(CodeGenFunction &CGF, OpenMPDirectiveKind Kind,
|
|
|
|
const llvm::function_ref<void(CodeGenFunction &)> &CodeGen) {
|
|
|
|
if (Stack.back().Kind == Kind && getExitBlock().isValid()) {
|
|
|
|
assert(CGF.getOMPCancelDestination(Kind).isValid());
|
|
|
|
assert(CGF.HaveInsertPoint());
|
|
|
|
assert(!Stack.back().HasBeenEmitted);
|
|
|
|
auto IP = CGF.Builder.saveAndClearIP();
|
|
|
|
CGF.EmitBlock(Stack.back().ExitBlock.getBlock());
|
|
|
|
CodeGen(CGF);
|
2017-07-28 00:28:20 +08:00
|
|
|
CGF.EmitBranch(Stack.back().ContBlock.getBlock());
|
2016-11-17 23:12:05 +08:00
|
|
|
CGF.Builder.restoreIP(IP);
|
|
|
|
Stack.back().HasBeenEmitted = true;
|
|
|
|
}
|
|
|
|
CodeGen(CGF);
|
|
|
|
}
|
|
|
|
/// Enter the cancel supporting \a Kind construct.
|
|
|
|
/// \param Kind OpenMP directive that supports cancel constructs.
|
|
|
|
/// \param HasCancel true, if the construct has inner cancel directive,
|
|
|
|
/// false otherwise.
|
|
|
|
void enter(CodeGenFunction &CGF, OpenMPDirectiveKind Kind, bool HasCancel) {
|
|
|
|
Stack.push_back({Kind,
|
|
|
|
HasCancel ? CGF.getJumpDestInCurrentScope("cancel.exit")
|
|
|
|
: JumpDest(),
|
|
|
|
HasCancel ? CGF.getJumpDestInCurrentScope("cancel.cont")
|
|
|
|
: JumpDest()});
|
|
|
|
}
|
|
|
|
/// Emits default exit point for the cancel construct (if the special one
|
|
|
|
/// has not be used) + join point for cancel/normal exits.
|
|
|
|
void exit(CodeGenFunction &CGF) {
|
|
|
|
if (getExitBlock().isValid()) {
|
|
|
|
assert(CGF.getOMPCancelDestination(Stack.back().Kind).isValid());
|
|
|
|
bool HaveIP = CGF.HaveInsertPoint();
|
|
|
|
if (!Stack.back().HasBeenEmitted) {
|
|
|
|
if (HaveIP)
|
|
|
|
CGF.EmitBranchThroughCleanup(Stack.back().ContBlock);
|
|
|
|
CGF.EmitBlock(Stack.back().ExitBlock.getBlock());
|
|
|
|
CGF.EmitBranchThroughCleanup(Stack.back().ContBlock);
|
|
|
|
}
|
|
|
|
CGF.EmitBlock(Stack.back().ContBlock.getBlock());
|
|
|
|
if (!HaveIP) {
|
|
|
|
CGF.Builder.CreateUnreachable();
|
|
|
|
CGF.Builder.ClearInsertionPoint();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Stack.pop_back();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
OpenMPCancelExitStack OMPCancelStack;
|
|
|
|
|
|
|
|
/// Controls insertion of cancellation exit blocks in worksharing constructs.
|
|
|
|
class OMPCancelStackRAII {
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
|
|
|
|
public:
|
|
|
|
OMPCancelStackRAII(CodeGenFunction &CGF, OpenMPDirectiveKind Kind,
|
|
|
|
bool HasCancel)
|
|
|
|
: CGF(CGF) {
|
|
|
|
CGF.OMPCancelStack.enter(CGF, Kind, HasCancel);
|
|
|
|
}
|
|
|
|
~OMPCancelStackRAII() { CGF.OMPCancelStack.exit(CGF); }
|
|
|
|
};
|
|
|
|
|
2014-01-07 06:27:43 +08:00
|
|
|
CodeGenPGO PGO;
|
|
|
|
|
2015-05-02 13:00:55 +08:00
|
|
|
/// Calculate branch weights appropriate for PGO data
|
|
|
|
llvm::MDNode *createProfileWeights(uint64_t TrueCount, uint64_t FalseCount);
|
|
|
|
llvm::MDNode *createProfileWeights(ArrayRef<uint64_t> Weights);
|
|
|
|
llvm::MDNode *createProfileWeightsForLoop(const Stmt *Cond,
|
|
|
|
uint64_t LoopCount);
|
|
|
|
|
2014-01-07 06:27:43 +08:00
|
|
|
public:
|
2017-02-25 14:35:45 +08:00
|
|
|
/// Increment the profiler's counter for the given statement by \p StepV.
|
|
|
|
/// If \p StepV is null, the default increment is 1.
|
|
|
|
void incrementProfileCounter(const Stmt *S, llvm::Value *StepV = nullptr) {
|
2016-02-05 02:39:09 +08:00
|
|
|
if (CGM.getCodeGenOpts().hasProfileClangInstr())
|
2017-02-25 14:35:45 +08:00
|
|
|
PGO.emitCounterIncrement(Builder, S, StepV);
|
2015-04-24 07:06:47 +08:00
|
|
|
PGO.setCurrentStmt(S);
|
2014-01-07 06:27:43 +08:00
|
|
|
}
|
2015-04-24 07:06:47 +08:00
|
|
|
|
|
|
|
/// Get the profiler's count for the given statement.
|
|
|
|
uint64_t getProfileCount(const Stmt *S) {
|
|
|
|
Optional<uint64_t> Count = PGO.getStmtCount(S);
|
|
|
|
if (!Count.hasValue())
|
|
|
|
return 0;
|
|
|
|
return *Count;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set the profiler's current count.
|
|
|
|
void setCurrentProfileCount(uint64_t Count) {
|
|
|
|
PGO.setCurrentRegionCount(Count);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Get the profiler's current count. This is generally the count for the most
|
|
|
|
/// recently incremented counter.
|
|
|
|
uint64_t getCurrentProfileCount() {
|
|
|
|
return PGO.getCurrentRegionCount();
|
|
|
|
}
|
|
|
|
|
2014-01-07 06:27:43 +08:00
|
|
|
private:
|
|
|
|
|
2012-01-14 17:08:15 +08:00
|
|
|
/// SwitchInsn - This is nearest current switch instruction. It is null if
|
2009-02-09 07:14:22 +08:00
|
|
|
/// current context is not in a switch.
|
2007-10-05 07:45:31 +08:00
|
|
|
llvm::SwitchInst *SwitchInsn;
|
2014-01-07 06:27:43 +08:00
|
|
|
/// The branch weights of SwitchInsn when doing instrumentation based PGO.
|
|
|
|
SmallVector<uint64_t, 16> *SwitchWeights;
|
2007-10-05 07:45:31 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// CaseRangeBlock - This block holds if condition check for last case
|
2007-10-10 01:08:50 +08:00
|
|
|
/// statement range in current switch instruction.
|
2007-10-09 04:57:48 +08:00
|
|
|
llvm::BasicBlock *CaseRangeBlock;
|
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
/// OpaqueLValues - Keeps track of the current set of opaque value
|
2011-02-16 16:02:54 +08:00
|
|
|
/// expressions.
|
2011-02-17 18:25:35 +08:00
|
|
|
llvm::DenseMap<const OpaqueValueExpr *, LValue> OpaqueLValues;
|
|
|
|
llvm::DenseMap<const OpaqueValueExpr *, RValue> OpaqueRValues;
|
2011-02-16 16:02:54 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
// VLASizeMap - This keeps track of the associated size for each VLA type.
|
2009-08-15 10:50:32 +08:00
|
|
|
// We track this by the size expression rather than the type itself because
|
|
|
|
// in certain situations, like a const qualifier applied to an VLA typedef,
|
|
|
|
// multiple VLA types can share the same size expression.
|
2009-02-09 07:14:22 +08:00
|
|
|
// FIXME: Maybe this could be a stack of maps that is pushed/popped as we
|
|
|
|
// enter/leave scopes.
|
2009-08-15 10:50:32 +08:00
|
|
|
llvm::DenseMap<const Expr*, llvm::Value*> VLASizeMap;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// A block containing a single 'unreachable' instruction. Created
|
|
|
|
/// lazily by getUnreachableBlock().
|
|
|
|
llvm::BasicBlock *UnreachableBlock;
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2013-05-04 04:11:48 +08:00
|
|
|
/// Counts of the number return expressions in the function.
|
|
|
|
unsigned NumReturnExprs;
|
2013-05-03 01:30:20 +08:00
|
|
|
|
|
|
|
/// Count the number of simple (constant) return expressions in the function.
|
|
|
|
unsigned NumSimpleReturnExprs;
|
|
|
|
|
2013-05-04 04:11:48 +08:00
|
|
|
/// The last regular (non-return) debug location (breakpoint) in the function.
|
2014-01-08 06:05:52 +08:00
|
|
|
SourceLocation LastStopPoint;
|
2013-05-03 01:30:20 +08:00
|
|
|
|
2013-04-21 06:23:05 +08:00
|
|
|
public:
|
|
|
|
/// A scope within which we are constructing the fields of an object which
|
|
|
|
/// might use a CXXDefaultInitExpr. This stashes away a 'this' value to use
|
|
|
|
/// if we need to evaluate a CXXDefaultInitExpr within the evaluation.
|
|
|
|
class FieldConstructionScope {
|
|
|
|
public:
|
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
|
|
|
FieldConstructionScope(CodeGenFunction &CGF, Address This)
|
2013-04-21 06:23:05 +08:00
|
|
|
: CGF(CGF), OldCXXDefaultInitExprThis(CGF.CXXDefaultInitExprThis) {
|
|
|
|
CGF.CXXDefaultInitExprThis = This;
|
|
|
|
}
|
|
|
|
~FieldConstructionScope() {
|
|
|
|
CGF.CXXDefaultInitExprThis = OldCXXDefaultInitExprThis;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
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 OldCXXDefaultInitExprThis;
|
2013-04-21 06:23:05 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/// The scope of a CXXDefaultInitExpr. Within this scope, the value of 'this'
|
|
|
|
/// is overridden to be the object under construction.
|
|
|
|
class CXXDefaultInitExprScope {
|
|
|
|
public:
|
|
|
|
CXXDefaultInitExprScope(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
|
|
|
: CGF(CGF), OldCXXThisValue(CGF.CXXThisValue),
|
|
|
|
OldCXXThisAlignment(CGF.CXXThisAlignment) {
|
|
|
|
CGF.CXXThisValue = CGF.CXXDefaultInitExprThis.getPointer();
|
|
|
|
CGF.CXXThisAlignment = CGF.CXXDefaultInitExprThis.getAlignment();
|
2013-04-21 06:23:05 +08:00
|
|
|
}
|
|
|
|
~CXXDefaultInitExprScope() {
|
|
|
|
CGF.CXXThisValue = OldCXXThisValue;
|
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.CXXThisAlignment = OldCXXThisAlignment;
|
2013-04-21 06:23:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
llvm::Value *OldCXXThisValue;
|
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 OldCXXThisAlignment;
|
2013-04-21 06:23:05 +08:00
|
|
|
};
|
|
|
|
|
2016-12-12 10:53:20 +08:00
|
|
|
/// The scope of an ArrayInitLoopExpr. Within this scope, the value of the
|
|
|
|
/// current loop index is overridden.
|
|
|
|
class ArrayInitLoopExprScope {
|
|
|
|
public:
|
|
|
|
ArrayInitLoopExprScope(CodeGenFunction &CGF, llvm::Value *Index)
|
|
|
|
: CGF(CGF), OldArrayInitIndex(CGF.ArrayInitIndex) {
|
|
|
|
CGF.ArrayInitIndex = Index;
|
|
|
|
}
|
|
|
|
~ArrayInitLoopExprScope() {
|
|
|
|
CGF.ArrayInitIndex = OldArrayInitIndex;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
llvm::Value *OldArrayInitIndex;
|
|
|
|
};
|
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
class InlinedInheritingConstructorScope {
|
|
|
|
public:
|
|
|
|
InlinedInheritingConstructorScope(CodeGenFunction &CGF, GlobalDecl GD)
|
|
|
|
: CGF(CGF), OldCurGD(CGF.CurGD), OldCurFuncDecl(CGF.CurFuncDecl),
|
|
|
|
OldCurCodeDecl(CGF.CurCodeDecl),
|
|
|
|
OldCXXABIThisDecl(CGF.CXXABIThisDecl),
|
|
|
|
OldCXXABIThisValue(CGF.CXXABIThisValue),
|
|
|
|
OldCXXThisValue(CGF.CXXThisValue),
|
|
|
|
OldCXXABIThisAlignment(CGF.CXXABIThisAlignment),
|
|
|
|
OldCXXThisAlignment(CGF.CXXThisAlignment),
|
|
|
|
OldReturnValue(CGF.ReturnValue), OldFnRetTy(CGF.FnRetTy),
|
|
|
|
OldCXXInheritedCtorInitExprArgs(
|
|
|
|
std::move(CGF.CXXInheritedCtorInitExprArgs)) {
|
|
|
|
CGF.CurGD = GD;
|
|
|
|
CGF.CurFuncDecl = CGF.CurCodeDecl =
|
|
|
|
cast<CXXConstructorDecl>(GD.getDecl());
|
|
|
|
CGF.CXXABIThisDecl = nullptr;
|
|
|
|
CGF.CXXABIThisValue = nullptr;
|
|
|
|
CGF.CXXThisValue = nullptr;
|
|
|
|
CGF.CXXABIThisAlignment = CharUnits();
|
|
|
|
CGF.CXXThisAlignment = CharUnits();
|
|
|
|
CGF.ReturnValue = Address::invalid();
|
|
|
|
CGF.FnRetTy = QualType();
|
|
|
|
CGF.CXXInheritedCtorInitExprArgs.clear();
|
|
|
|
}
|
|
|
|
~InlinedInheritingConstructorScope() {
|
|
|
|
CGF.CurGD = OldCurGD;
|
|
|
|
CGF.CurFuncDecl = OldCurFuncDecl;
|
|
|
|
CGF.CurCodeDecl = OldCurCodeDecl;
|
|
|
|
CGF.CXXABIThisDecl = OldCXXABIThisDecl;
|
|
|
|
CGF.CXXABIThisValue = OldCXXABIThisValue;
|
|
|
|
CGF.CXXThisValue = OldCXXThisValue;
|
|
|
|
CGF.CXXABIThisAlignment = OldCXXABIThisAlignment;
|
|
|
|
CGF.CXXThisAlignment = OldCXXThisAlignment;
|
|
|
|
CGF.ReturnValue = OldReturnValue;
|
|
|
|
CGF.FnRetTy = OldFnRetTy;
|
|
|
|
CGF.CXXInheritedCtorInitExprArgs =
|
|
|
|
std::move(OldCXXInheritedCtorInitExprArgs);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
CodeGenFunction &CGF;
|
|
|
|
GlobalDecl OldCurGD;
|
|
|
|
const Decl *OldCurFuncDecl;
|
|
|
|
const Decl *OldCurCodeDecl;
|
|
|
|
ImplicitParamDecl *OldCXXABIThisDecl;
|
|
|
|
llvm::Value *OldCXXABIThisValue;
|
|
|
|
llvm::Value *OldCXXThisValue;
|
|
|
|
CharUnits OldCXXABIThisAlignment;
|
|
|
|
CharUnits OldCXXThisAlignment;
|
|
|
|
Address OldReturnValue;
|
|
|
|
QualType OldFnRetTy;
|
|
|
|
CallArgList OldCXXInheritedCtorInitExprArgs;
|
|
|
|
};
|
|
|
|
|
2013-04-21 06:23:05 +08:00
|
|
|
private:
|
2009-11-25 11:15:49 +08:00
|
|
|
/// CXXThisDecl - When generating code for a C++ member function,
|
|
|
|
/// this will hold the implicit 'this' declaration.
|
2012-02-11 10:57:39 +08:00
|
|
|
ImplicitParamDecl *CXXABIThisDecl;
|
|
|
|
llvm::Value *CXXABIThisValue;
|
2010-02-17 06:04:33 +08:00
|
|
|
llvm::Value *CXXThisValue;
|
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 CXXABIThisAlignment;
|
|
|
|
CharUnits CXXThisAlignment;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-04-21 06:23:05 +08:00
|
|
|
/// The value of 'this' to use when evaluating CXXDefaultInitExprs within
|
|
|
|
/// this expression.
|
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 CXXDefaultInitExprThis = Address::invalid();
|
2013-04-21 06:23:05 +08:00
|
|
|
|
2016-12-12 10:53:20 +08:00
|
|
|
/// The current array initialization index when evaluating an
|
|
|
|
/// ArrayInitIndexExpr within an ArrayInitLoopExpr.
|
|
|
|
llvm::Value *ArrayInitIndex = nullptr;
|
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
/// The values of function arguments to use when evaluating
|
|
|
|
/// CXXInheritedCtorInitExprs within this context.
|
|
|
|
CallArgList CXXInheritedCtorInitExprArgs;
|
|
|
|
|
2013-02-13 16:37:51 +08:00
|
|
|
/// CXXStructorImplicitParamDecl - When generating code for a constructor or
|
|
|
|
/// destructor, this will hold the implicit argument (e.g. VTT).
|
|
|
|
ImplicitParamDecl *CXXStructorImplicitParamDecl;
|
|
|
|
llvm::Value *CXXStructorImplicitParamValue;
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
/// OutermostConditional - Points to the outermost active
|
|
|
|
/// conditional control. This is used so that we know if a
|
|
|
|
/// temporary should be destroyed conditionally.
|
|
|
|
ConditionalEvaluation *OutermostConditional;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
/// The current lexical scope.
|
|
|
|
LexicalScope *CurLexicalScope;
|
2009-09-12 10:14:24 +08:00
|
|
|
|
2013-05-16 08:41:26 +08:00
|
|
|
/// The current source location that should be used for exception
|
|
|
|
/// handling code.
|
|
|
|
SourceLocation CurEHLocation;
|
|
|
|
|
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
|
|
|
/// BlockByrefInfos - For each __block variable, contains
|
|
|
|
/// information about the layout of the variable.
|
|
|
|
llvm::DenseMap<const ValueDecl *, BlockByrefInfo> BlockByrefInfos;
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2017-03-14 09:56:34 +08:00
|
|
|
/// Used by -fsanitize=nullability-return to determine whether the return
|
|
|
|
/// value can be checked.
|
|
|
|
llvm::Value *RetValNullabilityPrecondition = nullptr;
|
|
|
|
|
|
|
|
/// Check if -fsanitize=nullability-return instrumentation is required for
|
|
|
|
/// this function.
|
|
|
|
bool requiresReturnValueNullabilityCheck() const {
|
|
|
|
return RetValNullabilityPrecondition;
|
|
|
|
}
|
|
|
|
|
2017-06-24 05:32:38 +08:00
|
|
|
/// Used to store precise source locations for return statements by the
|
|
|
|
/// runtime return value checks.
|
|
|
|
Address ReturnLocation = Address::invalid();
|
|
|
|
|
|
|
|
/// Check if the return value of this function requires sanitization.
|
|
|
|
bool requiresReturnValueCheck() const {
|
|
|
|
return requiresReturnValueNullabilityCheck() ||
|
|
|
|
(SanOpts.has(SanitizerKind::ReturnsNonnullAttribute) &&
|
|
|
|
CurCodeDecl && CurCodeDecl->getAttr<ReturnsNonNullAttr>());
|
|
|
|
}
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::BasicBlock *TerminateLandingPad;
|
2009-12-10 08:02:42 +08:00
|
|
|
llvm::BasicBlock *TerminateHandler;
|
2010-07-21 05:07:09 +08:00
|
|
|
llvm::BasicBlock *TrapBB;
|
2009-12-10 10:21:21 +08:00
|
|
|
|
2016-10-26 09:59:57 +08:00
|
|
|
/// True if we need emit the life-time markers.
|
|
|
|
const bool ShouldEmitLifetimeMarkers;
|
|
|
|
|
2017-05-04 15:31:20 +08:00
|
|
|
/// Add OpenCL kernel arg metadata and the kernel attribute meatadata to
|
|
|
|
/// the function metadata.
|
2012-07-10 06:06:01 +08:00
|
|
|
void EmitOpenCLKernelMetadata(const FunctionDecl *FD,
|
|
|
|
llvm::Function *Fn);
|
|
|
|
|
2007-05-28 09:07:47 +08:00
|
|
|
public:
|
2012-06-27 00:06:38 +08:00
|
|
|
CodeGenFunction(CodeGenModule &cgm, bool suppressNewContext=false);
|
2011-11-10 16:15:53 +08:00
|
|
|
~CodeGenFunction();
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-09-02 17:58:18 +08:00
|
|
|
CodeGenTypes &getTypes() const { return CGM.getTypes(); }
|
2011-05-15 10:34:36 +08:00
|
|
|
ASTContext &getContext() const { return CGM.getContext(); }
|
2011-03-08 02:45:56 +08:00
|
|
|
CGDebugInfo *getDebugInfo() {
|
|
|
|
if (DisableDebugInfo)
|
2014-05-21 13:09:00 +08:00
|
|
|
return nullptr;
|
2011-03-08 02:45:56 +08:00
|
|
|
return DebugInfo;
|
|
|
|
}
|
|
|
|
void disableDebugInfo() { DisableDebugInfo = true; }
|
|
|
|
void enableDebugInfo() { DisableDebugInfo = false; }
|
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
bool shouldUseFusedARCCalls() {
|
|
|
|
return CGM.getCodeGenOpts().OptimizationLevel == 0;
|
|
|
|
}
|
2007-06-03 06:49:07 +08:00
|
|
|
|
2012-03-11 15:00:24 +08:00
|
|
|
const LangOptions &getLangOpts() const { return CGM.getLangOpts(); }
|
2011-02-08 16:22:06 +08:00
|
|
|
|
2011-09-20 04:31:14 +08:00
|
|
|
/// Returns a pointer to the function's exception object and selector slot,
|
|
|
|
/// which is assigned in every landing pad.
|
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 getExceptionSlot();
|
|
|
|
Address getEHSelectorSlot();
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2011-09-16 02:57:19 +08:00
|
|
|
/// Returns the contents of the function's exception object and selector
|
|
|
|
/// slots.
|
|
|
|
llvm::Value *getExceptionFromSlot();
|
|
|
|
llvm::Value *getSelectorFromSlot();
|
|
|
|
|
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 getNormalCleanupDestSlot();
|
2010-07-24 05:56:41 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::BasicBlock *getUnreachableBlock() {
|
|
|
|
if (!UnreachableBlock) {
|
|
|
|
UnreachableBlock = createBasicBlock("unreachable");
|
|
|
|
new llvm::UnreachableInst(getLLVMContext(), UnreachableBlock);
|
|
|
|
}
|
|
|
|
return UnreachableBlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::BasicBlock *getInvokeDest() {
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!EHStack.requiresLandingPad()) return nullptr;
|
2010-07-06 09:34:17 +08:00
|
|
|
return getInvokeDestImpl();
|
|
|
|
}
|
2009-02-24 01:26:39 +08:00
|
|
|
|
2016-03-02 03:42:53 +08:00
|
|
|
bool currentFunctionUsesSEHTry() const { return CurSEHParent != nullptr; }
|
2015-02-11 08:00:21 +08:00
|
|
|
|
2013-04-17 06:48:15 +08:00
|
|
|
const TargetInfo &getTarget() const { return Target; }
|
2011-02-08 16:22:06 +08:00
|
|
|
llvm::LLVMContext &getLLVMContext() { return CGM.getLLVMContext(); }
|
2017-07-08 21:24:52 +08:00
|
|
|
const TargetCodeGenInfo &getTargetHooks() const {
|
|
|
|
return CGM.getTargetCodeGenInfo();
|
|
|
|
}
|
2009-07-13 12:10:07 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Cleanups
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
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
|
|
|
typedef void Destroyer(CodeGenFunction &CGF, Address addr, QualType ty);
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2011-07-11 16:38:19 +08:00
|
|
|
void pushIrregularPartialArrayCleanup(llvm::Value *arrayBegin,
|
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 arrayEndPointer,
|
2011-07-11 16:38:19 +08:00
|
|
|
QualType 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
|
|
|
CharUnits elementAlignment,
|
2012-01-26 11:33:36 +08:00
|
|
|
Destroyer *destroyer);
|
2011-07-11 16:38:19 +08:00
|
|
|
void pushRegularPartialArrayCleanup(llvm::Value *arrayBegin,
|
|
|
|
llvm::Value *arrayEnd,
|
|
|
|
QualType 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
|
|
|
CharUnits elementAlignment,
|
2012-01-26 11:33:36 +08:00
|
|
|
Destroyer *destroyer);
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2011-07-13 00:41:08 +08:00
|
|
|
void pushDestroy(QualType::DestructionKind dtorKind,
|
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 addr, QualType type);
|
2013-02-01 13:11:40 +08:00
|
|
|
void pushEHDestroy(QualType::DestructionKind dtorKind,
|
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 addr, QualType type);
|
|
|
|
void pushDestroy(CleanupKind kind, Address addr, QualType type,
|
2012-01-26 11:33:36 +08:00
|
|
|
Destroyer *destroyer, bool useEHCleanupForArray);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void pushLifetimeExtendedDestroy(CleanupKind kind, Address addr,
|
2013-06-13 04:42:33 +08:00
|
|
|
QualType type, Destroyer *destroyer,
|
|
|
|
bool useEHCleanupForArray);
|
2014-11-01 04:09:12 +08:00
|
|
|
void pushCallObjectDeleteCleanup(const FunctionDecl *OperatorDelete,
|
|
|
|
llvm::Value *CompletePtr,
|
|
|
|
QualType 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
|
|
|
void pushStackRestore(CleanupKind kind, Address SPMem);
|
|
|
|
void emitDestroy(Address addr, QualType type, Destroyer *destroyer,
|
2011-07-11 16:38:19 +08:00
|
|
|
bool useEHCleanupForArray);
|
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::Function *generateDestroyHelper(Address addr, QualType type,
|
2012-01-26 11:33:36 +08:00
|
|
|
Destroyer *destroyer,
|
2013-08-28 07:57:18 +08:00
|
|
|
bool useEHCleanupForArray,
|
|
|
|
const VarDecl *VD);
|
2011-07-09 09:37:26 +08:00
|
|
|
void emitArrayDestroy(llvm::Value *begin, llvm::Value *end,
|
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
|
|
|
QualType elementType, CharUnits elementAlign,
|
|
|
|
Destroyer *destroyer,
|
2011-07-13 16:09:46 +08:00
|
|
|
bool checkZeroLength, bool useEHCleanup);
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2012-01-26 11:33:36 +08:00
|
|
|
Destroyer *getDestroyer(QualType::DestructionKind destructionKind);
|
2011-07-13 00:41:08 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
/// Determines whether an EH cleanup is required to destroy a type
|
|
|
|
/// with the given destruction kind.
|
|
|
|
bool needsEHCleanup(QualType::DestructionKind kind) {
|
|
|
|
switch (kind) {
|
|
|
|
case QualType::DK_none:
|
|
|
|
return false;
|
|
|
|
case QualType::DK_cxx_destructor:
|
|
|
|
case QualType::DK_objc_weak_lifetime:
|
2012-03-11 15:00:24 +08:00
|
|
|
return getLangOpts().Exceptions;
|
2011-07-09 09:37:26 +08:00
|
|
|
case QualType::DK_objc_strong_lifetime:
|
2012-03-11 15:00:24 +08:00
|
|
|
return getLangOpts().Exceptions &&
|
2011-07-09 09:37:26 +08:00
|
|
|
CGM.getCodeGenOpts().ObjCAutoRefCountExceptions;
|
|
|
|
}
|
|
|
|
llvm_unreachable("bad destruction kind");
|
|
|
|
}
|
|
|
|
|
2011-07-13 00:41:08 +08:00
|
|
|
CleanupKind getCleanupKind(QualType::DestructionKind kind) {
|
|
|
|
return (needsEHCleanup(kind) ? NormalAndEHCleanup : NormalCleanup);
|
|
|
|
}
|
|
|
|
|
2009-02-24 01:26:39 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Objective-C
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2008-03-31 07:03:07 +08:00
|
|
|
void GenerateObjCMethod(const ObjCMethodDecl *OMD);
|
2008-08-26 16:29:31 +08:00
|
|
|
|
2015-01-14 08:04:42 +08:00
|
|
|
void StartObjCMethod(const ObjCMethodDecl *MD, const ObjCContainerDecl *CD);
|
2008-08-26 16:29:31 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// GenerateObjCGetter - Synthesize an Objective-C property getter function.
|
2008-12-10 04:23:04 +08:00
|
|
|
void GenerateObjCGetter(ObjCImplementationDecl *IMP,
|
|
|
|
const ObjCPropertyImplDecl *PID);
|
2011-09-13 11:34:09 +08:00
|
|
|
void generateObjCGetterBody(const ObjCImplementationDecl *classImpl,
|
2012-01-08 02:56:22 +08:00
|
|
|
const ObjCPropertyImplDecl *propImpl,
|
2012-05-30 03:56:01 +08:00
|
|
|
const ObjCMethodDecl *GetterMothodDecl,
|
2012-01-08 02:56:22 +08:00
|
|
|
llvm::Constant *AtomicHelperFn);
|
2011-02-19 03:15:13 +08:00
|
|
|
|
2010-04-29 05:28:56 +08:00
|
|
|
void GenerateObjCCtorDtorMethod(ObjCImplementationDecl *IMP,
|
|
|
|
ObjCMethodDecl *MD, bool ctor);
|
2008-08-26 16:29:31 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// GenerateObjCSetter - Synthesize an Objective-C property setter function
|
|
|
|
/// for the given property.
|
2008-12-10 04:23:04 +08:00
|
|
|
void GenerateObjCSetter(ObjCImplementationDecl *IMP,
|
|
|
|
const ObjCPropertyImplDecl *PID);
|
2011-09-10 17:17:20 +08:00
|
|
|
void generateObjCSetterBody(const ObjCImplementationDecl *classImpl,
|
2012-01-07 06:33:54 +08:00
|
|
|
const ObjCPropertyImplDecl *propImpl,
|
|
|
|
llvm::Constant *AtomicHelperFn);
|
2008-08-26 16:29:31 +08:00
|
|
|
|
2009-02-22 04:00:35 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Block Bits
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2011-02-07 18:33:21 +08:00
|
|
|
llvm::Value *EmitBlockLiteral(const BlockExpr *);
|
2011-11-10 16:15:53 +08:00
|
|
|
static void destroyBlockInfos(CGBlockInfo *info);
|
2009-02-22 04:00:35 +08:00
|
|
|
|
2010-06-24 08:08:06 +08:00
|
|
|
llvm::Function *GenerateBlockFunction(GlobalDecl GD,
|
2011-02-07 18:33:21 +08:00
|
|
|
const CGBlockInfo &Info,
|
2012-02-25 10:48:22 +08:00
|
|
|
const DeclMapTy &ldm,
|
2017-09-23 05:32:06 +08:00
|
|
|
bool IsLambdaConversionToBlock,
|
|
|
|
bool BuildGlobalBlock);
|
2009-02-22 04:00:35 +08:00
|
|
|
|
2011-02-08 16:22:06 +08:00
|
|
|
llvm::Constant *GenerateCopyHelperFunction(const CGBlockInfo &blockInfo);
|
|
|
|
llvm::Constant *GenerateDestroyHelperFunction(const CGBlockInfo &blockInfo);
|
2012-01-10 08:37:01 +08:00
|
|
|
llvm::Constant *GenerateObjCAtomicSetterCopyHelperFunction(
|
|
|
|
const ObjCPropertyImplDecl *PID);
|
|
|
|
llvm::Constant *GenerateObjCAtomicGetterCopyHelperFunction(
|
|
|
|
const ObjCPropertyImplDecl *PID);
|
2012-02-28 09:08:45 +08:00
|
|
|
llvm::Value *EmitBlockCopyAndAutorelease(llvm::Value *Block, QualType Ty);
|
2011-02-08 16:22:06 +08:00
|
|
|
|
|
|
|
void BuildBlockRelease(llvm::Value *DeclPtr, BlockFieldFlags flags);
|
|
|
|
|
2011-03-31 09:59:53 +08:00
|
|
|
class AutoVarEmission;
|
|
|
|
|
|
|
|
void emitByrefStructureInit(const AutoVarEmission &emission);
|
|
|
|
void enterByrefCleanup(const AutoVarEmission &emission);
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void setBlockContextParameter(const ImplicitParamDecl *D, unsigned argNum,
|
|
|
|
llvm::Value *ptr);
|
|
|
|
|
|
|
|
Address LoadBlockStruct();
|
|
|
|
Address GetAddrOfBlockDecl(const VarDecl *var, bool ByRef);
|
|
|
|
|
|
|
|
/// BuildBlockByrefAddress - Computes the location of the
|
|
|
|
/// data in a variable which is declared as __block.
|
|
|
|
Address emitBlockByrefAddress(Address baseAddr, const VarDecl *V,
|
|
|
|
bool followForward = true);
|
|
|
|
Address emitBlockByrefAddress(Address baseAddr,
|
|
|
|
const BlockByrefInfo &info,
|
|
|
|
bool followForward,
|
|
|
|
const llvm::Twine &name);
|
|
|
|
|
|
|
|
const BlockByrefInfo &getBlockByrefInfo(const VarDecl *var);
|
2009-03-04 11:23:46 +08:00
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
QualType BuildFunctionArgList(GlobalDecl GD, FunctionArgList &Args);
|
|
|
|
|
2011-03-09 12:27:21 +08:00
|
|
|
void GenerateCode(GlobalDecl GD, llvm::Function *Fn,
|
|
|
|
const CGFunctionInfo &FnInfo);
|
2014-04-11 07:21:53 +08:00
|
|
|
/// \brief Emit code for the start of a function.
|
|
|
|
/// \param Loc The location to be associated with the function.
|
|
|
|
/// \param StartLoc The location of the function body.
|
2013-05-03 15:33:41 +08:00
|
|
|
void StartFunction(GlobalDecl GD,
|
|
|
|
QualType RetTy,
|
2008-09-10 07:14:03 +08:00
|
|
|
llvm::Function *Fn,
|
2011-03-09 12:27:21 +08:00
|
|
|
const CGFunctionInfo &FnInfo,
|
2008-10-19 02:22:23 +08:00
|
|
|
const FunctionArgList &Args,
|
2014-04-11 09:13:04 +08:00
|
|
|
SourceLocation Loc = SourceLocation(),
|
|
|
|
SourceLocation StartLoc = SourceLocation());
|
2008-11-12 07:11:34 +08:00
|
|
|
|
2017-02-24 09:15:19 +08:00
|
|
|
static bool IsConstructorDelegationValid(const CXXConstructorDecl *Ctor);
|
|
|
|
|
2010-02-19 17:25:03 +08:00
|
|
|
void EmitConstructorBody(FunctionArgList &Args);
|
|
|
|
void EmitDestructorBody(FunctionArgList &Args);
|
2013-02-17 15:22:09 +08:00
|
|
|
void emitImplicitAssignmentOperatorBody(FunctionArgList &Args);
|
2013-11-05 17:12:18 +08:00
|
|
|
void EmitFunctionBody(FunctionArgList &Args, const Stmt *Body);
|
2015-04-24 07:06:47 +08:00
|
|
|
void EmitBlockWithFallThrough(llvm::BasicBlock *BB, const Stmt *S);
|
2010-02-18 11:17:58 +08:00
|
|
|
|
2013-09-29 16:45:24 +08:00
|
|
|
void EmitForwardingCallToLambda(const CXXMethodDecl *LambdaCallOperator,
|
2012-02-25 10:48:22 +08:00
|
|
|
CallArgList &CallArgs);
|
|
|
|
void EmitLambdaBlockInvokeBody();
|
2012-02-17 11:02:34 +08:00
|
|
|
void EmitLambdaDelegatingInvokeBody(const CXXMethodDecl *MD);
|
2017-08-05 06:38:06 +08:00
|
|
|
void EmitLambdaStaticInvokeBody(const CXXMethodDecl *MD);
|
2014-10-17 04:54:52 +08:00
|
|
|
void EmitAsanPrologueOrEpilogue(bool Prologue);
|
2012-02-16 09:37:33 +08:00
|
|
|
|
2015-01-18 10:48:07 +08:00
|
|
|
/// \brief Emit the unified return block, trying to avoid its emission when
|
|
|
|
/// possible.
|
|
|
|
/// \return The debug location of the user written return statement if the
|
|
|
|
/// return block is is avoided.
|
2015-01-14 15:38:27 +08:00
|
|
|
llvm::DebugLoc EmitReturnBlock();
|
2009-01-27 07:27:52 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// FinishFunction - Complete IR generation of the current function. It is
|
|
|
|
/// legal to call this function even if there is no current insertion point.
|
2008-08-26 16:29:31 +08:00
|
|
|
void FinishFunction(SourceLocation EndLoc=SourceLocation());
|
2008-09-10 07:27:19 +08:00
|
|
|
|
2015-02-12 06:33:32 +08:00
|
|
|
void StartThunk(llvm::Function *Fn, GlobalDecl GD,
|
|
|
|
const CGFunctionInfo &FnInfo);
|
2013-11-16 01:24:45 +08:00
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
void EmitCallAndReturnForThunk(llvm::Constant *Callee,
|
|
|
|
const ThunkInfo *Thunk);
|
2013-11-16 01:24:45 +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
|
|
|
void FinishThunk();
|
|
|
|
|
2014-07-26 09:34:32 +08:00
|
|
|
/// Emit a musttail call for a thunk with a potentially adjusted this pointer.
|
|
|
|
void EmitMustTailThunk(const CXXMethodDecl *MD, llvm::Value *AdjustedThisPtr,
|
|
|
|
llvm::Value *Callee);
|
|
|
|
|
2015-07-13 14:07:58 +08:00
|
|
|
/// Generate a thunk for the given method.
|
|
|
|
void generateThunk(llvm::Function *Fn, const CGFunctionInfo &FnInfo,
|
2011-03-09 12:27:21 +08:00
|
|
|
GlobalDecl GD, const ThunkInfo &Thunk);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2015-07-01 06:08:44 +08:00
|
|
|
llvm::Function *GenerateVarArgsThunk(llvm::Function *Fn,
|
|
|
|
const CGFunctionInfo &FnInfo,
|
|
|
|
GlobalDecl GD, const ThunkInfo &Thunk);
|
2011-05-07 01:27:27 +08:00
|
|
|
|
Reimplement code generation for copying fields in the
implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.
The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.
However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:
struct A { A(const A&); };
struct B {
A array[2][3];
};
then we generate an implicit copy assignment operator for B that looks
something like this:
B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }
CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.
Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.
Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.
llvm-svn: 103079
2010-05-05 13:51:00 +08:00
|
|
|
void EmitCtorPrologue(const CXXConstructorDecl *CD, CXXCtorType Type,
|
|
|
|
FunctionArgList &Args);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2016-12-14 08:03:17 +08:00
|
|
|
void EmitInitializerForField(FieldDecl *Field, LValue LHS, Expr *Init);
|
2012-02-14 10:31:03 +08:00
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
/// Struct with all informations about dynamic [sub]class needed to set vptr.
|
|
|
|
struct VPtr {
|
|
|
|
BaseSubobject Base;
|
|
|
|
const CXXRecordDecl *NearestVBase;
|
|
|
|
CharUnits OffsetFromNearestVBase;
|
|
|
|
const CXXRecordDecl *VTableClass;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Initialize the vtable pointer of the given subobject.
|
|
|
|
void InitializeVTablePointer(const VPtr &vptr);
|
|
|
|
|
|
|
|
typedef llvm::SmallVector<VPtr, 4> VPtrsVector;
|
2010-03-29 03:40:00 +08:00
|
|
|
|
|
|
|
typedef llvm::SmallPtrSet<const CXXRecordDecl *, 4> VisitedVirtualBasesSetTy;
|
2015-09-15 08:37:06 +08:00
|
|
|
VPtrsVector getVTablePointers(const CXXRecordDecl *VTableClass);
|
|
|
|
|
|
|
|
void getVTablePointers(BaseSubobject Base, const CXXRecordDecl *NearestVBase,
|
|
|
|
CharUnits OffsetFromNearestVBase,
|
|
|
|
bool BaseIsNonVirtualPrimaryBase,
|
|
|
|
const CXXRecordDecl *VTableClass,
|
|
|
|
VisitedVirtualBasesSetTy &VBases, VPtrsVector &vptrs);
|
2009-12-08 14:46:18 +08:00
|
|
|
|
2010-03-29 05:07:49 +08:00
|
|
|
void InitializeVTablePointers(const CXXRecordDecl *ClassDecl);
|
2010-03-29 03:40:00 +08:00
|
|
|
|
2010-10-27 02:44:08 +08:00
|
|
|
/// GetVTablePtr - Return the Value of the vtable pointer member pointed
|
|
|
|
/// to by This.
|
2015-09-16 05:46:55 +08:00
|
|
|
llvm::Value *GetVTablePtr(Address This, llvm::Type *VTableTy,
|
|
|
|
const CXXRecordDecl *VTableClass);
|
2010-03-29 03:40:00 +08:00
|
|
|
|
2015-06-19 09:51:54 +08:00
|
|
|
enum CFITypeCheckKind {
|
|
|
|
CFITCK_VCall,
|
|
|
|
CFITCK_NVCall,
|
|
|
|
CFITCK_DerivedCast,
|
|
|
|
CFITCK_UnrelatedCast,
|
2016-01-26 07:34:52 +08:00
|
|
|
CFITCK_ICall,
|
2015-06-19 09:51:54 +08:00
|
|
|
};
|
|
|
|
|
2015-03-14 10:42:25 +08:00
|
|
|
/// \brief Derived is the presumed address of an object of type T after a
|
|
|
|
/// cast. If T is a polymorphic class type, emit a check that the virtual
|
|
|
|
/// table for Derived belongs to a class derived from T.
|
|
|
|
void EmitVTablePtrCheckForCast(QualType T, llvm::Value *Derived,
|
2015-06-19 09:51:54 +08:00
|
|
|
bool MayBeNull, CFITypeCheckKind TCK,
|
|
|
|
SourceLocation Loc);
|
2015-03-14 10:42:25 +08:00
|
|
|
|
2015-02-21 04:30:56 +08:00
|
|
|
/// EmitVTablePtrCheckForCall - Virtual method MD is being called via VTable.
|
|
|
|
/// If vptr CFI is enabled, emit a check that VTable is valid.
|
2016-02-25 04:46:36 +08:00
|
|
|
void EmitVTablePtrCheckForCall(const CXXRecordDecl *RD, llvm::Value *VTable,
|
2015-06-19 09:51:54 +08:00
|
|
|
CFITypeCheckKind TCK, SourceLocation Loc);
|
2013-08-26 06:46:27 +08:00
|
|
|
|
2015-03-14 10:42:25 +08:00
|
|
|
/// EmitVTablePtrCheck - Emit a check that VTable is a valid virtual table for
|
2016-06-25 05:21:46 +08:00
|
|
|
/// RD using llvm.type.test.
|
2015-06-19 09:51:54 +08:00
|
|
|
void EmitVTablePtrCheck(const CXXRecordDecl *RD, llvm::Value *VTable,
|
|
|
|
CFITypeCheckKind TCK, SourceLocation Loc);
|
2015-03-14 10:42:25 +08:00
|
|
|
|
2016-02-25 04:46:36 +08:00
|
|
|
/// If whole-program virtual table optimization is enabled, emit an assumption
|
2016-06-25 05:21:46 +08:00
|
|
|
/// that VTable is a member of RD's type identifier. Or, if vptr CFI is
|
|
|
|
/// enabled, emit a check that VTable is a member of RD's type identifier.
|
|
|
|
void EmitTypeMetadataCodeForVCall(const CXXRecordDecl *RD,
|
|
|
|
llvm::Value *VTable, SourceLocation Loc);
|
2016-02-25 04:46:36 +08:00
|
|
|
|
2016-06-25 08:24:06 +08:00
|
|
|
/// Returns whether we should perform a type checked load when loading a
|
|
|
|
/// virtual function for virtual calls to members of RD. This is generally
|
|
|
|
/// true when both vcall CFI and whole-program-vtables are enabled.
|
|
|
|
bool ShouldEmitVTableTypeCheckedLoad(const CXXRecordDecl *RD);
|
|
|
|
|
|
|
|
/// Emit a type checked load from the given vtable.
|
|
|
|
llvm::Value *EmitVTableTypeCheckedLoad(const CXXRecordDecl *RD, llvm::Value *VTable,
|
|
|
|
uint64_t VTableByteOffset);
|
|
|
|
|
2010-07-21 13:30:47 +08:00
|
|
|
/// EnterDtorCleanups - Enter the cleanups necessary to complete the
|
|
|
|
/// given phase of destruction for a destructor. The end result
|
|
|
|
/// should call destructors on members and base classes in reverse
|
|
|
|
/// order of their construction.
|
|
|
|
void EnterDtorCleanups(const CXXDestructorDecl *Dtor, CXXDtorType Type);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-06-22 08:03:40 +08:00
|
|
|
/// ShouldInstrumentFunction - Return true if the current function should be
|
|
|
|
/// instrumented with __cyg_profile_func_* calls
|
|
|
|
bool ShouldInstrumentFunction();
|
|
|
|
|
2016-07-14 06:32:15 +08:00
|
|
|
/// ShouldXRayInstrument - Return true if the current function should be
|
|
|
|
/// instrumented with XRay nop sleds.
|
|
|
|
bool ShouldXRayInstrumentFunction() const;
|
|
|
|
|
2010-06-22 08:03:40 +08:00
|
|
|
/// EmitFunctionInstrumentation - Emit LLVM code to call the specified
|
|
|
|
/// instrumentation function with the current function and the call site, if
|
|
|
|
/// function instrumentation is enabled.
|
|
|
|
void EmitFunctionInstrumentation(const char *Fn);
|
|
|
|
|
2011-02-11 00:52:03 +08:00
|
|
|
/// EmitMCountInstrumentation - Emit call to .mcount.
|
|
|
|
void EmitMCountInstrumentation();
|
|
|
|
|
2017-09-13 08:04:35 +08:00
|
|
|
/// Encode an address into a form suitable for use in a function prologue.
|
|
|
|
llvm::Constant *EncodeAddrForUseInPrologue(llvm::Function *F,
|
|
|
|
llvm::Constant *Addr);
|
|
|
|
|
|
|
|
/// Decode an address used in a function prologue, encoded by \c
|
|
|
|
/// EncodeAddrForUseInPrologue.
|
|
|
|
llvm::Value *DecodeAddrUsedInPrologue(llvm::Value *F,
|
|
|
|
llvm::Value *EncodedAddr);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitFunctionProlog - Emit the target specific LLVM code to load the
|
|
|
|
/// arguments for the given function. This is also responsible for naming the
|
|
|
|
/// LLVM function arguments.
|
2009-02-03 06:03:45 +08:00
|
|
|
void EmitFunctionProlog(const CGFunctionInfo &FI,
|
|
|
|
llvm::Function *Fn,
|
2008-09-10 07:27:19 +08:00
|
|
|
const FunctionArgList &Args);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitFunctionEpilog - Emit the target specific LLVM code to return the
|
|
|
|
/// given temporary.
|
2013-10-02 10:29:49 +08:00
|
|
|
void EmitFunctionEpilog(const CGFunctionInfo &FI, bool EmitRetDbgLoc,
|
|
|
|
SourceLocation EndLoc);
|
2008-09-10 07:27:19 +08:00
|
|
|
|
2017-03-14 09:56:34 +08:00
|
|
|
/// Emit a test that checks if the return value \p RV is nonnull.
|
2017-06-24 05:32:38 +08:00
|
|
|
void EmitReturnValueCheck(llvm::Value *RV);
|
2017-03-14 09:56:34 +08:00
|
|
|
|
2009-12-08 07:38:24 +08:00
|
|
|
/// EmitStartEHSpec - Emit the start of the exception spec.
|
|
|
|
void EmitStartEHSpec(const Decl *D);
|
|
|
|
|
|
|
|
/// EmitEndEHSpec - Emit the end of the exception spec.
|
|
|
|
void EmitEndEHSpec(const Decl *D);
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
/// getTerminateLandingPad - Return a landing pad that just calls terminate.
|
|
|
|
llvm::BasicBlock *getTerminateLandingPad();
|
|
|
|
|
|
|
|
/// getTerminateHandler - Return a handler (not a landing pad, just
|
|
|
|
/// a catch handler) that just calls terminate. This is used when
|
|
|
|
/// a terminate scope encloses a try.
|
2009-12-10 06:59:31 +08:00
|
|
|
llvm::BasicBlock *getTerminateHandler();
|
|
|
|
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::Type *ConvertTypeForMem(QualType T);
|
|
|
|
llvm::Type *ConvertType(QualType T);
|
|
|
|
llvm::Type *ConvertType(const TypeDecl *T) {
|
2010-02-16 12:15:37 +08:00
|
|
|
return ConvertType(getContext().getTypeDeclType(T));
|
|
|
|
}
|
2008-04-04 12:07:35 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// LoadObjCSelf - Load the value of self. This function is only valid while
|
|
|
|
/// generating code for an Objective-C method.
|
2008-04-04 12:07:35 +08:00
|
|
|
llvm::Value *LoadObjCSelf();
|
2009-02-09 07:14:22 +08:00
|
|
|
|
|
|
|
/// TypeOfSelfObject - Return type of object that this self represents.
|
2009-02-03 08:09:52 +08:00
|
|
|
QualType TypeOfSelfObject();
|
2008-06-18 02:05:57 +08:00
|
|
|
|
2017-09-08 21:44:51 +08:00
|
|
|
/// getEvaluationKind - Return the TypeEvaluationKind of QualType \c T.
|
2013-03-08 05:37:08 +08:00
|
|
|
static TypeEvaluationKind getEvaluationKind(QualType T);
|
|
|
|
|
|
|
|
static bool hasScalarEvaluationKind(QualType T) {
|
|
|
|
return getEvaluationKind(T) == TEK_Scalar;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool hasAggregateEvaluationKind(QualType T) {
|
|
|
|
return getEvaluationKind(T) == TEK_Aggregate;
|
|
|
|
}
|
2008-11-11 10:29:29 +08:00
|
|
|
|
|
|
|
/// createBasicBlock - Create an LLVM basic block.
|
2012-10-10 03:52:38 +08:00
|
|
|
llvm::BasicBlock *createBasicBlock(const Twine &name = "",
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Function *parent = nullptr,
|
|
|
|
llvm::BasicBlock *before = nullptr) {
|
2008-11-12 08:01:12 +08:00
|
|
|
#ifdef NDEBUG
|
2011-02-08 16:22:06 +08:00
|
|
|
return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
|
2008-11-12 08:01:12 +08:00
|
|
|
#else
|
2011-02-08 16:22:06 +08:00
|
|
|
return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
|
2008-11-12 08:01:12 +08:00
|
|
|
#endif
|
2008-11-11 10:29:29 +08:00
|
|
|
}
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2007-05-30 08:13:02 +08:00
|
|
|
/// getBasicBlockForLabel - Return the LLVM basicblock that the specified
|
|
|
|
/// label maps to.
|
2011-02-17 15:39:24 +08:00
|
|
|
JumpDest getJumpDestForLabel(const LabelDecl *S);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2009-12-01 04:08:49 +08:00
|
|
|
/// SimplifyForwardingBlocks - If the given basic block is only a branch to
|
|
|
|
/// another basic block, simplify it. This assumes that no other code could
|
|
|
|
/// potentially reference the basic block.
|
2009-04-01 12:37:47 +08:00
|
|
|
void SimplifyForwardingBlocks(llvm::BasicBlock *BB);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitBlock - Emit the given block \arg BB and set it as the insert point,
|
|
|
|
/// adding a fall-through branch from the current insert block if
|
|
|
|
/// necessary. It is legal to call this function even if there is no current
|
|
|
|
/// insertion point.
|
2008-11-13 09:24:05 +08:00
|
|
|
///
|
2009-02-09 07:14:22 +08:00
|
|
|
/// IsFinished - If true, indicates that the caller has finished emitting
|
|
|
|
/// branches to the given block and does not expect to emit code into it. This
|
|
|
|
/// means the block can be ignored if it is unreachable.
|
2008-11-13 09:24:05 +08:00
|
|
|
void EmitBlock(llvm::BasicBlock *BB, bool IsFinished=false);
|
2008-11-11 12:34:23 +08:00
|
|
|
|
2011-08-11 10:22:43 +08:00
|
|
|
/// EmitBlockAfterUses - Emit the given block somewhere hopefully
|
|
|
|
/// near its uses, and leave the insertion point in it.
|
|
|
|
void EmitBlockAfterUses(llvm::BasicBlock *BB);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitBranch - Emit a branch to the specified basic block from the current
|
|
|
|
/// insert block, taking care to avoid creation of branches from dummy
|
|
|
|
/// blocks. It is legal to call this function even if there is no current
|
|
|
|
/// insertion point.
|
2008-11-12 06:06:59 +08:00
|
|
|
///
|
2009-02-09 07:14:22 +08:00
|
|
|
/// This function clears the current insertion point. The caller should follow
|
|
|
|
/// calls to this function with calls to Emit*Block prior to generation new
|
|
|
|
/// code.
|
2008-11-11 17:41:28 +08:00
|
|
|
void EmitBranch(llvm::BasicBlock *Block);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// HaveInsertPoint - True if an insertion point is defined. If not, this
|
|
|
|
/// indicates that the current code being emitted is unreachable.
|
|
|
|
bool HaveInsertPoint() const {
|
2014-05-21 13:09:00 +08:00
|
|
|
return Builder.GetInsertBlock() != nullptr;
|
2008-11-12 07:11:34 +08:00
|
|
|
}
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EnsureInsertPoint - Ensure that an insertion point is defined so that
|
|
|
|
/// emitted IR has a place to go. Note that by definition, if this function
|
|
|
|
/// creates a block then that block is unreachable; callers may do better to
|
|
|
|
/// detect when no insertion point is defined and simply skip IR generation.
|
2008-11-12 07:11:34 +08:00
|
|
|
void EnsureInsertPoint() {
|
|
|
|
if (!HaveInsertPoint())
|
|
|
|
EmitBlock(createBasicBlock());
|
|
|
|
}
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2008-08-16 08:56:44 +08:00
|
|
|
/// ErrorUnsupported - Print out an error that codegen doesn't support the
|
2007-12-02 09:43:38 +08:00
|
|
|
/// specified stmt yet.
|
2013-08-20 05:02:26 +08:00
|
|
|
void ErrorUnsupported(const Stmt *S, const char *Type);
|
2007-06-02 12:16:21 +08:00
|
|
|
|
2007-06-23 05:44:33 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Helpers
|
|
|
|
//===--------------------------------------------------------------------===//
|
2009-02-09 07:14:22 +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
|
|
|
LValue MakeAddrLValue(Address Addr, QualType T,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo =
|
|
|
|
LValueBaseInfo(AlignmentSource::Type)) {
|
|
|
|
return LValue::MakeAddr(Addr, T, getContext(), BaseInfo,
|
2017-10-05 19:05:43 +08:00
|
|
|
CGM.getTBAATypeInfo(T));
|
2011-11-16 08:42:57 +08:00
|
|
|
}
|
2012-07-03 07:58:38 +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
|
|
|
LValue MakeAddrLValue(llvm::Value *V, QualType T, CharUnits Alignment,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo =
|
|
|
|
LValueBaseInfo(AlignmentSource::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 LValue::MakeAddr(Address(V, Alignment), T, getContext(),
|
2017-10-05 19:05:43 +08:00
|
|
|
BaseInfo, CGM.getTBAATypeInfo(T));
|
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 MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T);
|
2014-09-19 06:05:54 +08:00
|
|
|
LValue MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T);
|
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 getNaturalTypeAlignment(QualType T,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr,
|
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 forPointeeType = false);
|
|
|
|
CharUnits getNaturalPointeeTypeAlignment(QualType T,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
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 EmitLoadOfReference(Address Ref, const ReferenceType *RefTy,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
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 EmitLoadOfReferenceLValue(Address Ref, const ReferenceType *RefTy);
|
2010-08-21 10:53:44 +08:00
|
|
|
|
2016-02-04 19:27:03 +08:00
|
|
|
Address EmitLoadOfPointer(Address Ptr, const PointerType *PtrTy,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
2016-02-04 19:27:03 +08:00
|
|
|
LValue EmitLoadOfPointerLValue(Address Ptr, const PointerType *PtrTy);
|
|
|
|
|
2017-06-20 01:03:41 +08:00
|
|
|
/// CreateTempAlloca - This creates an alloca and inserts it into the entry
|
|
|
|
/// block if \p ArraySize is nullptr, otherwise inserts it at the current
|
|
|
|
/// insertion point of the builder. The caller is responsible for setting an
|
|
|
|
/// appropriate alignment on
|
2010-02-09 10:48:28 +08:00
|
|
|
/// the alloca.
|
2017-06-20 01:03:41 +08:00
|
|
|
///
|
|
|
|
/// \p ArraySize is the number of array elements to be allocated if it
|
|
|
|
/// is not nullptr.
|
|
|
|
///
|
|
|
|
/// LangAS::Default is the address space of pointers to local variables and
|
|
|
|
/// temporaries, as exposed in the source language. In certain
|
|
|
|
/// configurations, this is not the same as the alloca address space, and a
|
|
|
|
/// cast is needed to lift the pointer from the alloca AS into
|
|
|
|
/// LangAS::Default. This can happen when the target uses a restricted
|
|
|
|
/// address space for the stack but the source language requires
|
|
|
|
/// LangAS::Default to be a generic address space. The latter condition is
|
|
|
|
/// common for most programming languages; OpenCL is an exception in that
|
|
|
|
/// LangAS::Default is the private address space, which naturally maps
|
|
|
|
/// to the stack.
|
|
|
|
///
|
|
|
|
/// Because the address of a temporary is often exposed to the program in
|
|
|
|
/// various ways, this function will perform the cast by default. The cast
|
|
|
|
/// may be avoided by passing false as \p CastToDefaultAddrSpace; this is
|
|
|
|
/// more efficient if the caller knows that the address will not be exposed.
|
|
|
|
llvm::AllocaInst *CreateTempAlloca(llvm::Type *Ty, const Twine &Name = "tmp",
|
|
|
|
llvm::Value *ArraySize = nullptr);
|
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 CreateTempAlloca(llvm::Type *Ty, CharUnits align,
|
2017-06-20 01:03:41 +08:00
|
|
|
const Twine &Name = "tmp",
|
|
|
|
llvm::Value *ArraySize = nullptr,
|
|
|
|
bool CastToDefaultAddrSpace = true);
|
2009-02-09 07:14:22 +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
|
|
|
/// CreateDefaultAlignedTempAlloca - This creates an alloca with the
|
|
|
|
/// default ABI alignment of the given LLVM type.
|
|
|
|
///
|
|
|
|
/// IMPORTANT NOTE: This is *not* generally the right alignment for
|
|
|
|
/// any given AST type that happens to have been lowered to the
|
|
|
|
/// given IR type. This should only ever be used for function-local,
|
|
|
|
/// IR-driven manipulations like saving and restoring a value. Do
|
|
|
|
/// not hand this address off to arbitrary IRGen routines, and especially
|
|
|
|
/// do not pass it as an argument to a function that might expect a
|
|
|
|
/// properly ABI-aligned value.
|
|
|
|
Address CreateDefaultAlignTempAlloca(llvm::Type *Ty,
|
|
|
|
const Twine &Name = "tmp");
|
|
|
|
|
|
|
|
/// InitTempAlloca - Provide an initial value for the given alloca which
|
|
|
|
/// will be observable at all locations in the function.
|
|
|
|
///
|
|
|
|
/// The address should be something that was returned from one of
|
|
|
|
/// the CreateTempAlloca or CreateMemTemp routines, and the
|
|
|
|
/// initializer must be valid in the entry block (i.e. it must
|
|
|
|
/// either be a constant or an argument value).
|
|
|
|
void InitTempAlloca(Address Alloca, llvm::Value *Value);
|
2010-04-22 09:10:34 +08:00
|
|
|
|
2010-02-17 03:44:13 +08:00
|
|
|
/// CreateIRTemp - Create a temporary IR object of the given type, with
|
|
|
|
/// appropriate alignment. This routine should only be used when an temporary
|
|
|
|
/// value needs to be stored into an alloca (for example, to avoid explicit
|
|
|
|
/// PHI construction), but the type is the IR type, not the type appropriate
|
|
|
|
/// for storing in memory.
|
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
|
|
|
///
|
|
|
|
/// That is, this is exactly equivalent to CreateMemTemp, but calling
|
|
|
|
/// ConvertType instead of ConvertTypeForMem.
|
|
|
|
Address CreateIRTemp(QualType T, const Twine &Name = "tmp");
|
2010-02-17 03:44:13 +08:00
|
|
|
|
2010-02-09 10:48:28 +08:00
|
|
|
/// CreateMemTemp - Create a temporary memory object of the given type, with
|
2017-06-20 01:03:41 +08:00
|
|
|
/// appropriate alignment. Cast it to the default address space if
|
|
|
|
/// \p CastToDefaultAddrSpace is true.
|
|
|
|
Address CreateMemTemp(QualType T, const Twine &Name = "tmp",
|
|
|
|
bool CastToDefaultAddrSpace = true);
|
|
|
|
Address CreateMemTemp(QualType T, CharUnits Align, const Twine &Name = "tmp",
|
|
|
|
bool CastToDefaultAddrSpace = true);
|
2010-02-09 10:48:28 +08:00
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
/// CreateAggTemp - Create a temporary memory object for the given
|
|
|
|
/// aggregate type.
|
2011-07-20 15:06:53 +08:00
|
|
|
AggValueSlot CreateAggTemp(QualType T, const Twine &Name = "tmp") {
|
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 AggValueSlot::forAddr(CreateMemTemp(T, Name),
|
2011-12-03 08:54:26 +08:00
|
|
|
T.getQualifiers(),
|
2011-08-26 04:40:09 +08:00
|
|
|
AggValueSlot::IsNotDestructed,
|
2011-08-26 07:04:34 +08:00
|
|
|
AggValueSlot::DoesNotNeedGCBarriers,
|
2012-03-30 01:37:10 +08:00
|
|
|
AggValueSlot::IsNotAliased);
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
2011-02-08 16:22:06 +08:00
|
|
|
/// Emit a cast to void* in the appropriate address space.
|
|
|
|
llvm::Value *EmitCastToVoidPtr(llvm::Value *value);
|
|
|
|
|
2007-06-06 04:53:16 +08:00
|
|
|
/// EvaluateExprAsBool - Perform the usual unary conversions on the specified
|
|
|
|
/// expression and compare the result against zero, returning an Int1Ty value.
|
2007-06-16 07:05:46 +08:00
|
|
|
llvm::Value *EvaluateExprAsBool(const Expr *E);
|
2007-06-23 05:44:33 +08:00
|
|
|
|
2010-12-05 10:00:02 +08:00
|
|
|
/// EmitIgnoredExpr - Emit an expression in a context which ignores the result.
|
|
|
|
void EmitIgnoredExpr(const Expr *E);
|
|
|
|
|
2007-09-01 06:49:20 +08:00
|
|
|
/// EmitAnyExpr - Emit code to compute the specified expression which can have
|
|
|
|
/// any type. The result is returned as an RValue struct. If this is an
|
|
|
|
/// aggregate expression, the aggloc/agglocvolatile arguments indicate where
|
|
|
|
/// the result should be returned.
|
2009-05-27 06:03:21 +08:00
|
|
|
///
|
2012-08-24 01:58:28 +08:00
|
|
|
/// \param ignoreResult True if the resulting value isn't used.
|
2010-09-15 18:14:12 +08:00
|
|
|
RValue EmitAnyExpr(const Expr *E,
|
2012-07-03 07:58:38 +08:00
|
|
|
AggValueSlot aggSlot = AggValueSlot::ignored(),
|
|
|
|
bool ignoreResult = false);
|
2007-09-29 05:49:18 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
// EmitVAListRef - Emit a "reference" to a va_list; this is either the address
|
|
|
|
// or the value of the expression, depending on how va_list is defined.
|
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 EmitVAListRef(const Expr *E);
|
2009-01-21 01:46:04 +08:00
|
|
|
|
2015-09-18 04:55:33 +08:00
|
|
|
/// Emit a "reference" to a __builtin_ms_va_list; this is
|
|
|
|
/// always the value of the expression, because a __builtin_ms_va_list is a
|
|
|
|
/// pointer to a char.
|
|
|
|
Address EmitMSVAListRef(const Expr *E);
|
|
|
|
|
2017-03-26 10:18:05 +08:00
|
|
|
/// EmitAnyExprToTemp - Similarly to EmitAnyExpr(), however, the result will
|
2009-02-09 07:14:22 +08:00
|
|
|
/// always be accessible even if no aggregate location is provided.
|
2010-09-15 18:14:12 +08:00
|
|
|
RValue EmitAnyExprToTemp(const Expr *E);
|
2008-09-09 09:06:48 +08:00
|
|
|
|
2011-03-08 17:11:50 +08:00
|
|
|
/// EmitAnyExprToMem - Emits the code necessary to evaluate an
|
2012-03-30 01:37:10 +08:00
|
|
|
/// arbitrary expression into the given memory location.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitAnyExprToMem(const Expr *E, Address Location,
|
2012-03-30 01:37:10 +08:00
|
|
|
Qualifiers Quals, bool IsInitializer);
|
2010-04-21 18:05:39 +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
|
|
|
void EmitAnyExprToExn(const Expr *E, Address Addr);
|
2015-03-05 08:46:22 +08:00
|
|
|
|
2011-03-08 17:11:50 +08:00
|
|
|
/// EmitExprAsInit - Emits the code necessary to initialize a
|
|
|
|
/// location in memory with the given initializer.
|
2014-12-09 08:32:22 +08:00
|
|
|
void EmitExprAsInit(const Expr *init, const ValueDecl *D, LValue lvalue,
|
2015-01-14 15:38:27 +08:00
|
|
|
bool capturedByInit);
|
2011-03-08 17:11:50 +08:00
|
|
|
|
2013-01-26 07:57:05 +08:00
|
|
|
/// hasVolatileMember - returns true if aggregate type has a volatile
|
|
|
|
/// member.
|
|
|
|
bool hasVolatileMember(QualType T) {
|
|
|
|
if (const RecordType *RT = T->getAs<RecordType>()) {
|
|
|
|
const RecordDecl *RD = cast<RecordDecl>(RT->getDecl());
|
|
|
|
return RD->hasVolatileMember();
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2013-02-05 17:06:17 +08:00
|
|
|
/// EmitAggregateCopy - Emit an aggregate assignment.
|
2012-09-30 20:43:37 +08:00
|
|
|
///
|
|
|
|
/// The difference to EmitAggregateCopy is that tail padding is not copied.
|
|
|
|
/// This is required for correctness when assigning non-POD structures in C++.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitAggregateAssign(Address DestPtr, Address SrcPtr,
|
2013-01-26 07:57:05 +08:00
|
|
|
QualType EltTy) {
|
|
|
|
bool IsVolatile = hasVolatileMember(EltTy);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
EmitAggregateCopy(DestPtr, SrcPtr, EltTy, IsVolatile, true);
|
2012-09-30 20:43:37 +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
|
|
|
void EmitAggregateCopyCtor(Address DestPtr, Address SrcPtr,
|
|
|
|
QualType DestTy, QualType SrcTy) {
|
2015-02-04 07:04:06 +08:00
|
|
|
EmitAggregateCopy(DestPtr, SrcPtr, SrcTy, /*IsVolatile=*/false,
|
|
|
|
/*IsAssignment=*/false);
|
|
|
|
}
|
|
|
|
|
2013-02-05 17:06:17 +08:00
|
|
|
/// EmitAggregateCopy - Emit an aggregate copy.
|
2009-05-24 06:29:41 +08:00
|
|
|
///
|
2012-09-27 18:16:10 +08:00
|
|
|
/// \param isVolatile - True iff either the source or the destination is
|
2009-05-24 06:29:41 +08:00
|
|
|
/// volatile.
|
2012-09-30 20:43:37 +08:00
|
|
|
/// \param isAssignment - If false, allow padding to be copied. This often
|
|
|
|
/// yields more efficient.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitAggregateCopy(Address DestPtr, Address SrcPtr,
|
2011-12-06 06:23:28 +08:00
|
|
|
QualType EltTy, bool isVolatile=false,
|
2012-09-30 20:43:37 +08:00
|
|
|
bool isAssignment = false);
|
2008-09-10 04:49:46 +08:00
|
|
|
|
2008-09-11 17:15:33 +08:00
|
|
|
/// GetAddrOfLocalVar - Return the address of a local variable.
|
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 GetAddrOfLocalVar(const VarDecl *VD) {
|
|
|
|
auto it = LocalDeclMap.find(VD);
|
|
|
|
assert(it != LocalDeclMap.end() &&
|
|
|
|
"Invalid argument to GetAddrOfLocalVar(), no decl!");
|
|
|
|
return it->second;
|
2010-08-31 15:33:07 +08:00
|
|
|
}
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
/// getOpaqueLValueMapping - Given an opaque value expression (which
|
|
|
|
/// must be mapped to an l-value), return its mapping.
|
|
|
|
const LValue &getOpaqueLValueMapping(const OpaqueValueExpr *e) {
|
|
|
|
assert(OpaqueValueMapping::shouldBindAsLValue(e));
|
|
|
|
|
|
|
|
llvm::DenseMap<const OpaqueValueExpr*,LValue>::iterator
|
|
|
|
it = OpaqueLValues.find(e);
|
|
|
|
assert(it != OpaqueLValues.end() && "no mapping for opaque value!");
|
|
|
|
return it->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getOpaqueRValueMapping - Given an opaque value expression (which
|
|
|
|
/// must be mapped to an r-value), return its mapping.
|
|
|
|
const RValue &getOpaqueRValueMapping(const OpaqueValueExpr *e) {
|
|
|
|
assert(!OpaqueValueMapping::shouldBindAsLValue(e));
|
|
|
|
|
|
|
|
llvm::DenseMap<const OpaqueValueExpr*,RValue>::iterator
|
|
|
|
it = OpaqueRValues.find(e);
|
|
|
|
assert(it != OpaqueRValues.end() && "no mapping for opaque value!");
|
2011-02-16 16:02:54 +08:00
|
|
|
return it->second;
|
|
|
|
}
|
|
|
|
|
2016-12-12 10:53:20 +08:00
|
|
|
/// Get the index of the current ArrayInitLoopExpr, if any.
|
|
|
|
llvm::Value *getArrayInitIndex() { return ArrayInitIndex; }
|
|
|
|
|
2008-05-22 08:50:06 +08:00
|
|
|
/// getAccessedFieldNo - Given an encoded value and a result number, return
|
|
|
|
/// the input field number being accessed.
|
|
|
|
static unsigned getAccessedFieldNo(unsigned Idx, const llvm::Constant *Elts);
|
|
|
|
|
2011-02-17 15:39:24 +08:00
|
|
|
llvm::BlockAddress *GetAddrOfLabel(const LabelDecl *L);
|
2009-10-13 14:55:33 +08:00
|
|
|
llvm::BasicBlock *GetIndirectGotoBlock();
|
2008-08-05 00:51:22 +08:00
|
|
|
|
2017-04-15 06:03:34 +08:00
|
|
|
/// Check if \p E is a C++ "this" pointer wrapped in value-preserving casts.
|
|
|
|
static bool IsWrappedCXXThis(const Expr *E);
|
Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
I also compiled X86FastISel.cpp with -fsanitize=null using
patched/unpatched clangs based on r293572. Here are the number of null
checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit:
- Don't introduce any unintentional object-size or alignment checks.
- Don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295515
2017-02-18 07:22:59 +08:00
|
|
|
|
2010-05-23 01:35:42 +08:00
|
|
|
/// EmitNullInitialization - Generate code to set a value of the given type to
|
|
|
|
/// null, If the type contains data member pointers, they will be initialized
|
|
|
|
/// to -1 in accordance with the Itanium C++ ABI.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitNullInitialization(Address DestPtr, QualType Ty);
|
2008-11-04 13:30:00 +08:00
|
|
|
|
2015-09-18 04:55:33 +08:00
|
|
|
/// Emits a call to an LLVM variable-argument intrinsic, either
|
|
|
|
/// \c llvm.va_start or \c llvm.va_end.
|
|
|
|
/// \param ArgValue A reference to the \c va_list as emitted by either
|
|
|
|
/// \c EmitVAListRef or \c EmitMSVAListRef.
|
|
|
|
/// \param IsStart If \c true, emits a call to \c llvm.va_start; otherwise,
|
|
|
|
/// calls \c llvm.va_end.
|
|
|
|
llvm::Value *EmitVAStartEnd(llvm::Value *ArgValue, bool IsStart);
|
|
|
|
|
|
|
|
/// Generate code to get an argument from the passed in pointer
|
|
|
|
/// and update it accordingly.
|
|
|
|
/// \param VE The \c VAArgExpr for which to generate code.
|
|
|
|
/// \param VAListAddr Receives a reference to the \c va_list as emitted by
|
|
|
|
/// either \c EmitVAListRef or \c EmitMSVAListRef.
|
|
|
|
/// \returns A pointer to the argument.
|
2008-11-04 13:30:00 +08:00
|
|
|
// FIXME: We should be able to get rid of this method and use the va_arg
|
2009-02-09 07:14:22 +08:00
|
|
|
// instruction in LLVM instead once it works well enough.
|
2015-09-18 04:55:33 +08:00
|
|
|
Address EmitVAArg(VAArgExpr *VE, Address &VAListAddr);
|
2008-12-21 04:27:15 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
/// emitArrayLength - Compute the length of an array, even if it's a
|
|
|
|
/// VLA, and drill down to the base element type.
|
|
|
|
llvm::Value *emitArrayLength(const ArrayType *arrayType,
|
|
|
|
QualType &baseType,
|
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 &addr);
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
/// EmitVLASize - Capture all the sizes for the VLA expressions in
|
|
|
|
/// the given variably-modified type and store them in the VLASizeMap.
|
2009-07-19 14:58:07 +08:00
|
|
|
///
|
|
|
|
/// This function can be called with a null (unreachable) insert point.
|
2011-06-25 05:55:10 +08:00
|
|
|
void EmitVariablyModifiedType(QualType Ty);
|
|
|
|
|
|
|
|
/// getVLASize - Returns an LLVM value that corresponds to the size,
|
|
|
|
/// in non-variably-sized elements, of a variable length array type,
|
|
|
|
/// plus that largest non-variably-sized element type. Assumes that
|
|
|
|
/// the type has already been emitted with EmitVariablyModifiedType.
|
|
|
|
std::pair<llvm::Value*,QualType> getVLASize(const VariableArrayType *vla);
|
|
|
|
std::pair<llvm::Value*,QualType> getVLASize(QualType vla);
|
2008-12-12 15:19:02 +08:00
|
|
|
|
2009-04-15 00:58:56 +08:00
|
|
|
/// LoadCXXThis - Load the value of 'this'. This function is only valid while
|
|
|
|
/// generating code for an C++ member function.
|
2010-02-17 06:04:33 +08:00
|
|
|
llvm::Value *LoadCXXThis() {
|
|
|
|
assert(CXXThisValue && "no 'this' value for this function");
|
|
|
|
return CXXThisValue;
|
|
|
|
}
|
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 LoadCXXThisAddress();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-01-02 09:01:18 +08:00
|
|
|
/// LoadCXXVTT - Load the VTT parameter to base constructors/destructors have
|
|
|
|
/// virtual bases.
|
2013-02-13 16:37:51 +08:00
|
|
|
// FIXME: Every place that calls LoadCXXVTT is something
|
|
|
|
// that needs to be abstracted properly.
|
2010-02-17 06:04:33 +08:00
|
|
|
llvm::Value *LoadCXXVTT() {
|
2013-02-13 16:37:51 +08:00
|
|
|
assert(CXXStructorImplicitParamValue && "no VTT value for this function");
|
|
|
|
return CXXStructorImplicitParamValue;
|
|
|
|
}
|
|
|
|
|
2010-02-16 12:15:37 +08:00
|
|
|
/// GetAddressOfBaseOfCompleteClass - Convert the given pointer to a
|
2010-04-25 07:01:49 +08:00
|
|
|
/// complete class to the given direct base.
|
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
|
|
|
|
GetAddressOfDirectBaseInCompleteClass(Address Value,
|
2010-04-25 07:01:49 +08:00
|
|
|
const CXXRecordDecl *Derived,
|
|
|
|
const CXXRecordDecl *Base,
|
|
|
|
bool BaseIsVirtual);
|
2010-04-25 05:51:08 +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
|
|
|
static bool ShouldNullCheckClassCastValue(const CastExpr *Cast);
|
|
|
|
|
2009-12-01 04:08:49 +08:00
|
|
|
/// GetAddressOfBaseClass - This function will add the necessary delta to the
|
|
|
|
/// load of 'this' and returns address of the base class.
|
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 GetAddressOfBaseClass(Address Value,
|
|
|
|
const CXXRecordDecl *Derived,
|
|
|
|
CastExpr::path_const_iterator PathBegin,
|
|
|
|
CastExpr::path_const_iterator PathEnd,
|
|
|
|
bool NullCheckValue, SourceLocation Loc);
|
|
|
|
|
|
|
|
Address GetAddressOfDerivedClass(Address Value,
|
|
|
|
const CXXRecordDecl *Derived,
|
|
|
|
CastExpr::path_const_iterator PathBegin,
|
|
|
|
CastExpr::path_const_iterator PathEnd,
|
|
|
|
bool NullCheckValue);
|
2009-11-24 01:57:54 +08:00
|
|
|
|
2013-02-27 21:46:31 +08:00
|
|
|
/// GetVTTParameter - Return the VTT parameter that should be passed to a
|
|
|
|
/// base constructor/destructor with virtual bases.
|
|
|
|
/// FIXME: VTTs are Itanium ABI-specific, so the definition should move
|
|
|
|
/// to ItaniumCXXABI.cpp together with all the references to VTT.
|
|
|
|
llvm::Value *GetVTTParameter(GlobalDecl GD, bool ForVirtualBase,
|
|
|
|
bool Delegating);
|
|
|
|
|
2010-02-23 08:48:20 +08:00
|
|
|
void EmitDelegateCXXConstructorCall(const CXXConstructorDecl *Ctor,
|
|
|
|
CXXCtorType CtorType,
|
2013-10-02 10:29:49 +08:00
|
|
|
const FunctionArgList &Args,
|
|
|
|
SourceLocation Loc);
|
2011-05-01 15:04:31 +08:00
|
|
|
// It's important not to confuse this and the previous function. Delegating
|
|
|
|
// constructors are the C++0x feature. The constructor delegate optimization
|
|
|
|
// is used to reduce duplication in the base and complete consturctors where
|
|
|
|
// they are substantially the same.
|
|
|
|
void EmitDelegatingCXXConstructorCall(const CXXConstructorDecl *Ctor,
|
|
|
|
const FunctionArgList &Args);
|
2015-09-15 08:37:06 +08:00
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
/// Emit a call to an inheriting constructor (that is, one that invokes a
|
|
|
|
/// constructor inherited from a base class) by inlining its definition. This
|
|
|
|
/// is necessary if the ABI does not support forwarding the arguments to the
|
|
|
|
/// base class constructor (because they're variadic or similar).
|
|
|
|
void EmitInlinedInheritingCXXConstructorCall(const CXXConstructorDecl *Ctor,
|
|
|
|
CXXCtorType CtorType,
|
|
|
|
bool ForVirtualBase,
|
|
|
|
bool Delegating,
|
|
|
|
CallArgList &Args);
|
|
|
|
|
|
|
|
/// Emit a call to a constructor inherited from a base class, passing the
|
|
|
|
/// current constructor's arguments along unmodified (without even making
|
|
|
|
/// a copy).
|
|
|
|
void EmitInheritedCXXConstructorCall(const CXXConstructorDecl *D,
|
|
|
|
bool ForVirtualBase, Address This,
|
|
|
|
bool InheritedFromVBase,
|
|
|
|
const CXXInheritedCtorInitExpr *E);
|
|
|
|
|
2010-05-03 07:20:53 +08:00
|
|
|
void EmitCXXConstructorCall(const CXXConstructorDecl *D, CXXCtorType Type,
|
2013-01-31 13:50:40 +08:00
|
|
|
bool ForVirtualBase, bool Delegating,
|
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, const CXXConstructExpr *E);
|
2014-08-22 04:26:47 +08:00
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
void EmitCXXConstructorCall(const CXXConstructorDecl *D, CXXCtorType Type,
|
|
|
|
bool ForVirtualBase, bool Delegating,
|
|
|
|
Address This, CallArgList &Args);
|
|
|
|
|
2015-09-15 08:37:06 +08:00
|
|
|
/// Emit assumption load for all bases. Requires to be be called only on
|
|
|
|
/// most-derived class and not under construction of the object.
|
|
|
|
void EmitVTableAssumptionLoads(const CXXRecordDecl *ClassDecl, Address This);
|
|
|
|
|
|
|
|
/// Emit assumption that vptr load == global vtable.
|
|
|
|
void EmitVTableAssumptionLoad(const VPtr &vptr, Address This);
|
|
|
|
|
2010-11-14 05:53:34 +08:00
|
|
|
void EmitSynthesizedCXXCopyCtorCall(const CXXConstructorDecl *D,
|
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, Address Src,
|
|
|
|
const CXXConstructExpr *E);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-08-20 04:55:16 +08:00
|
|
|
void EmitCXXAggrConstructorCall(const CXXConstructorDecl *D,
|
2016-04-29 17:39:50 +08:00
|
|
|
const ArrayType *ArrayTy,
|
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 ArrayPtr,
|
2014-08-22 04:26:47 +08:00
|
|
|
const CXXConstructExpr *E,
|
2010-07-21 09:10:17 +08:00
|
|
|
bool ZeroInitialization = false);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2009-09-23 10:45:36 +08:00
|
|
|
void EmitCXXAggrConstructorCall(const CXXConstructorDecl *D,
|
|
|
|
llvm::Value *NumElements,
|
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 ArrayPtr,
|
2014-08-22 04:26:47 +08:00
|
|
|
const CXXConstructExpr *E,
|
2010-07-21 09:10:17 +08:00
|
|
|
bool ZeroInitialization = false);
|
2009-04-17 08:06:03 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
static Destroyer destroyCXXObject;
|
|
|
|
|
2009-05-30 05:03:38 +08:00
|
|
|
void EmitCXXDestructorCall(const CXXDestructorDecl *D, CXXDtorType Type,
|
2013-01-31 13:50:40 +08:00
|
|
|
bool ForVirtualBase, bool Delegating,
|
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);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2011-09-15 14:49:18 +08:00
|
|
|
void EmitNewArrayInitializer(const CXXNewExpr *E, QualType 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
|
|
|
llvm::Type *ElementTy, Address NewPtr,
|
2015-04-04 23:12:29 +08:00
|
|
|
llvm::Value *NumElements,
|
2014-06-03 14:58:52 +08:00
|
|
|
llvm::Value *AllocSizeWithoutCookie);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-11-28 06:09:22 +08:00
|
|
|
void EmitCXXTemporary(const CXXTemporary *Temporary, QualType TempType,
|
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);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-04-23 05:38:15 +08:00
|
|
|
llvm::Value *EmitLifetimeStart(uint64_t Size, llvm::Value *Addr);
|
|
|
|
void EmitLifetimeEnd(llvm::Value *Size, llvm::Value *Addr);
|
|
|
|
|
2009-05-31 09:40:14 +08:00
|
|
|
llvm::Value *EmitCXXNewExpr(const CXXNewExpr *E);
|
2009-08-17 05:13:42 +08:00
|
|
|
void EmitCXXDeleteExpr(const CXXDeleteExpr *E);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-11-18 08:57:03 +08:00
|
|
|
void EmitDeleteCall(const FunctionDecl *DeleteFD, llvm::Value *Ptr,
|
2016-10-11 02:54:32 +08:00
|
|
|
QualType DeleteTy, llvm::Value *NumElements = nullptr,
|
|
|
|
CharUnits CookieSize = CharUnits());
|
2009-11-18 08:57:03 +08:00
|
|
|
|
2014-06-04 07:27:44 +08:00
|
|
|
RValue EmitBuiltinNewDeleteCall(const FunctionProtoType *Type,
|
|
|
|
const Expr *Arg, bool IsDelete);
|
|
|
|
|
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 *EmitCXXTypeidExpr(const CXXTypeidExpr *E);
|
|
|
|
llvm::Value *EmitDynamicCast(Address V, const CXXDynamicCastExpr *DCE);
|
|
|
|
Address EmitCXXUuidofExpr(const CXXUuidofExpr *E);
|
2009-11-15 16:09:41 +08:00
|
|
|
|
2012-08-24 08:54:33 +08:00
|
|
|
/// \brief Situations in which we might emit a check for the suitability of a
|
|
|
|
/// pointer or glvalue.
|
2012-09-08 10:08:36 +08:00
|
|
|
enum TypeCheckKind {
|
2012-08-24 08:54:33 +08:00
|
|
|
/// Checking the operand of a load. Must be suitably sized and aligned.
|
2012-09-08 10:08:36 +08:00
|
|
|
TCK_Load,
|
2012-08-24 08:54:33 +08:00
|
|
|
/// Checking the destination of a store. Must be suitably sized and aligned.
|
2012-09-08 10:08:36 +08:00
|
|
|
TCK_Store,
|
2012-08-24 08:54:33 +08:00
|
|
|
/// Checking the bound value in a reference binding. Must be suitably sized
|
|
|
|
/// and aligned, but is not required to refer to an object (until the
|
|
|
|
/// reference is used), per core issue 453.
|
2012-09-08 10:08:36 +08:00
|
|
|
TCK_ReferenceBinding,
|
2012-08-24 08:54:33 +08:00
|
|
|
/// Checking the object expression in a non-static data member access. Must
|
|
|
|
/// be an object within its lifetime.
|
2012-09-08 10:08:36 +08:00
|
|
|
TCK_MemberAccess,
|
2012-08-24 08:54:33 +08:00
|
|
|
/// Checking the 'this' pointer for a call to a non-static member function.
|
|
|
|
/// Must be an object within its lifetime.
|
2012-10-25 10:14:12 +08:00
|
|
|
TCK_MemberCall,
|
|
|
|
/// Checking the 'this' pointer for a constructor call.
|
2013-02-14 05:18:23 +08:00
|
|
|
TCK_ConstructorCall,
|
|
|
|
/// Checking the operand of a static_cast to a derived pointer type. Must be
|
|
|
|
/// null or an object within its lifetime.
|
|
|
|
TCK_DowncastPointer,
|
|
|
|
/// Checking the operand of a static_cast to a derived reference type. Must
|
|
|
|
/// be an object within its lifetime.
|
2014-10-14 07:59:00 +08:00
|
|
|
TCK_DowncastReference,
|
|
|
|
/// Checking the operand of a cast to a base object. Must be suitably sized
|
|
|
|
/// and aligned.
|
|
|
|
TCK_Upcast,
|
|
|
|
/// Checking the operand of a cast to a virtual base object. Must be an
|
|
|
|
/// object within its lifetime.
|
2017-03-15 00:48:29 +08:00
|
|
|
TCK_UpcastToVirtualBase,
|
|
|
|
/// Checking the value assigned to a _Nonnull pointer. Must not be null.
|
|
|
|
TCK_NonnullAssign
|
2012-08-24 08:54:33 +08:00
|
|
|
};
|
|
|
|
|
2017-10-03 09:27:25 +08:00
|
|
|
/// Determine whether the pointer type check \p TCK permits null pointers.
|
|
|
|
static bool isNullPointerAllowed(TypeCheckKind TCK);
|
|
|
|
|
|
|
|
/// Determine whether the pointer type check \p TCK requires a vptr check.
|
|
|
|
static bool isVptrCheckRequired(TypeCheckKind TCK, QualType Ty);
|
|
|
|
|
2014-07-08 07:59:57 +08:00
|
|
|
/// \brief Whether any type-checking sanitizers are enabled. If \c false,
|
|
|
|
/// calls to EmitTypeCheck can be skipped.
|
|
|
|
bool sanitizePerformTypeCheck() const;
|
|
|
|
|
2012-09-08 10:08:36 +08:00
|
|
|
/// \brief Emit a check that \p V is the address of storage of the
|
2012-08-24 08:54:33 +08:00
|
|
|
/// appropriate size and alignment for an object of type \p Type.
|
2012-10-10 03:52:38 +08:00
|
|
|
void EmitTypeCheck(TypeCheckKind TCK, SourceLocation Loc, llvm::Value *V,
|
2014-10-14 07:59:00 +08:00
|
|
|
QualType Type, CharUnits Alignment = CharUnits::Zero(),
|
2017-02-18 07:22:55 +08:00
|
|
|
SanitizerSet SkippedChecks = SanitizerSet());
|
2009-12-16 10:57:00 +08:00
|
|
|
|
2013-02-23 10:53:19 +08:00
|
|
|
/// \brief Emit a check that \p Base points into an array object, which
|
|
|
|
/// we can access at index \p Index. \p Accessed should be \c false if we
|
|
|
|
/// this expression is used as an lvalue, for instance in "&Arr[Idx]".
|
|
|
|
void EmitBoundsCheck(const Expr *E, const Expr *Base, llvm::Value *Index,
|
|
|
|
QualType IndexType, bool Accessed);
|
|
|
|
|
2010-01-10 05:40:03 +08:00
|
|
|
llvm::Value *EmitScalarPrePostIncDec(const UnaryOperator *E, LValue LV,
|
|
|
|
bool isInc, bool isPre);
|
|
|
|
ComplexPairTy EmitComplexPrePostIncDec(const UnaryOperator *E, LValue LV,
|
|
|
|
bool isInc, bool isPre);
|
2014-09-08 06:58:14 +08:00
|
|
|
|
|
|
|
void EmitAlignmentAssumption(llvm::Value *PtrValue, unsigned Alignment,
|
2014-10-16 07:45:08 +08:00
|
|
|
llvm::Value *OffsetValue = nullptr) {
|
|
|
|
Builder.CreateAlignmentAssumption(CGM.getDataLayout(), PtrValue, Alignment,
|
|
|
|
OffsetValue);
|
|
|
|
}
|
2014-09-08 06:58:14 +08:00
|
|
|
|
2016-11-10 22:44:30 +08:00
|
|
|
/// Converts Location to a DebugLoc, if debug information is enabled.
|
|
|
|
llvm::DebugLoc SourceLocToDebugLoc(SourceLocation Location);
|
|
|
|
|
|
|
|
|
2007-06-02 12:16:21 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
2007-06-14 04:44:40 +08:00
|
|
|
// Declaration Emission
|
2007-06-02 12:16:21 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2009-07-19 14:58:07 +08:00
|
|
|
/// EmitDecl - Emit a declaration.
|
|
|
|
///
|
|
|
|
/// This function can be called with a null (unreachable) insert point.
|
2007-06-09 09:20:56 +08:00
|
|
|
void EmitDecl(const Decl &D);
|
2009-07-19 14:58:07 +08:00
|
|
|
|
2010-10-15 12:57:14 +08:00
|
|
|
/// EmitVarDecl - Emit a local variable declaration.
|
2009-07-19 14:58:07 +08:00
|
|
|
///
|
|
|
|
/// This function can be called with a null (unreachable) insert point.
|
2010-10-15 12:57:14 +08:00
|
|
|
void EmitVarDecl(const VarDecl &D);
|
2009-07-19 14:58:07 +08:00
|
|
|
|
2014-12-09 08:32:22 +08:00
|
|
|
void EmitScalarInit(const Expr *init, const ValueDecl *D, LValue lvalue,
|
2015-01-14 15:38:27 +08:00
|
|
|
bool capturedByInit);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
typedef void SpecialInitFn(CodeGenFunction &Init, const VarDecl &D,
|
|
|
|
llvm::Value *Address);
|
|
|
|
|
2014-10-08 22:01:46 +08:00
|
|
|
/// \brief Determine whether the given initializer is trivial in the sense
|
|
|
|
/// that it requires no code to be generated.
|
|
|
|
bool isTrivialInitializer(const Expr *Init);
|
|
|
|
|
2010-10-15 12:57:14 +08:00
|
|
|
/// EmitAutoVarDecl - Emit an auto variable declaration.
|
2009-07-19 14:58:07 +08:00
|
|
|
///
|
|
|
|
/// This function can be called with a null (unreachable) insert point.
|
2011-02-22 14:44:22 +08:00
|
|
|
void EmitAutoVarDecl(const VarDecl &D);
|
|
|
|
|
|
|
|
class AutoVarEmission {
|
|
|
|
friend class CodeGenFunction;
|
|
|
|
|
2011-02-22 15:16:58 +08:00
|
|
|
const VarDecl *Variable;
|
2011-02-22 14:44:22 +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
|
|
|
/// The address of the alloca. Invalid if the variable was emitted
|
2011-02-22 14:44:22 +08:00
|
|
|
/// as a global constant.
|
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 Addr;
|
2011-02-22 14:44:22 +08:00
|
|
|
|
|
|
|
llvm::Value *NRVOFlag;
|
|
|
|
|
|
|
|
/// True if the variable is a __block variable.
|
|
|
|
bool IsByRef;
|
|
|
|
|
|
|
|
/// True if the variable is of aggregate type and has a constant
|
|
|
|
/// initializer.
|
|
|
|
bool IsConstantAggregate;
|
|
|
|
|
2013-03-23 14:43:35 +08:00
|
|
|
/// Non-null if we should use lifetime annotations.
|
|
|
|
llvm::Value *SizeForLifetimeMarkers;
|
|
|
|
|
2011-02-22 15:16:58 +08:00
|
|
|
struct Invalid {};
|
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
|
|
|
AutoVarEmission(Invalid) : Variable(nullptr), Addr(Address::invalid()) {}
|
2011-02-22 15:16:58 +08:00
|
|
|
|
2011-02-22 14:44:22 +08:00
|
|
|
AutoVarEmission(const VarDecl &variable)
|
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
|
|
|
: Variable(&variable), Addr(Address::invalid()), NRVOFlag(nullptr),
|
2013-03-23 14:43:35 +08:00
|
|
|
IsByRef(false), IsConstantAggregate(false),
|
2014-05-21 13:09:00 +08:00
|
|
|
SizeForLifetimeMarkers(nullptr) {}
|
2011-02-22 14:44:22 +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
|
|
|
bool wasEmittedAsGlobal() const { return !Addr.isValid(); }
|
2011-02-22 14:44:22 +08:00
|
|
|
|
|
|
|
public:
|
2011-02-22 15:16:58 +08:00
|
|
|
static AutoVarEmission invalid() { return AutoVarEmission(Invalid()); }
|
2013-03-23 14:43:35 +08:00
|
|
|
|
2014-05-21 13:09:00 +08:00
|
|
|
bool useLifetimeMarkers() const {
|
|
|
|
return SizeForLifetimeMarkers != nullptr;
|
|
|
|
}
|
2013-03-23 14:43:35 +08:00
|
|
|
llvm::Value *getSizeForLifetimeMarkers() const {
|
|
|
|
assert(useLifetimeMarkers());
|
|
|
|
return SizeForLifetimeMarkers;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the raw, allocated address, which is not necessarily
|
|
|
|
/// the address of the object itself.
|
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 getAllocatedAddress() const {
|
|
|
|
return Addr;
|
2013-03-23 14:43:35 +08:00
|
|
|
}
|
2011-02-22 15:16:58 +08:00
|
|
|
|
2011-02-22 14:44:22 +08:00
|
|
|
/// Returns the address of the object within this declaration.
|
|
|
|
/// Note that this does not chase the forwarding pointer for
|
|
|
|
/// __block decls.
|
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 getObjectAddress(CodeGenFunction &CGF) const {
|
|
|
|
if (!IsByRef) return Addr;
|
2011-02-22 14:44:22 +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
|
|
|
return CGF.emitBlockByrefAddress(Addr, Variable, /*forward*/ false);
|
2011-02-22 14:44:22 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
AutoVarEmission EmitAutoVarAlloca(const VarDecl &var);
|
|
|
|
void EmitAutoVarInit(const AutoVarEmission &emission);
|
|
|
|
void EmitAutoVarCleanups(const AutoVarEmission &emission);
|
2011-07-09 09:37:26 +08:00
|
|
|
void emitAutoVarTypeCleanup(const AutoVarEmission &emission,
|
|
|
|
QualType::DestructionKind dtorKind);
|
2009-07-19 14:58:07 +08:00
|
|
|
|
2010-10-15 12:57:14 +08:00
|
|
|
void EmitStaticVarDecl(const VarDecl &D,
|
|
|
|
llvm::GlobalValue::LinkageTypes Linkage);
|
2008-08-16 11:19:19 +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
|
|
|
class ParamValue {
|
|
|
|
llvm::Value *Value;
|
|
|
|
unsigned Alignment;
|
|
|
|
ParamValue(llvm::Value *V, unsigned A) : Value(V), Alignment(A) {}
|
|
|
|
public:
|
|
|
|
static ParamValue forDirect(llvm::Value *value) {
|
|
|
|
return ParamValue(value, 0);
|
|
|
|
}
|
|
|
|
static ParamValue forIndirect(Address addr) {
|
|
|
|
assert(!addr.getAlignment().isZero());
|
|
|
|
return ParamValue(addr.getPointer(), addr.getAlignment().getQuantity());
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isIndirect() const { return Alignment != 0; }
|
|
|
|
llvm::Value *getAnyValue() const { return Value; }
|
|
|
|
|
|
|
|
llvm::Value *getDirectValue() const {
|
|
|
|
assert(!isIndirect());
|
|
|
|
return Value;
|
|
|
|
}
|
|
|
|
|
|
|
|
Address getIndirectAddress() const {
|
|
|
|
assert(isIndirect());
|
|
|
|
return Address(Value, CharUnits::fromQuantity(Alignment));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2008-08-16 11:19:19 +08:00
|
|
|
/// EmitParmDecl - Emit a ParmVarDecl or an ImplicitParamDecl.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitParmDecl(const VarDecl &D, ParamValue Arg, unsigned ArgNo);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-02-17 18:25:35 +08:00
|
|
|
/// protectFromPeepholes - Protect a value that we're intending to
|
|
|
|
/// store to the side, but which will probably be used later, from
|
|
|
|
/// aggressive peepholing optimizations that might delete it.
|
|
|
|
///
|
|
|
|
/// Pass the result to unprotectFromPeepholes to declare that
|
|
|
|
/// protection is no longer required.
|
|
|
|
///
|
|
|
|
/// There's no particular reason why this shouldn't apply to
|
|
|
|
/// l-values, it's just that no existing peepholes work on pointers.
|
|
|
|
PeepholeProtection protectFromPeepholes(RValue rvalue);
|
|
|
|
void unprotectFromPeepholes(PeepholeProtection protection);
|
|
|
|
|
2017-03-31 05:48:55 +08:00
|
|
|
void EmitAlignmentAssumption(llvm::Value *PtrValue, llvm::Value *Alignment,
|
|
|
|
llvm::Value *OffsetValue = nullptr) {
|
|
|
|
Builder.CreateAlignmentAssumption(CGM.getDataLayout(), PtrValue, Alignment,
|
|
|
|
OffsetValue);
|
|
|
|
}
|
|
|
|
|
2007-05-30 07:50:05 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Statement Emission
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitStopPoint - Emit a debug stoppoint if we are emitting debug info.
|
2008-11-12 16:21:33 +08:00
|
|
|
void EmitStopPoint(const Stmt *S);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitStmt - Emit the code for the statement \arg S. It is legal to call
|
|
|
|
/// this function even if there is no current insertion point.
|
|
|
|
///
|
|
|
|
/// This function may clear the current insertion point; callers should use
|
|
|
|
/// EnsureInsertPoint if they wish to subsequently generate code without first
|
|
|
|
/// calling EmitBlock, EmitBranch, or EmitStmt.
|
2017-09-06 16:47:18 +08:00
|
|
|
void EmitStmt(const Stmt *S, ArrayRef<const Attr *> Attrs = None);
|
2008-11-12 07:11:34 +08:00
|
|
|
|
2008-11-12 16:21:33 +08:00
|
|
|
/// EmitSimpleStmt - Try to emit a "simple" statement which does not
|
2009-02-09 07:14:22 +08:00
|
|
|
/// necessarily require an insertion point or debug information; typically
|
|
|
|
/// because the statement amounts to a jump or a container of other
|
|
|
|
/// statements.
|
2008-11-12 16:21:33 +08:00
|
|
|
///
|
|
|
|
/// \return True if the statement was handled.
|
|
|
|
bool EmitSimpleStmt(const Stmt *S);
|
|
|
|
|
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 EmitCompoundStmt(const CompoundStmt &S, bool GetLast = false,
|
|
|
|
AggValueSlot AVS = AggValueSlot::ignored());
|
|
|
|
Address EmitCompoundStmtWithoutScope(const CompoundStmt &S,
|
|
|
|
bool GetLast = false,
|
|
|
|
AggValueSlot AVS =
|
2013-06-11 06:04:49 +08:00
|
|
|
AggValueSlot::ignored());
|
2008-11-12 07:11:34 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitLabel - Emit the block for the given label. It is legal to call this
|
|
|
|
/// function even if there is no current insertion point.
|
2011-02-17 15:39:24 +08:00
|
|
|
void EmitLabel(const LabelDecl *D); // helper for EmitLabelStmt.
|
2008-11-12 07:11:34 +08:00
|
|
|
|
2007-05-30 08:13:02 +08:00
|
|
|
void EmitLabelStmt(const LabelStmt &S);
|
2012-04-14 08:33:13 +08:00
|
|
|
void EmitAttributedStmt(const AttributedStmt &S);
|
2007-05-30 08:13:02 +08:00
|
|
|
void EmitGotoStmt(const GotoStmt &S);
|
2008-08-05 00:51:22 +08:00
|
|
|
void EmitIndirectGotoStmt(const IndirectGotoStmt &S);
|
2007-05-31 05:03:58 +08:00
|
|
|
void EmitIfStmt(const IfStmt &S);
|
2014-06-06 20:40:24 +08:00
|
|
|
|
|
|
|
void EmitWhileStmt(const WhileStmt &S,
|
2014-08-27 14:28:16 +08:00
|
|
|
ArrayRef<const Attr *> Attrs = None);
|
|
|
|
void EmitDoStmt(const DoStmt &S, ArrayRef<const Attr *> Attrs = None);
|
2014-06-06 20:40:24 +08:00
|
|
|
void EmitForStmt(const ForStmt &S,
|
2014-08-27 14:28:16 +08:00
|
|
|
ArrayRef<const Attr *> Attrs = None);
|
2007-06-02 11:19:07 +08:00
|
|
|
void EmitReturnStmt(const ReturnStmt &S);
|
2007-06-09 09:20:56 +08:00
|
|
|
void EmitDeclStmt(const DeclStmt &S);
|
2008-11-12 16:21:33 +08:00
|
|
|
void EmitBreakStmt(const BreakStmt &S);
|
|
|
|
void EmitContinueStmt(const ContinueStmt &S);
|
2007-10-05 07:45:31 +08:00
|
|
|
void EmitSwitchStmt(const SwitchStmt &S);
|
|
|
|
void EmitDefaultStmt(const DefaultStmt &S);
|
|
|
|
void EmitCaseStmt(const CaseStmt &S);
|
2007-10-09 04:57:48 +08:00
|
|
|
void EmitCaseStmtRange(const CaseStmt &S);
|
2012-08-29 02:54:39 +08:00
|
|
|
void EmitAsmStmt(const AsmStmt &S);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2008-08-31 03:51:14 +08:00
|
|
|
void EmitObjCForCollectionStmt(const ObjCForCollectionStmt &S);
|
2008-09-09 18:04:29 +08:00
|
|
|
void EmitObjCAtTryStmt(const ObjCAtTryStmt &S);
|
|
|
|
void EmitObjCAtThrowStmt(const ObjCAtThrowStmt &S);
|
2008-11-16 05:26:17 +08:00
|
|
|
void EmitObjCAtSynchronizedStmt(const ObjCAtSynchronizedStmt &S);
|
2011-06-16 07:02:42 +08:00
|
|
|
void EmitObjCAutoreleasePoolStmt(const ObjCAutoreleasePoolStmt &S);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2016-10-28 00:28:31 +08:00
|
|
|
void EmitCoroutineBody(const CoroutineBodyStmt &S);
|
2017-03-07 05:12:54 +08:00
|
|
|
void EmitCoreturnStmt(const CoreturnStmt &S);
|
2017-03-26 10:18:05 +08:00
|
|
|
RValue EmitCoawaitExpr(const CoawaitExpr &E,
|
|
|
|
AggValueSlot aggSlot = AggValueSlot::ignored(),
|
|
|
|
bool ignoreResult = false);
|
2017-06-16 03:43:36 +08:00
|
|
|
LValue EmitCoawaitLValue(const CoawaitExpr *E);
|
2017-03-26 10:18:05 +08:00
|
|
|
RValue EmitCoyieldExpr(const CoyieldExpr &E,
|
|
|
|
AggValueSlot aggSlot = AggValueSlot::ignored(),
|
|
|
|
bool ignoreResult = false);
|
2017-06-16 03:43:36 +08:00
|
|
|
LValue EmitCoyieldLValue(const CoyieldExpr *E);
|
2016-10-04 06:44:48 +08:00
|
|
|
RValue EmitCoroutineIntrinsic(const CallExpr *E, unsigned int IID);
|
|
|
|
|
2010-07-07 14:56:46 +08:00
|
|
|
void EnterCXXTryStmt(const CXXTryStmt &S, bool IsFnTryBlock = false);
|
|
|
|
void ExitCXXTryStmt(const CXXTryStmt &S, bool IsFnTryBlock = false);
|
2010-02-19 17:25:03 +08:00
|
|
|
|
2009-09-28 02:58:34 +08:00
|
|
|
void EmitCXXTryStmt(const CXXTryStmt &S);
|
2013-09-17 05:46:30 +08:00
|
|
|
void EmitSEHTryStmt(const SEHTryStmt &S);
|
2014-07-07 08:12:30 +08:00
|
|
|
void EmitSEHLeaveStmt(const SEHLeaveStmt &S);
|
2015-04-15 04:59:00 +08:00
|
|
|
void EnterSEHTryStmt(const SEHTryStmt &S);
|
|
|
|
void ExitSEHTryStmt(const SEHTryStmt &S);
|
|
|
|
|
2015-07-07 08:36:30 +08:00
|
|
|
void startOutlinedSEHHelper(CodeGenFunction &ParentCGF, bool IsFilter,
|
2015-04-15 04:59:00 +08:00
|
|
|
const Stmt *OutlinedStmt);
|
Initial support for Win64 SEH IR emission
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
2015-01-22 09:36:17 +08:00
|
|
|
|
|
|
|
llvm::Function *GenerateSEHFilterFunction(CodeGenFunction &ParentCGF,
|
|
|
|
const SEHExceptStmt &Except);
|
|
|
|
|
2015-04-15 04:59:00 +08:00
|
|
|
llvm::Function *GenerateSEHFinallyFunction(CodeGenFunction &ParentCGF,
|
|
|
|
const SEHFinallyStmt &Finally);
|
|
|
|
|
2015-07-07 08:36:30 +08:00
|
|
|
void EmitSEHExceptionCodeSave(CodeGenFunction &ParentCGF,
|
|
|
|
llvm::Value *ParentFP,
|
|
|
|
llvm::Value *EntryEBP);
|
Initial support for Win64 SEH IR emission
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
2015-01-22 09:36:17 +08:00
|
|
|
llvm::Value *EmitSEHExceptionCode();
|
|
|
|
llvm::Value *EmitSEHExceptionInfo();
|
2015-02-05 06:37:07 +08:00
|
|
|
llvm::Value *EmitSEHAbnormalTermination();
|
Initial support for Win64 SEH IR emission
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
2015-01-22 09:36:17 +08:00
|
|
|
|
2015-04-09 06:23:48 +08:00
|
|
|
/// Scan the outlined statement for captures from the parent function. For
|
|
|
|
/// each capture, mark the capture as escaped and emit a call to
|
2015-07-08 06:26:07 +08:00
|
|
|
/// llvm.localrecover. Insert the localrecover result into the LocalDeclMap.
|
2015-06-10 01:49:42 +08:00
|
|
|
void EmitCapturedLocals(CodeGenFunction &ParentCGF, const Stmt *OutlinedStmt,
|
2015-07-07 08:36:30 +08:00
|
|
|
bool IsFilter);
|
|
|
|
|
|
|
|
/// Recovers the address of a local in a parent function. ParentVar is the
|
|
|
|
/// address of the variable used in the immediate parent function. It can
|
2015-07-08 06:26:07 +08:00
|
|
|
/// either be an alloca or a call to llvm.localrecover if there are nested
|
2015-07-07 08:36:30 +08:00
|
|
|
/// outlined functions. ParentFP is the frame pointer of the outermost parent
|
|
|
|
/// frame.
|
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 recoverAddrOfEscapedLocal(CodeGenFunction &ParentCGF,
|
|
|
|
Address ParentVar,
|
|
|
|
llvm::Value *ParentFP);
|
2015-04-09 06:23:48 +08:00
|
|
|
|
2014-06-06 20:40:24 +08:00
|
|
|
void EmitCXXForRangeStmt(const CXXForRangeStmt &S,
|
2014-08-27 14:28:16 +08:00
|
|
|
ArrayRef<const Attr *> Attrs = None);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2016-01-26 20:20:39 +08:00
|
|
|
/// Returns calculated size of the specified type.
|
|
|
|
llvm::Value *getTypeSize(QualType Ty);
|
2014-10-29 20:21:55 +08:00
|
|
|
LValue InitCapturedStruct(const CapturedStmt &S);
|
2013-05-10 03:17:11 +08:00
|
|
|
llvm::Function *EmitCapturedStmt(const CapturedStmt &S, CapturedRegionKind K);
|
2014-06-30 10:55:54 +08:00
|
|
|
llvm::Function *GenerateCapturedStmtFunction(const CapturedStmt &S);
|
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 GenerateCapturedStmtArgument(const CapturedStmt &S);
|
2016-06-17 02:39:34 +08:00
|
|
|
llvm::Function *GenerateOpenMPCapturedStmtFunction(const CapturedStmt &S);
|
2015-09-10 16:12:02 +08:00
|
|
|
void GenerateOpenMPCapturedVars(const CapturedStmt &S,
|
2015-12-03 01:44:43 +08:00
|
|
|
SmallVectorImpl<llvm::Value *> &CapturedVars);
|
2016-01-21 20:35:58 +08:00
|
|
|
void emitOMPSimpleStore(LValue LVal, RValue RVal, QualType RValTy,
|
|
|
|
SourceLocation Loc);
|
2015-04-14 13:11:24 +08:00
|
|
|
/// \brief Perform element by element copying of arrays with type \a
|
|
|
|
/// OriginalType from \a SrcAddr to \a DestAddr using copying procedure
|
|
|
|
/// generated by \a CopyGen.
|
|
|
|
///
|
|
|
|
/// \param DestAddr Address of the destination array.
|
|
|
|
/// \param SrcAddr Address of the source array.
|
|
|
|
/// \param OriginalType Type of destination and source arrays.
|
|
|
|
/// \param CopyGen Copying procedure that copies value of single array element
|
|
|
|
/// to another single array element.
|
|
|
|
void EmitOMPAggregateAssign(
|
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 DestAddr, Address SrcAddr, QualType OriginalType,
|
|
|
|
const llvm::function_ref<void(Address, Address)> &CopyGen);
|
2015-04-14 13:11:24 +08:00
|
|
|
/// \brief Emit proper copying of data from one variable to another.
|
|
|
|
///
|
|
|
|
/// \param OriginalType Original type of the copied variables.
|
|
|
|
/// \param DestAddr Destination address.
|
|
|
|
/// \param SrcAddr Source address.
|
|
|
|
/// \param DestVD Destination variable used in \a CopyExpr (for arrays, has
|
|
|
|
/// type of the base array element).
|
|
|
|
/// \param SrcVD Source variable used in \a CopyExpr (for arrays, has type of
|
|
|
|
/// the base array element).
|
|
|
|
/// \param Copy Actual copygin expression for copying data from \a SrcVD to \a
|
|
|
|
/// DestVD.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitOMPCopy(QualType OriginalType,
|
|
|
|
Address DestAddr, Address SrcAddr,
|
2015-04-14 13:11:24 +08:00
|
|
|
const VarDecl *DestVD, const VarDecl *SrcVD,
|
|
|
|
const Expr *Copy);
|
[OPENMP] Codegen for 'reduction' clause in 'parallel' directive.
Emit a code for reduction clause. Next code should be emitted for reductions:
static kmp_critical_name lock = { 0 };
void reduce_func(void *lhs[<n>], void *rhs[<n>]) {
...
*(Type<i> *)lhs[i] = RedOp<i>(*(Type<i> *)lhs[i], *(Type<i> *)rhs[i]);
...
}
... void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n> - 1]};
switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) {
case 1:
...
<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]);
...
__kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>);
break;
case 2:
...
Atomic(<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]));
...
break;
default:
;
}
Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation.
Differential Revision: http://reviews.llvm.org/D8915
llvm-svn: 234583
2015-04-10 18:43:45 +08:00
|
|
|
/// \brief Emit atomic update code for constructs: \a X = \a X \a BO \a E or
|
|
|
|
/// \a X = \a E \a BO \a E.
|
|
|
|
///
|
|
|
|
/// \param X Value to be updated.
|
|
|
|
/// \param E Update value.
|
|
|
|
/// \param BO Binary operation for update operation.
|
|
|
|
/// \param IsXLHSInRHSPart true if \a X is LHS in RHS part of the update
|
|
|
|
/// expression, false otherwise.
|
|
|
|
/// \param AO Atomic ordering of the generated atomic instructions.
|
|
|
|
/// \param CommonGen Code generator for complex expressions that cannot be
|
|
|
|
/// expressed through atomicrmw instruction.
|
2015-04-23 14:35:10 +08:00
|
|
|
/// \returns <true, OldAtomicValue> if simple 'atomicrmw' instruction was
|
|
|
|
/// generated, <false, RValue::get(nullptr)> otherwise.
|
|
|
|
std::pair<bool, RValue> EmitOMPAtomicSimpleUpdateExpr(
|
[OPENMP] Codegen for 'reduction' clause in 'parallel' directive.
Emit a code for reduction clause. Next code should be emitted for reductions:
static kmp_critical_name lock = { 0 };
void reduce_func(void *lhs[<n>], void *rhs[<n>]) {
...
*(Type<i> *)lhs[i] = RedOp<i>(*(Type<i> *)lhs[i], *(Type<i> *)rhs[i]);
...
}
... void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n> - 1]};
switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) {
case 1:
...
<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]);
...
__kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>);
break;
case 2:
...
Atomic(<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]));
...
break;
default:
;
}
Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation.
Differential Revision: http://reviews.llvm.org/D8915
llvm-svn: 234583
2015-04-10 18:43:45 +08:00
|
|
|
LValue X, RValue E, BinaryOperatorKind BO, bool IsXLHSInRHSPart,
|
|
|
|
llvm::AtomicOrdering AO, SourceLocation Loc,
|
|
|
|
const llvm::function_ref<RValue(RValue)> &CommonGen);
|
2015-04-15 12:52:20 +08:00
|
|
|
bool EmitOMPFirstprivateClause(const OMPExecutableDirective &D,
|
2014-10-10 17:48:26 +08:00
|
|
|
OMPPrivateScope &PrivateScope);
|
2014-10-21 11:16:40 +08:00
|
|
|
void EmitOMPPrivateClause(const OMPExecutableDirective &D,
|
|
|
|
OMPPrivateScope &PrivateScope);
|
2016-07-28 22:23:26 +08:00
|
|
|
void EmitOMPUseDevicePtrClause(
|
|
|
|
const OMPClause &C, OMPPrivateScope &PrivateScope,
|
|
|
|
const llvm::DenseMap<const ValueDecl *, Address> &CaptureDeviceAddrMap);
|
2015-04-16 13:39:01 +08:00
|
|
|
/// \brief Emit code for copyin clause in \a D directive. The next code is
|
|
|
|
/// generated at the start of outlined functions for directives:
|
|
|
|
/// \code
|
|
|
|
/// threadprivate_var1 = master_threadprivate_var1;
|
|
|
|
/// operator=(threadprivate_var2, master_threadprivate_var2);
|
|
|
|
/// ...
|
|
|
|
/// __kmpc_barrier(&loc, global_tid);
|
|
|
|
/// \endcode
|
|
|
|
///
|
|
|
|
/// \param D OpenMP directive possibly with 'copyin' clause(s).
|
|
|
|
/// \returns true if at least one copyin variable is found, false otherwise.
|
|
|
|
bool EmitOMPCopyinClause(const OMPExecutableDirective &D);
|
2015-04-16 12:54:05 +08:00
|
|
|
/// \brief Emit initial code for lastprivate variables. If some variable is
|
|
|
|
/// not also firstprivate, then the default initialization is used. Otherwise
|
|
|
|
/// initialization of this variable is performed by EmitOMPFirstprivateClause
|
|
|
|
/// method.
|
|
|
|
///
|
|
|
|
/// \param D Directive that may have 'lastprivate' directives.
|
|
|
|
/// \param PrivateScope Private scope for capturing lastprivate variables for
|
|
|
|
/// proper codegen in internal captured statement.
|
|
|
|
///
|
|
|
|
/// \returns true if there is at least one lastprivate variable, false
|
|
|
|
/// otherwise.
|
|
|
|
bool EmitOMPLastprivateClauseInit(const OMPExecutableDirective &D,
|
|
|
|
OMPPrivateScope &PrivateScope);
|
|
|
|
/// \brief Emit final copying of lastprivate values to original variables at
|
|
|
|
/// the end of the worksharing or simd directive.
|
|
|
|
///
|
|
|
|
/// \param D Directive that has at least one 'lastprivate' directives.
|
|
|
|
/// \param IsLastIterCond Boolean condition that must be set to 'i1 true' if
|
|
|
|
/// it is the last iteration of the loop code in associated directive, or to
|
2015-06-16 21:14:42 +08:00
|
|
|
/// 'i1 false' otherwise. If this item is nullptr, no final check is required.
|
2015-04-16 12:54:05 +08:00
|
|
|
void EmitOMPLastprivateClauseFinal(const OMPExecutableDirective &D,
|
2016-04-22 11:56:56 +08:00
|
|
|
bool NoFinals,
|
2015-06-16 21:14:42 +08:00
|
|
|
llvm::Value *IsLastIterCond = nullptr);
|
2016-04-22 11:56:56 +08:00
|
|
|
/// Emit initial code for linear clauses.
|
|
|
|
void EmitOMPLinearClause(const OMPLoopDirective &D,
|
|
|
|
CodeGenFunction::OMPPrivateScope &PrivateScope);
|
|
|
|
/// Emit final code for linear clauses.
|
|
|
|
/// \param CondGen Optional conditional code for final part of codegen for
|
|
|
|
/// linear clause.
|
|
|
|
void EmitOMPLinearClauseFinal(
|
|
|
|
const OMPLoopDirective &D,
|
|
|
|
const llvm::function_ref<llvm::Value *(CodeGenFunction &)> &CondGen);
|
[OPENMP] Codegen for 'reduction' clause in 'parallel' directive.
Emit a code for reduction clause. Next code should be emitted for reductions:
static kmp_critical_name lock = { 0 };
void reduce_func(void *lhs[<n>], void *rhs[<n>]) {
...
*(Type<i> *)lhs[i] = RedOp<i>(*(Type<i> *)lhs[i], *(Type<i> *)rhs[i]);
...
}
... void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n> - 1]};
switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) {
case 1:
...
<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]);
...
__kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>);
break;
case 2:
...
Atomic(<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]));
...
break;
default:
;
}
Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation.
Differential Revision: http://reviews.llvm.org/D8915
llvm-svn: 234583
2015-04-10 18:43:45 +08:00
|
|
|
/// \brief Emit initial code for reduction variables. Creates reduction copies
|
|
|
|
/// and initializes them with the values according to OpenMP standard.
|
|
|
|
///
|
|
|
|
/// \param D Directive (possibly) with the 'reduction' clause.
|
|
|
|
/// \param PrivateScope Private scope for capturing reduction variables for
|
|
|
|
/// proper codegen in internal captured statement.
|
|
|
|
///
|
|
|
|
void EmitOMPReductionClauseInit(const OMPExecutableDirective &D,
|
|
|
|
OMPPrivateScope &PrivateScope);
|
|
|
|
/// \brief Emit final update of reduction values to original variables at
|
|
|
|
/// the end of the directive.
|
|
|
|
///
|
|
|
|
/// \param D Directive that has at least one 'reduction' directives.
|
2017-02-17 00:20:16 +08:00
|
|
|
/// \param ReductionKind The kind of reduction to perform.
|
|
|
|
void EmitOMPReductionClauseFinal(const OMPExecutableDirective &D,
|
|
|
|
const OpenMPDirectiveKind ReductionKind);
|
2015-06-18 18:10:12 +08:00
|
|
|
/// \brief Emit initial code for linear variables. Creates private copies
|
|
|
|
/// and initializes them with the values according to OpenMP standard.
|
|
|
|
///
|
|
|
|
/// \param D Directive (possibly) with the 'linear' clause.
|
2017-08-16 23:58:46 +08:00
|
|
|
/// \return true if at least one linear variable is found that should be
|
|
|
|
/// initialized with the value of the original variable, false otherwise.
|
|
|
|
bool EmitOMPLinearClauseInit(const OMPLoopDirective &D);
|
2014-05-06 18:08:46 +08:00
|
|
|
|
[OPENMP 4.5] Codegen for 'taskloop' directive.
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
2016-04-25 20:22:29 +08:00
|
|
|
typedef const llvm::function_ref<void(CodeGenFunction & /*CGF*/,
|
|
|
|
llvm::Value * /*OutlinedFn*/,
|
2016-04-28 17:23:51 +08:00
|
|
|
const OMPTaskDataTy & /*Data*/)>
|
[OPENMP 4.5] Codegen for 'taskloop' directive.
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
2016-04-25 20:22:29 +08:00
|
|
|
TaskGenTy;
|
|
|
|
void EmitOMPTaskBasedDirective(const OMPExecutableDirective &S,
|
|
|
|
const RegionCodeGenTy &BodyGen,
|
2016-04-28 17:23:51 +08:00
|
|
|
const TaskGenTy &TaskGen, OMPTaskDataTy &Data);
|
[OPENMP 4.5] Codegen for 'taskloop' directive.
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
2016-04-25 20:22:29 +08:00
|
|
|
|
2014-05-06 18:08:46 +08:00
|
|
|
void EmitOMPParallelDirective(const OMPParallelDirective &S);
|
2014-05-22 16:54:05 +08:00
|
|
|
void EmitOMPSimdDirective(const OMPSimdDirective &S);
|
2014-06-18 12:14:57 +08:00
|
|
|
void EmitOMPForDirective(const OMPForDirective &S);
|
2014-09-18 13:12:34 +08:00
|
|
|
void EmitOMPForSimdDirective(const OMPForSimdDirective &S);
|
2014-06-25 19:44:49 +08:00
|
|
|
void EmitOMPSectionsDirective(const OMPSectionsDirective &S);
|
2014-06-26 16:21:58 +08:00
|
|
|
void EmitOMPSectionDirective(const OMPSectionDirective &S);
|
2014-06-26 20:05:45 +08:00
|
|
|
void EmitOMPSingleDirective(const OMPSingleDirective &S);
|
2014-07-17 16:54:58 +08:00
|
|
|
void EmitOMPMasterDirective(const OMPMasterDirective &S);
|
2014-07-21 17:42:05 +08:00
|
|
|
void EmitOMPCriticalDirective(const OMPCriticalDirective &S);
|
2014-07-07 21:01:15 +08:00
|
|
|
void EmitOMPParallelForDirective(const OMPParallelForDirective &S);
|
2014-09-23 17:33:00 +08:00
|
|
|
void EmitOMPParallelForSimdDirective(const OMPParallelForSimdDirective &S);
|
2014-07-08 16:12:03 +08:00
|
|
|
void EmitOMPParallelSectionsDirective(const OMPParallelSectionsDirective &S);
|
2014-07-11 19:25:16 +08:00
|
|
|
void EmitOMPTaskDirective(const OMPTaskDirective &S);
|
2014-07-18 15:47:19 +08:00
|
|
|
void EmitOMPTaskyieldDirective(const OMPTaskyieldDirective &S);
|
2014-07-18 17:11:51 +08:00
|
|
|
void EmitOMPBarrierDirective(const OMPBarrierDirective &S);
|
2014-07-18 18:17:07 +08:00
|
|
|
void EmitOMPTaskwaitDirective(const OMPTaskwaitDirective &S);
|
2015-06-18 20:14:09 +08:00
|
|
|
void EmitOMPTaskgroupDirective(const OMPTaskgroupDirective &S);
|
2014-07-21 19:26:11 +08:00
|
|
|
void EmitOMPFlushDirective(const OMPFlushDirective &S);
|
2014-07-22 14:45:04 +08:00
|
|
|
void EmitOMPOrderedDirective(const OMPOrderedDirective &S);
|
2014-07-22 18:10:35 +08:00
|
|
|
void EmitOMPAtomicDirective(const OMPAtomicDirective &S);
|
2014-09-19 16:19:49 +08:00
|
|
|
void EmitOMPTargetDirective(const OMPTargetDirective &S);
|
2015-07-21 21:44:28 +08:00
|
|
|
void EmitOMPTargetDataDirective(const OMPTargetDataDirective &S);
|
2016-01-20 03:15:56 +08:00
|
|
|
void EmitOMPTargetEnterDataDirective(const OMPTargetEnterDataDirective &S);
|
2016-01-20 04:04:50 +08:00
|
|
|
void EmitOMPTargetExitDataDirective(const OMPTargetExitDataDirective &S);
|
2016-05-27 01:30:50 +08:00
|
|
|
void EmitOMPTargetUpdateDirective(const OMPTargetUpdateDirective &S);
|
2016-01-27 02:48:41 +08:00
|
|
|
void EmitOMPTargetParallelDirective(const OMPTargetParallelDirective &S);
|
2016-02-03 23:46:42 +08:00
|
|
|
void
|
|
|
|
EmitOMPTargetParallelForDirective(const OMPTargetParallelForDirective &S);
|
2014-10-09 12:18:56 +08:00
|
|
|
void EmitOMPTeamsDirective(const OMPTeamsDirective &S);
|
2015-07-01 14:57:41 +08:00
|
|
|
void
|
|
|
|
EmitOMPCancellationPointDirective(const OMPCancellationPointDirective &S);
|
2015-07-02 19:25:17 +08:00
|
|
|
void EmitOMPCancelDirective(const OMPCancelDirective &S);
|
[OPENMP 4.5] Codegen for 'taskloop' directive.
The taskloop construct specifies that the iterations of one or more associated loops will be executed in parallel using OpenMP tasks. The iterations are distributed across tasks created by the construct and scheduled to be executed.
The next code will be generated for the taskloop directive:
#pragma omp taskloop num_tasks(N) lastprivate(j)
for( i=0; i<N*GRAIN*STRIDE-1; i+=STRIDE ) {
int th = omp_get_thread_num();
#pragma omp atomic
counter++;
#pragma omp atomic
th_counter[th]++;
j = i;
}
Generated code:
task = __kmpc_omp_task_alloc(NULL,gtid,1,sizeof(struct
task),sizeof(struct shar),&task_entry);
psh = task->shareds;
psh->pth_counter = &th_counter;
psh->pcounter = &counter;
psh->pj = &j;
task->lb = 0;
task->ub = N*GRAIN*STRIDE-2;
task->st = STRIDE;
__kmpc_taskloop(
NULL, // location
gtid, // gtid
task, // task structure
1, // if clause value
&task->lb, // lower bound
&task->ub, // upper bound
STRIDE, // loop increment
0, // 1 if nogroup specified
2, // schedule type: 0-none, 1-grainsize, 2-num_tasks
N, // schedule value (ignored for type 0)
(void*)&__task_dup_entry // tasks duplication routine
);
llvm-svn: 267395
2016-04-25 20:22:29 +08:00
|
|
|
void EmitOMPTaskLoopBasedDirective(const OMPLoopDirective &S);
|
2015-12-01 12:18:41 +08:00
|
|
|
void EmitOMPTaskLoopDirective(const OMPTaskLoopDirective &S);
|
2015-12-03 17:40:15 +08:00
|
|
|
void EmitOMPTaskLoopSimdDirective(const OMPTaskLoopSimdDirective &S);
|
2015-12-14 22:51:25 +08:00
|
|
|
void EmitOMPDistributeDirective(const OMPDistributeDirective &S);
|
2016-06-27 22:55:37 +08:00
|
|
|
void EmitOMPDistributeParallelForDirective(
|
|
|
|
const OMPDistributeParallelForDirective &S);
|
2016-07-05 13:00:15 +08:00
|
|
|
void EmitOMPDistributeParallelForSimdDirective(
|
|
|
|
const OMPDistributeParallelForSimdDirective &S);
|
2016-07-06 12:45:38 +08:00
|
|
|
void EmitOMPDistributeSimdDirective(const OMPDistributeSimdDirective &S);
|
2016-07-14 10:54:56 +08:00
|
|
|
void EmitOMPTargetParallelForSimdDirective(
|
|
|
|
const OMPTargetParallelForSimdDirective &S);
|
2016-07-21 06:57:10 +08:00
|
|
|
void EmitOMPTargetSimdDirective(const OMPTargetSimdDirective &S);
|
2016-08-05 22:37:37 +08:00
|
|
|
void EmitOMPTeamsDistributeDirective(const OMPTeamsDistributeDirective &S);
|
2016-10-25 20:50:55 +08:00
|
|
|
void
|
|
|
|
EmitOMPTeamsDistributeSimdDirective(const OMPTeamsDistributeSimdDirective &S);
|
2016-12-01 07:51:03 +08:00
|
|
|
void EmitOMPTeamsDistributeParallelForSimdDirective(
|
|
|
|
const OMPTeamsDistributeParallelForSimdDirective &S);
|
2016-12-09 11:24:30 +08:00
|
|
|
void EmitOMPTeamsDistributeParallelForDirective(
|
|
|
|
const OMPTeamsDistributeParallelForDirective &S);
|
2016-12-17 13:48:59 +08:00
|
|
|
void EmitOMPTargetTeamsDirective(const OMPTargetTeamsDirective &S);
|
2016-12-25 12:52:54 +08:00
|
|
|
void EmitOMPTargetTeamsDistributeDirective(
|
|
|
|
const OMPTargetTeamsDistributeDirective &S);
|
2016-12-30 06:16:30 +08:00
|
|
|
void EmitOMPTargetTeamsDistributeParallelForDirective(
|
|
|
|
const OMPTargetTeamsDistributeParallelForDirective &S);
|
2017-01-03 13:23:48 +08:00
|
|
|
void EmitOMPTargetTeamsDistributeParallelForSimdDirective(
|
|
|
|
const OMPTargetTeamsDistributeParallelForSimdDirective &S);
|
2017-01-11 02:08:18 +08:00
|
|
|
void EmitOMPTargetTeamsDistributeSimdDirective(
|
|
|
|
const OMPTargetTeamsDistributeSimdDirective &S);
|
2013-05-10 03:17:11 +08:00
|
|
|
|
2017-01-16 23:26:02 +08:00
|
|
|
/// Emit device code for the target directive.
|
|
|
|
static void EmitOMPTargetDeviceFunction(CodeGenModule &CGM,
|
|
|
|
StringRef ParentName,
|
|
|
|
const OMPTargetDirective &S);
|
2017-01-19 02:18:53 +08:00
|
|
|
static void
|
|
|
|
EmitOMPTargetParallelDeviceFunction(CodeGenModule &CGM, StringRef ParentName,
|
|
|
|
const OMPTargetParallelDirective &S);
|
2017-01-25 10:18:43 +08:00
|
|
|
static void
|
|
|
|
EmitOMPTargetTeamsDeviceFunction(CodeGenModule &CGM, StringRef ParentName,
|
|
|
|
const OMPTargetTeamsDirective &S);
|
2015-04-22 19:15:40 +08:00
|
|
|
/// \brief Emit inner loop of the worksharing/simd construct.
|
|
|
|
///
|
|
|
|
/// \param S Directive, for which the inner loop must be emitted.
|
|
|
|
/// \param RequiresCleanup true, if directive has some associated private
|
|
|
|
/// variables.
|
|
|
|
/// \param LoopCond Bollean condition for loop continuation.
|
|
|
|
/// \param IncExpr Increment expression for loop control variable.
|
|
|
|
/// \param BodyGen Generator for the inner body of the inner loop.
|
|
|
|
/// \param PostIncGen Genrator for post-increment code (required for ordered
|
|
|
|
/// loop directvies).
|
|
|
|
void EmitOMPInnerLoop(
|
|
|
|
const Stmt &S, bool RequiresCleanup, const Expr *LoopCond,
|
|
|
|
const Expr *IncExpr,
|
|
|
|
const llvm::function_ref<void(CodeGenFunction &)> &BodyGen,
|
|
|
|
const llvm::function_ref<void(CodeGenFunction &)> &PostIncGen);
|
2015-04-14 11:29:22 +08:00
|
|
|
|
2015-07-03 17:56:58 +08:00
|
|
|
JumpDest getOMPCancelDestination(OpenMPDirectiveKind Kind);
|
2016-04-22 11:56:56 +08:00
|
|
|
/// Emit initial code for loop counters of loop-based directives.
|
|
|
|
void EmitOMPPrivateLoopCounters(const OMPLoopDirective &S,
|
|
|
|
OMPPrivateScope &LoopScope);
|
2015-07-03 17:56:58 +08:00
|
|
|
|
2017-04-26 01:52:12 +08:00
|
|
|
/// Helper for the OpenMP loop directives.
|
|
|
|
void EmitOMPLoopBody(const OMPLoopDirective &D, JumpDest LoopExit);
|
|
|
|
|
|
|
|
/// \brief Emit code for the worksharing loop-based directive.
|
|
|
|
/// \return true, if this construct has any lastprivate clause, false -
|
|
|
|
/// otherwise.
|
|
|
|
bool EmitOMPWorksharingLoop(const OMPLoopDirective &S, Expr *EUB,
|
|
|
|
const CodeGenLoopBoundsTy &CodeGenLoopBounds,
|
|
|
|
const CodeGenDispatchBoundsTy &CGDispatchBounds);
|
|
|
|
|
2017-09-26 21:47:31 +08:00
|
|
|
/// Emits the lvalue for the expression with possibly captured variable.
|
|
|
|
LValue EmitOMPSharedLValue(const Expr *E);
|
|
|
|
|
2014-12-15 15:07:06 +08:00
|
|
|
private:
|
2016-12-22 10:50:20 +08:00
|
|
|
/// Helpers for blocks
|
|
|
|
llvm::Value *EmitBlockLiteral(const CGBlockInfo &Info);
|
|
|
|
|
2014-12-15 15:07:06 +08:00
|
|
|
/// Helpers for the OpenMP loop directives.
|
2015-12-31 14:52:34 +08:00
|
|
|
void EmitOMPSimdInit(const OMPLoopDirective &D, bool IsMonotonic = false);
|
2016-03-09 17:49:09 +08:00
|
|
|
void EmitOMPSimdFinal(
|
|
|
|
const OMPLoopDirective &D,
|
|
|
|
const llvm::function_ref<llvm::Value *(CodeGenFunction &)> &CondGen);
|
2017-04-26 01:52:12 +08:00
|
|
|
|
|
|
|
void EmitOMPDistributeLoop(const OMPLoopDirective &S,
|
|
|
|
const CodeGenLoopTy &CodeGenLoop, Expr *IncExpr);
|
|
|
|
|
|
|
|
/// struct with the values to be passed to the OpenMP loop-related functions
|
|
|
|
struct OMPLoopArguments {
|
|
|
|
/// loop lower bound
|
|
|
|
Address LB = Address::invalid();
|
|
|
|
/// loop upper bound
|
|
|
|
Address UB = Address::invalid();
|
|
|
|
/// loop stride
|
|
|
|
Address ST = Address::invalid();
|
|
|
|
/// isLastIteration argument for runtime functions
|
|
|
|
Address IL = Address::invalid();
|
|
|
|
/// Chunk value generated by sema
|
|
|
|
llvm::Value *Chunk = nullptr;
|
|
|
|
/// EnsureUpperBound
|
|
|
|
Expr *EUB = nullptr;
|
|
|
|
/// IncrementExpression
|
|
|
|
Expr *IncExpr = nullptr;
|
|
|
|
/// Loop initialization
|
|
|
|
Expr *Init = nullptr;
|
|
|
|
/// Loop exit condition
|
|
|
|
Expr *Cond = nullptr;
|
|
|
|
/// Update of LB after a whole chunk has been executed
|
|
|
|
Expr *NextLB = nullptr;
|
|
|
|
/// Update of UB after a whole chunk has been executed
|
|
|
|
Expr *NextUB = nullptr;
|
|
|
|
OMPLoopArguments() = default;
|
|
|
|
OMPLoopArguments(Address LB, Address UB, Address ST, Address IL,
|
|
|
|
llvm::Value *Chunk = nullptr, Expr *EUB = nullptr,
|
|
|
|
Expr *IncExpr = nullptr, Expr *Init = nullptr,
|
|
|
|
Expr *Cond = nullptr, Expr *NextLB = nullptr,
|
|
|
|
Expr *NextUB = nullptr)
|
|
|
|
: LB(LB), UB(UB), ST(ST), IL(IL), Chunk(Chunk), EUB(EUB),
|
|
|
|
IncExpr(IncExpr), Init(Init), Cond(Cond), NextLB(NextLB),
|
|
|
|
NextUB(NextUB) {}
|
|
|
|
};
|
|
|
|
void EmitOMPOuterLoop(bool DynamicOrOrdered, bool IsMonotonic,
|
|
|
|
const OMPLoopDirective &S, OMPPrivateScope &LoopScope,
|
|
|
|
const OMPLoopArguments &LoopArgs,
|
|
|
|
const CodeGenLoopTy &CodeGenLoop,
|
|
|
|
const CodeGenOrderedTy &CodeGenOrdered);
|
2016-05-10 17:57:36 +08:00
|
|
|
void EmitOMPForOuterLoop(const OpenMPScheduleTy &ScheduleKind,
|
2015-12-31 14:52:34 +08:00
|
|
|
bool IsMonotonic, const OMPLoopDirective &S,
|
2017-04-26 01:52:12 +08:00
|
|
|
OMPPrivateScope &LoopScope, bool Ordered,
|
|
|
|
const OMPLoopArguments &LoopArgs,
|
|
|
|
const CodeGenDispatchBoundsTy &CGDispatchBounds);
|
|
|
|
void EmitOMPDistributeOuterLoop(OpenMPDistScheduleClauseKind ScheduleKind,
|
|
|
|
const OMPLoopDirective &S,
|
|
|
|
OMPPrivateScope &LoopScope,
|
|
|
|
const OMPLoopArguments &LoopArgs,
|
|
|
|
const CodeGenLoopTy &CodeGenLoopContent);
|
2015-07-02 12:17:07 +08:00
|
|
|
/// \brief Emit code for sections directive.
|
2016-02-16 19:18:12 +08:00
|
|
|
void EmitSections(const OMPExecutableDirective &S);
|
2014-12-15 15:07:06 +08:00
|
|
|
|
|
|
|
public:
|
2014-10-01 14:03:56 +08:00
|
|
|
|
2007-06-02 13:24:33 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// LValue Expression Emission
|
|
|
|
//===--------------------------------------------------------------------===//
|
2007-06-06 04:53:16 +08:00
|
|
|
|
2009-02-05 15:09:07 +08:00
|
|
|
/// GetUndefRValue - Get an appropriate 'undef' rvalue for the given type.
|
|
|
|
RValue GetUndefRValue(QualType Ty);
|
|
|
|
|
2009-01-10 00:50:52 +08:00
|
|
|
/// EmitUnsupportedRValue - Emit a dummy r-value using the type of E
|
|
|
|
/// and issue an ErrorUnsupported style diagnostic (using the
|
|
|
|
/// provided Name).
|
|
|
|
RValue EmitUnsupportedRValue(const Expr *E,
|
|
|
|
const char *Name);
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitUnsupportedLValue - Emit a dummy l-value using the type of E and issue
|
|
|
|
/// an ErrorUnsupported style diagnostic (using the provided Name).
|
2008-08-26 04:45:57 +08:00
|
|
|
LValue EmitUnsupportedLValue(const Expr *E,
|
|
|
|
const char *Name);
|
|
|
|
|
2007-06-06 04:53:16 +08:00
|
|
|
/// EmitLValue - Emit code to compute a designator that specifies the location
|
|
|
|
/// of the expression.
|
|
|
|
///
|
|
|
|
/// This can return one of two things: a simple address or a bitfield
|
|
|
|
/// reference. In either case, the LLVM Value* in the LValue structure is
|
|
|
|
/// guaranteed to be an LLVM pointer type.
|
|
|
|
///
|
|
|
|
/// If this returns a bitfield reference, nothing about the pointee type of
|
|
|
|
/// the LLVM value is known: For example, it may not be a pointer to an
|
|
|
|
/// integer.
|
|
|
|
///
|
|
|
|
/// If this returns a normal address, and if the lvalue's C type is fixed
|
|
|
|
/// size, this method guarantees that the returned pointer type will point to
|
|
|
|
/// an LLVM type of the same size of the lvalue's type. If the lvalue has a
|
|
|
|
/// variable length type, this is not possible.
|
|
|
|
///
|
2007-06-02 13:24:33 +08:00
|
|
|
LValue EmitLValue(const Expr *E);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2012-09-08 10:08:36 +08:00
|
|
|
/// \brief Same as EmitLValue but additionally we generate checking code to
|
|
|
|
/// guard against undefined behavior. This is only suitable when we know
|
|
|
|
/// that the address will be used to access the object.
|
|
|
|
LValue EmitCheckedLValue(const Expr *E, TypeCheckKind TCK);
|
2009-12-16 10:57:00 +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
|
|
|
RValue convertTempToRValue(Address addr, QualType type,
|
2013-10-02 10:29:49 +08:00
|
|
|
SourceLocation Loc);
|
2013-03-08 05:37:08 +08:00
|
|
|
|
2013-03-08 05:37:17 +08:00
|
|
|
void EmitAtomicInit(Expr *E, LValue lvalue);
|
|
|
|
|
2015-02-14 09:35:12 +08:00
|
|
|
bool LValueIsSuitableForInlineAtomic(LValue Src);
|
|
|
|
|
|
|
|
RValue EmitAtomicLoad(LValue LV, SourceLocation SL,
|
|
|
|
AggValueSlot Slot = AggValueSlot::ignored());
|
|
|
|
|
2013-10-02 10:29:49 +08:00
|
|
|
RValue EmitAtomicLoad(LValue lvalue, SourceLocation loc,
|
2015-02-14 09:35:12 +08:00
|
|
|
llvm::AtomicOrdering AO, bool IsVolatile = false,
|
2013-03-08 05:37:17 +08:00
|
|
|
AggValueSlot slot = AggValueSlot::ignored());
|
|
|
|
|
|
|
|
void EmitAtomicStore(RValue rvalue, LValue lvalue, bool isInit);
|
|
|
|
|
2015-02-14 09:35:12 +08:00
|
|
|
void EmitAtomicStore(RValue rvalue, LValue lvalue, llvm::AtomicOrdering AO,
|
|
|
|
bool IsVolatile, bool isInit);
|
|
|
|
|
2015-03-30 13:20:59 +08:00
|
|
|
std::pair<RValue, llvm::Value *> EmitAtomicCompareExchange(
|
2014-12-15 13:25:25 +08:00
|
|
|
LValue Obj, RValue Expected, RValue Desired, SourceLocation Loc,
|
2016-04-07 01:26:42 +08:00
|
|
|
llvm::AtomicOrdering Success =
|
|
|
|
llvm::AtomicOrdering::SequentiallyConsistent,
|
|
|
|
llvm::AtomicOrdering Failure =
|
|
|
|
llvm::AtomicOrdering::SequentiallyConsistent,
|
2014-12-15 13:25:25 +08:00
|
|
|
bool IsWeak = false, AggValueSlot Slot = AggValueSlot::ignored());
|
|
|
|
|
2015-03-30 13:20:59 +08:00
|
|
|
void EmitAtomicUpdate(LValue LVal, llvm::AtomicOrdering AO,
|
2015-05-15 16:36:34 +08:00
|
|
|
const llvm::function_ref<RValue(RValue)> &UpdateOp,
|
2015-03-30 13:20:59 +08:00
|
|
|
bool IsVolatile);
|
|
|
|
|
2010-10-28 04:58:56 +08:00
|
|
|
/// EmitToMemory - Change a scalar value from its value
|
|
|
|
/// representation to its in-memory representation.
|
|
|
|
llvm::Value *EmitToMemory(llvm::Value *Value, QualType Ty);
|
|
|
|
|
|
|
|
/// EmitFromMemory - Change a scalar value from its memory
|
|
|
|
/// representation to its value representation.
|
|
|
|
llvm::Value *EmitFromMemory(llvm::Value *Value, QualType Ty);
|
|
|
|
|
2017-02-28 03:46:19 +08:00
|
|
|
/// Check if the scalar \p Value is within the valid range for the given
|
|
|
|
/// type \p Ty.
|
|
|
|
///
|
|
|
|
/// Returns true if a check is needed (even if the range is unknown).
|
|
|
|
bool EmitScalarRangeCheck(llvm::Value *Value, QualType Ty,
|
|
|
|
SourceLocation Loc);
|
|
|
|
|
2009-02-10 08:57:50 +08:00
|
|
|
/// EmitLoadOfScalar - Load a scalar value from an address, taking
|
|
|
|
/// care to appropriately convert from the memory representation to
|
|
|
|
/// the LLVM value representation.
|
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 *EmitLoadOfScalar(Address Addr, bool Volatile, QualType Ty,
|
2013-10-02 10:29:49 +08:00
|
|
|
SourceLocation Loc,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo =
|
|
|
|
LValueBaseInfo(AlignmentSource::Type),
|
2017-10-05 19:05:43 +08:00
|
|
|
TBAAAccessInfo TBAAInfo = TBAAAccessInfo(),
|
2015-09-09 07:52:33 +08:00
|
|
|
bool isNontemporal = false);
|
2011-06-25 10:11:03 +08:00
|
|
|
|
|
|
|
/// EmitLoadOfScalar - Load a scalar value from an address, taking
|
|
|
|
/// care to appropriately convert from the memory representation to
|
|
|
|
/// the LLVM value representation. The l-value must be a simple
|
|
|
|
/// l-value.
|
2013-10-02 10:29:49 +08:00
|
|
|
llvm::Value *EmitLoadOfScalar(LValue lvalue, SourceLocation Loc);
|
2009-02-10 08:57:50 +08:00
|
|
|
|
|
|
|
/// EmitStoreOfScalar - Store a scalar value to an address, taking
|
|
|
|
/// care to appropriately convert from the memory representation to
|
|
|
|
/// the LLVM value representation.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitStoreOfScalar(llvm::Value *Value, Address Addr,
|
|
|
|
bool Volatile, QualType Ty,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo =
|
|
|
|
LValueBaseInfo(AlignmentSource::Type),
|
2017-10-05 19:05:43 +08:00
|
|
|
TBAAAccessInfo TBAAInfo = TBAAAccessInfo(),
|
2017-10-03 18:52:39 +08:00
|
|
|
bool isInit = false, bool isNontemporal = false);
|
2011-06-25 10:11:03 +08:00
|
|
|
|
|
|
|
/// EmitStoreOfScalar - Store a scalar value to an address, taking
|
|
|
|
/// care to appropriately convert from the memory representation to
|
|
|
|
/// the LLVM value representation. The l-value must be a simple
|
2012-01-17 01:27:18 +08:00
|
|
|
/// l-value. The isInit flag indicates whether this is an initialization.
|
|
|
|
/// If so, atomic qualifiers are ignored and the store is always non-atomic.
|
|
|
|
void EmitStoreOfScalar(llvm::Value *value, LValue lvalue, bool isInit=false);
|
2009-02-10 08:57:50 +08:00
|
|
|
|
2007-06-06 04:53:16 +08:00
|
|
|
/// EmitLoadOfLValue - Given an expression that represents a value lvalue,
|
|
|
|
/// this method emits the address of the lvalue, then loads the result as an
|
|
|
|
/// rvalue, returning the rvalue.
|
2013-10-02 10:29:49 +08:00
|
|
|
RValue EmitLoadOfLValue(LValue V, SourceLocation Loc);
|
2011-06-25 10:11:03 +08:00
|
|
|
RValue EmitLoadOfExtVectorElementLValue(LValue V);
|
2017-03-10 00:06:27 +08:00
|
|
|
RValue EmitLoadOfBitfieldLValue(LValue LV, SourceLocation Loc);
|
2014-05-20 02:15:42 +08:00
|
|
|
RValue EmitLoadOfGlobalRegLValue(LValue LV);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2007-06-06 04:53:16 +08:00
|
|
|
/// EmitStoreThroughLValue - Store the specified rvalue into the specified
|
|
|
|
/// lvalue, where both are guaranteed to the have the same type, and that type
|
|
|
|
/// is 'Ty'.
|
2015-01-14 15:38:27 +08:00
|
|
|
void EmitStoreThroughLValue(RValue Src, LValue Dst, bool isInit = false);
|
2011-06-25 10:11:03 +08:00
|
|
|
void EmitStoreThroughExtVectorComponentLValue(RValue Src, LValue Dst);
|
2014-05-20 02:15:42 +08:00
|
|
|
void EmitStoreThroughGlobalRegLValue(RValue Src, LValue Dst);
|
2008-11-19 17:36:46 +08:00
|
|
|
|
2013-10-02 10:29:49 +08:00
|
|
|
/// EmitStoreThroughBitfieldLValue - Store Src into Dst with same constraints
|
|
|
|
/// as EmitStoreThroughLValue.
|
2008-11-19 17:36:46 +08:00
|
|
|
///
|
2009-02-09 07:14:22 +08:00
|
|
|
/// \param Result [out] - If non-null, this will be set to a Value* for the
|
|
|
|
/// bit-field contents after the store, appropriate for use as the result of
|
|
|
|
/// an assignment to the bit-field.
|
2011-06-25 10:11:03 +08:00
|
|
|
void EmitStoreThroughBitfieldLValue(RValue Src, LValue Dst,
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Value **Result=nullptr);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-11-17 07:07:28 +08:00
|
|
|
/// Emit an l-value for an assignment (simple or compound) of complex type.
|
|
|
|
LValue EmitComplexAssignmentLValue(const BinaryOperator *E);
|
2010-12-05 10:00:02 +08:00
|
|
|
LValue EmitComplexCompoundAssignmentLValue(const CompoundAssignOperator *E);
|
2015-02-13 05:23:20 +08:00
|
|
|
LValue EmitScalarCompoundAssignWithComplex(const CompoundAssignOperator *E,
|
|
|
|
llvm::Value *&Result);
|
2010-11-17 07:07:28 +08:00
|
|
|
|
2011-04-15 13:22:18 +08:00
|
|
|
// Note: only available for agg return types
|
2008-09-04 11:20:13 +08:00
|
|
|
LValue EmitBinaryOperatorLValue(const BinaryOperator *E);
|
2010-12-05 10:00:02 +08:00
|
|
|
LValue EmitCompoundAssignmentLValue(const CompoundAssignOperator *E);
|
2009-02-12 04:59:32 +08:00
|
|
|
// Note: only available for agg return types
|
2007-12-29 13:02:41 +08:00
|
|
|
LValue EmitCallExprLValue(const CallExpr *E);
|
2009-02-12 04:59:32 +08:00
|
|
|
// Note: only available for agg return types
|
|
|
|
LValue EmitVAArgExprLValue(const VAArgExpr *E);
|
2007-06-02 13:24:33 +08:00
|
|
|
LValue EmitDeclRefLValue(const DeclRefExpr *E);
|
2007-06-06 12:54:52 +08:00
|
|
|
LValue EmitStringLiteralLValue(const StringLiteral *E);
|
2009-02-25 06:18:39 +08:00
|
|
|
LValue EmitObjCEncodeExprLValue(const ObjCEncodeExpr *E);
|
2008-08-10 09:53:14 +08:00
|
|
|
LValue EmitPredefinedLValue(const PredefinedExpr *E);
|
2007-06-06 04:53:16 +08:00
|
|
|
LValue EmitUnaryOpLValue(const UnaryOperator *E);
|
2013-02-23 10:53:19 +08:00
|
|
|
LValue EmitArraySubscriptExpr(const ArraySubscriptExpr *E,
|
|
|
|
bool Accessed = false);
|
2015-08-31 15:32:19 +08:00
|
|
|
LValue EmitOMPArraySectionExpr(const OMPArraySectionExpr *E,
|
|
|
|
bool IsLowerBound = true);
|
2008-04-19 07:10:10 +08:00
|
|
|
LValue EmitExtVectorElementExpr(const ExtVectorElementExpr *E);
|
2007-10-23 10:10:49 +08:00
|
|
|
LValue EmitMemberExpr(const MemberExpr *E);
|
2009-12-10 07:35:29 +08:00
|
|
|
LValue EmitObjCIsaExpr(const ObjCIsaExpr *E);
|
2008-05-14 07:18:27 +08:00
|
|
|
LValue EmitCompoundLiteralLValue(const CompoundLiteralExpr *E);
|
2012-05-15 05:57:21 +08:00
|
|
|
LValue EmitInitListLValue(const InitListExpr *E);
|
2011-02-17 18:25:35 +08:00
|
|
|
LValue EmitConditionalOperatorLValue(const AbstractConditionalOperator *E);
|
2009-03-19 02:28:57 +08:00
|
|
|
LValue EmitCastLValue(const CastExpr *E);
|
2011-06-22 01:03:29 +08:00
|
|
|
LValue EmitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *E);
|
2011-02-16 16:02:54 +08:00
|
|
|
LValue EmitOpaqueValueLValue(const OpaqueValueExpr *e);
|
2014-08-20 01:17:40 +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 EmitExtVectorElementLValue(LValue V);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2013-10-02 10:29:49 +08:00
|
|
|
RValue EmitRValueForField(LValue LV, const FieldDecl *FD, SourceLocation Loc);
|
2012-04-13 19:22:00 +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 EmitArrayToPointerDecay(const Expr *Array,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
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
|
|
|
|
2012-03-10 11:05:10 +08:00
|
|
|
class ConstantEmission {
|
|
|
|
llvm::PointerIntPair<llvm::Constant*, 1, bool> ValueAndIsReference;
|
|
|
|
ConstantEmission(llvm::Constant *C, bool isReference)
|
|
|
|
: ValueAndIsReference(C, isReference) {}
|
|
|
|
public:
|
|
|
|
ConstantEmission() {}
|
|
|
|
static ConstantEmission forReference(llvm::Constant *C) {
|
|
|
|
return ConstantEmission(C, true);
|
|
|
|
}
|
|
|
|
static ConstantEmission forValue(llvm::Constant *C) {
|
|
|
|
return ConstantEmission(C, false);
|
|
|
|
}
|
|
|
|
|
2015-02-16 06:00:28 +08:00
|
|
|
explicit operator bool() const {
|
2014-05-21 13:09:00 +08:00
|
|
|
return ValueAndIsReference.getOpaqueValue() != nullptr;
|
|
|
|
}
|
2012-03-10 11:05:10 +08:00
|
|
|
|
|
|
|
bool isReference() const { return ValueAndIsReference.getInt(); }
|
|
|
|
LValue getReferenceLValue(CodeGenFunction &CGF, Expr *refExpr) const {
|
|
|
|
assert(isReference());
|
|
|
|
return CGF.MakeNaturalAlignAddrLValue(ValueAndIsReference.getPointer(),
|
|
|
|
refExpr->getType());
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Constant *getValue() const {
|
|
|
|
assert(!isReference());
|
|
|
|
return ValueAndIsReference.getPointer();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2012-03-10 17:33:50 +08:00
|
|
|
ConstantEmission tryEmitAsConstant(DeclRefExpr *refExpr);
|
2017-08-25 18:07:00 +08:00
|
|
|
ConstantEmission tryEmitAsConstant(const MemberExpr *ME);
|
2012-03-10 11:05:10 +08:00
|
|
|
|
2011-11-06 17:01:30 +08:00
|
|
|
RValue EmitPseudoObjectRValue(const PseudoObjectExpr *e,
|
|
|
|
AggValueSlot slot = AggValueSlot::ignored());
|
|
|
|
LValue EmitPseudoObjectLValue(const PseudoObjectExpr *e);
|
|
|
|
|
2009-04-22 13:08:15 +08:00
|
|
|
llvm::Value *EmitIvarOffset(const ObjCInterfaceDecl *Interface,
|
2008-09-24 12:00:38 +08:00
|
|
|
const ObjCIvarDecl *Ivar);
|
2012-04-16 11:54:45 +08:00
|
|
|
LValue EmitLValueForField(LValue Base, const FieldDecl* Field);
|
2013-05-03 15:33:41 +08:00
|
|
|
LValue EmitLValueForLambdaField(const FieldDecl *Field);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2010-01-29 13:24:29 +08:00
|
|
|
/// EmitLValueForFieldInitialization - Like EmitLValueForField, except that
|
|
|
|
/// if the Field is a reference, this will return the address of the reference
|
|
|
|
/// and not the address of the value stored in the reference.
|
2012-04-16 11:54:45 +08:00
|
|
|
LValue EmitLValueForFieldInitialization(LValue Base,
|
|
|
|
const FieldDecl* Field);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2009-02-03 08:09:52 +08:00
|
|
|
LValue EmitLValueForIvar(QualType ObjectTy,
|
|
|
|
llvm::Value* Base, const ObjCIvarDecl *Ivar,
|
2008-09-24 12:00:38 +08:00
|
|
|
unsigned CVRQualifiers);
|
2008-12-16 04:35:07 +08:00
|
|
|
|
2009-05-31 07:23:33 +08:00
|
|
|
LValue EmitCXXConstructLValue(const CXXConstructExpr *E);
|
2009-05-31 07:30:54 +08:00
|
|
|
LValue EmitCXXBindTemporaryLValue(const CXXBindTemporaryExpr *E);
|
2012-02-08 13:34:55 +08:00
|
|
|
LValue EmitLambdaLValue(const LambdaExpr *E);
|
2009-11-15 16:09:41 +08:00
|
|
|
LValue EmitCXXTypeidLValue(const CXXTypeidExpr *E);
|
2012-10-11 18:13:44 +08:00
|
|
|
LValue EmitCXXUuidofLValue(const CXXUuidofExpr *E);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2008-08-23 18:51:21 +08:00
|
|
|
LValue EmitObjCMessageExprLValue(const ObjCMessageExpr *E);
|
2008-03-31 07:03:07 +08:00
|
|
|
LValue EmitObjCIvarRefLValue(const ObjCIvarRefExpr *E);
|
2009-04-26 03:35:26 +08:00
|
|
|
LValue EmitStmtExprLValue(const StmtExpr *E);
|
2009-10-23 06:57:31 +08:00
|
|
|
LValue EmitPointerToDataMemberBinaryExpr(const BinaryOperator *E);
|
2010-06-18 03:56:20 +08:00
|
|
|
LValue EmitObjCSelectorLValue(const ObjCSelectorExpr *E);
|
2016-09-13 09:13:19 +08:00
|
|
|
void EmitDeclRefExprDbgValue(const DeclRefExpr *E, const APValue &Init);
|
2011-02-17 18:25:35 +08:00
|
|
|
|
2007-05-31 01:57:17 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
2007-08-11 08:04:45 +08:00
|
|
|
// Scalar Expression Emission
|
2007-05-31 01:57:17 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitCall - Generate a call of the given function, expecting the given
|
|
|
|
/// result type, and using the given argument list which specifies both the
|
|
|
|
/// LLVM arguments and the types they were derived from.
|
2016-10-27 07:46:34 +08:00
|
|
|
RValue EmitCall(const CGFunctionInfo &CallInfo, const CGCallee &Callee,
|
2015-11-24 06:04:44 +08:00
|
|
|
ReturnValueSlot ReturnValue, const CallArgList &Args,
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Instruction **callOrInvoke = nullptr);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
RValue EmitCall(QualType FnType, const CGCallee &Callee, const CallExpr *E,
|
2009-12-25 04:40:36 +08:00
|
|
|
ReturnValueSlot ReturnValue,
|
2014-12-13 07:41:25 +08:00
|
|
|
llvm::Value *Chain = nullptr);
|
2010-10-19 14:39:39 +08:00
|
|
|
RValue EmitCallExpr(const CallExpr *E,
|
2009-12-25 04:40:36 +08:00
|
|
|
ReturnValueSlot ReturnValue = ReturnValueSlot());
|
2016-10-27 07:46:34 +08:00
|
|
|
RValue EmitSimpleCallExpr(const CallExpr *E, ReturnValueSlot ReturnValue);
|
|
|
|
CGCallee EmitCallee(const Expr *E);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-11-12 08:44:04 +08:00
|
|
|
void checkTargetFeatures(const CallExpr *E, const FunctionDecl *TargetDecl);
|
2015-10-16 07:47:11 +08:00
|
|
|
|
2013-03-01 03:01:20 +08:00
|
|
|
llvm::CallInst *EmitRuntimeCall(llvm::Value *callee,
|
|
|
|
const Twine &name = "");
|
|
|
|
llvm::CallInst *EmitRuntimeCall(llvm::Value *callee,
|
|
|
|
ArrayRef<llvm::Value*> args,
|
|
|
|
const Twine &name = "");
|
|
|
|
llvm::CallInst *EmitNounwindRuntimeCall(llvm::Value *callee,
|
|
|
|
const Twine &name = "");
|
|
|
|
llvm::CallInst *EmitNounwindRuntimeCall(llvm::Value *callee,
|
|
|
|
ArrayRef<llvm::Value*> args,
|
|
|
|
const Twine &name = "");
|
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
llvm::CallSite EmitCallOrInvoke(llvm::Value *Callee,
|
2011-07-24 01:14:25 +08:00
|
|
|
ArrayRef<llvm::Value *> Args,
|
2011-07-20 15:06:53 +08:00
|
|
|
const Twine &Name = "");
|
2013-03-01 03:01:20 +08:00
|
|
|
llvm::CallSite EmitRuntimeCallOrInvoke(llvm::Value *callee,
|
|
|
|
ArrayRef<llvm::Value*> args,
|
|
|
|
const Twine &name = "");
|
|
|
|
llvm::CallSite EmitRuntimeCallOrInvoke(llvm::Value *callee,
|
|
|
|
const Twine &name = "");
|
|
|
|
void EmitNoreturnRuntimeCallOrInvoke(llvm::Value *callee,
|
|
|
|
ArrayRef<llvm::Value*> args);
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee BuildAppleKextVirtualCall(const CXXMethodDecl *MD,
|
|
|
|
NestedNameSpecifier *Qual,
|
|
|
|
llvm::Type *Ty);
|
2011-02-02 07:22:34 +08:00
|
|
|
|
2016-10-27 07:46:34 +08:00
|
|
|
CGCallee BuildAppleKextVirtualDestructorCall(const CXXDestructorDecl *DD,
|
|
|
|
CXXDtorType Type,
|
|
|
|
const CXXRecordDecl *RD);
|
2009-11-13 12:45:41 +08:00
|
|
|
|
2014-08-26 04:17:35 +08:00
|
|
|
RValue
|
2016-10-27 07:46:34 +08:00
|
|
|
EmitCXXMemberOrOperatorCall(const CXXMethodDecl *Method,
|
|
|
|
const CGCallee &Callee,
|
2014-08-26 04:17:35 +08:00
|
|
|
ReturnValueSlot ReturnValue, llvm::Value *This,
|
|
|
|
llvm::Value *ImplicitParam,
|
2016-09-29 03:09:10 +08:00
|
|
|
QualType ImplicitParamTy, const CallExpr *E,
|
|
|
|
CallArgList *RtlArgs);
|
2016-10-27 07:46:34 +08:00
|
|
|
RValue EmitCXXDestructorCall(const CXXDestructorDecl *DD,
|
|
|
|
const CGCallee &Callee,
|
2016-03-10 08:20:37 +08:00
|
|
|
llvm::Value *This, llvm::Value *ImplicitParam,
|
|
|
|
QualType ImplicitParamTy, const CallExpr *E,
|
|
|
|
StructorType Type);
|
2009-12-25 05:13:40 +08:00
|
|
|
RValue EmitCXXMemberCallExpr(const CXXMemberCallExpr *E,
|
|
|
|
ReturnValueSlot ReturnValue);
|
Fix incorrect codegen for devirtualized calls to virtual overloaded operators.
Consider this program:
struct A {
virtual void operator-() { printf("base\n"); }
};
struct B final : public A {
virtual void operator-() override { printf("derived\n"); }
};
int main() {
B* b = new B;
-static_cast<A&>(*b);
}
Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable. Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.
For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.
This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.
This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.
(This adjustment for virtual operator calls seems still wrong with the MS ABI.)
llvm-svn: 223185
2014-12-03 09:21:41 +08:00
|
|
|
RValue EmitCXXMemberOrOperatorMemberCallExpr(const CallExpr *CE,
|
|
|
|
const CXXMethodDecl *MD,
|
|
|
|
ReturnValueSlot ReturnValue,
|
|
|
|
bool HasQualifier,
|
|
|
|
NestedNameSpecifier *Qualifier,
|
|
|
|
bool IsArrow, const Expr *Base);
|
|
|
|
// Compute the object 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 EmitCXXMemberDataPointerAddress(const Expr *E, Address base,
|
|
|
|
llvm::Value *memberPtr,
|
|
|
|
const MemberPointerType *memberPtrType,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
2009-12-25 05:13:40 +08:00
|
|
|
RValue EmitCXXMemberPointerCallExpr(const CXXMemberCallExpr *E,
|
|
|
|
ReturnValueSlot ReturnValue);
|
This patch is motivated by numerous strict-aliasing warnings when compiling
clang as a Release build.
The big change is that all AST nodes (subclasses of Stmt) whose children are
Expr* store their children as Stmt* or arrays of Stmt*. This is to remove
strict-aliasing warnings when using StmtIterator. None of the interfaces of any
of the classes have changed (except those with arg_iterators, see below), as the
accessor methods introduce the needed casts (via cast<>). While this extra
casting may seem cumbersome, it actually adds some important sanity checks
throughout the codebase, as clients using StmtIterator can potentially overwrite
children that are expected to be Expr* with Stmt* (that aren't Expr*). The casts
provide extra sanity checks that are operational in debug builds to catch
invariant violations such as these.
For classes that have arg_iterators (e.g., CallExpr), the definition of
arg_iterator has been replaced. Instead of it being Expr**, it is an actual
class (called ExprIterator) that wraps a Stmt**, and provides the necessary
operators for iteration. The nice thing about this class is that it also uses
cast<> to type-checking, which introduces extra sanity checks throughout the
codebase that are useful for debugging.
A few of the CodeGen functions that use arg_iterator (especially from
OverloadExpr) have been modified to take begin and end iterators instead of a
base Expr** and the number of arguments. This matches more with the abstraction
of iteration. This still needs to be cleaned up a little bit, as clients expect
that ExprIterator is a RandomAccessIterator (which we may or may not wish to
allow for efficiency of representation).
This is a fairly large patch. It passes the tests (except CodeGen/bitfield.c,
which was already broken) on both a Debug and Release build, but it should
obviously be reviewed.
llvm-svn: 52378
2008-06-17 10:43:46 +08:00
|
|
|
|
2009-05-27 12:18:27 +08:00
|
|
|
RValue EmitCXXOperatorMemberCallExpr(const CXXOperatorCallExpr *E,
|
2009-12-25 05:13:40 +08:00
|
|
|
const CXXMethodDecl *MD,
|
|
|
|
ReturnValueSlot ReturnValue);
|
2016-10-27 07:46:34 +08:00
|
|
|
RValue EmitCXXPseudoDestructorExpr(const CXXPseudoDestructorExpr *E);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-10-07 02:29:37 +08:00
|
|
|
RValue EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
|
|
|
|
ReturnValueSlot ReturnValue);
|
|
|
|
|
2017-01-30 04:49:31 +08:00
|
|
|
RValue EmitNVPTXDevicePrintfCallExpr(const CallExpr *E,
|
|
|
|
ReturnValueSlot ReturnValue);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
RValue EmitBuiltinExpr(const FunctionDecl *FD,
|
2014-12-13 07:41:25 +08:00
|
|
|
unsigned BuiltinID, const CallExpr *E,
|
|
|
|
ReturnValueSlot ReturnValue);
|
2007-06-06 04:53:16 +08:00
|
|
|
|
2009-12-25 05:13:40 +08:00
|
|
|
RValue EmitBlockCallExpr(const CallExpr *E, ReturnValueSlot ReturnValue);
|
2009-02-18 01:00:02 +08:00
|
|
|
|
2009-02-09 07:14:22 +08:00
|
|
|
/// EmitTargetBuiltinExpr - Emit the given builtin call. Returns 0 if the call
|
|
|
|
/// is unhandled by the current target.
|
2008-10-10 08:24:54 +08:00
|
|
|
llvm::Value *EmitTargetBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
|
|
|
|
2013-11-14 10:45:18 +08:00
|
|
|
llvm::Value *EmitAArch64CompareBuiltinExpr(llvm::Value *Op, llvm::Type *Ty,
|
|
|
|
const llvm::CmpInst::Predicate Fp,
|
|
|
|
const llvm::CmpInst::Predicate Ip,
|
|
|
|
const llvm::Twine &Name = "");
|
2010-03-04 03:03:45 +08:00
|
|
|
llvm::Value *EmitARMBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2014-02-21 19:57:24 +08:00
|
|
|
|
|
|
|
llvm::Value *EmitCommonNeonBuiltinExpr(unsigned BuiltinID,
|
|
|
|
unsigned LLVMIntrinsic,
|
|
|
|
unsigned AltLLVMIntrinsic,
|
|
|
|
const char *NameHint,
|
|
|
|
unsigned Modifier,
|
|
|
|
const CallExpr *E,
|
2014-01-31 18:46:45 +08:00
|
|
|
SmallVectorImpl<llvm::Value *> &Ops,
|
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 PtrOp0, Address PtrOp1);
|
2014-02-21 19:57:24 +08:00
|
|
|
llvm::Function *LookupNeonLLVMIntrinsic(unsigned IntrinsicID,
|
|
|
|
unsigned Modifier, llvm::Type *ArgTy,
|
|
|
|
const CallExpr *E);
|
2010-10-19 14:39:39 +08:00
|
|
|
llvm::Value *EmitNeonCall(llvm::Function *F,
|
2011-07-20 14:58:45 +08:00
|
|
|
SmallVectorImpl<llvm::Value*> &O,
|
2010-12-09 06:37:56 +08:00
|
|
|
const char *name,
|
2010-06-14 13:21:25 +08:00
|
|
|
unsigned shift = 0, bool rightshift = false);
|
2010-12-08 06:40:02 +08:00
|
|
|
llvm::Value *EmitNeonSplat(llvm::Value *V, llvm::Constant *Idx);
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::Value *EmitNeonShiftVector(llvm::Value *V, llvm::Type *Ty,
|
2010-06-14 13:21:25 +08:00
|
|
|
bool negateForRightShift);
|
2013-10-04 21:13:15 +08:00
|
|
|
llvm::Value *EmitNeonRShiftImm(llvm::Value *Vec, llvm::Value *Amt,
|
|
|
|
llvm::Type *Ty, bool usgn, const char *name);
|
2014-03-29 23:09:45 +08:00
|
|
|
llvm::Value *vectorWrapScalar16(llvm::Value *Op);
|
2014-05-24 20:52:07 +08:00
|
|
|
llvm::Value *EmitAArch64BuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2012-02-22 17:30:11 +08:00
|
|
|
llvm::Value *BuildVector(ArrayRef<llvm::Value*> Ops);
|
2007-12-10 07:17:02 +08:00
|
|
|
llvm::Value *EmitX86BuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
|
|
|
llvm::Value *EmitPPCBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2015-06-20 01:54:10 +08:00
|
|
|
llvm::Value *EmitAMDGPUBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2015-04-01 20:54:25 +08:00
|
|
|
llvm::Value *EmitSystemZBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2015-06-26 02:29:42 +08:00
|
|
|
llvm::Value *EmitNVPTXBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
|
2015-09-04 06:51:53 +08:00
|
|
|
llvm::Value *EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
|
|
|
|
const CallExpr *E);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2016-10-13 06:01:05 +08:00
|
|
|
private:
|
|
|
|
enum class MSVCIntrin;
|
|
|
|
|
|
|
|
public:
|
|
|
|
llvm::Value *EmitMSVCBuiltinExpr(MSVCIntrin BuiltinID, const CallExpr *E);
|
|
|
|
|
2017-02-24 05:08:08 +08:00
|
|
|
llvm::Value *EmitBuiltinAvailable(ArrayRef<llvm::Value *> Args);
|
|
|
|
|
2008-08-20 08:28:19 +08:00
|
|
|
llvm::Value *EmitObjCProtocolExpr(const ObjCProtocolExpr *E);
|
2007-08-24 13:35:26 +08:00
|
|
|
llvm::Value *EmitObjCStringLiteral(const ObjCStringLiteral *E);
|
2012-04-19 08:25:12 +08:00
|
|
|
llvm::Value *EmitObjCBoxedExpr(const ObjCBoxedExpr *E);
|
2012-03-07 04:05:56 +08:00
|
|
|
llvm::Value *EmitObjCArrayLiteral(const ObjCArrayLiteral *E);
|
|
|
|
llvm::Value *EmitObjCDictionaryLiteral(const ObjCDictionaryLiteral *E);
|
|
|
|
llvm::Value *EmitObjCCollectionLiteral(const Expr *E,
|
2014-10-29 02:28:16 +08:00
|
|
|
const ObjCMethodDecl *MethodWithObjects);
|
2008-06-25 01:04:18 +08:00
|
|
|
llvm::Value *EmitObjCSelectorExpr(const ObjCSelectorExpr *E);
|
2010-05-22 09:48:05 +08:00
|
|
|
RValue EmitObjCMessageExpr(const ObjCMessageExpr *E,
|
|
|
|
ReturnValueSlot Return = ReturnValueSlot());
|
2008-06-25 01:04:18 +08:00
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
/// Retrieves the default cleanup kind for an ARC cleanup.
|
|
|
|
/// Except under -fobjc-arc-eh, ARC cleanups are normal-only.
|
|
|
|
CleanupKind getARCCleanupKind() {
|
|
|
|
return CGM.getCodeGenOpts().ObjCAutoRefCountExceptions
|
|
|
|
? NormalAndEHCleanup : NormalCleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
// ARC primitives.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitARCInitWeak(Address addr, llvm::Value *value);
|
|
|
|
void EmitARCDestroyWeak(Address addr);
|
2015-10-22 02:06:43 +08:00
|
|
|
llvm::Value *EmitARCLoadWeak(Address addr);
|
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 *EmitARCLoadWeakRetained(Address addr);
|
|
|
|
llvm::Value *EmitARCStoreWeak(Address addr, llvm::Value *value, bool ignored);
|
|
|
|
void EmitARCCopyWeak(Address dst, Address src);
|
|
|
|
void EmitARCMoveWeak(Address dst, Address src);
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::Value *EmitARCRetainAutorelease(QualType type, llvm::Value *value);
|
|
|
|
llvm::Value *EmitARCRetainAutoreleaseNonBlock(llvm::Value *value);
|
2011-06-25 10:11:03 +08:00
|
|
|
llvm::Value *EmitARCStoreStrong(LValue lvalue, llvm::Value *value,
|
2013-03-13 11:10:54 +08:00
|
|
|
bool resultIgnored);
|
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 *EmitARCStoreStrongCall(Address addr, llvm::Value *value,
|
2013-03-13 11:10:54 +08:00
|
|
|
bool resultIgnored);
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::Value *EmitARCRetain(QualType type, llvm::Value *value);
|
2016-03-22 04:50:03 +08:00
|
|
|
llvm::Value *EmitARCRetainNonBlock(llvm::Value *value);
|
2011-10-04 14:23:45 +08:00
|
|
|
llvm::Value *EmitARCRetainBlock(llvm::Value *value, bool mandatory);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void EmitARCDestroyStrong(Address addr, ARCPreciseLifetime_t precise);
|
2013-03-13 11:10:54 +08:00
|
|
|
void EmitARCRelease(llvm::Value *value, ARCPreciseLifetime_t precise);
|
2016-03-22 04:50:03 +08:00
|
|
|
llvm::Value *EmitARCAutorelease(llvm::Value *value);
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::Value *EmitARCAutoreleaseReturnValue(llvm::Value *value);
|
|
|
|
llvm::Value *EmitARCRetainAutoreleaseReturnValue(llvm::Value *value);
|
|
|
|
llvm::Value *EmitARCRetainAutoreleasedReturnValue(llvm::Value *value);
|
2016-01-28 02:32:30 +08:00
|
|
|
llvm::Value *EmitARCUnsafeClaimAutoreleasedReturnValue(llvm::Value *value);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
std::pair<LValue,llvm::Value*>
|
|
|
|
EmitARCStoreAutoreleasing(const BinaryOperator *e);
|
|
|
|
std::pair<LValue,llvm::Value*>
|
|
|
|
EmitARCStoreStrong(const BinaryOperator *e, bool ignored);
|
2016-01-28 02:32:30 +08:00
|
|
|
std::pair<LValue,llvm::Value*>
|
|
|
|
EmitARCStoreUnsafeUnretained(const BinaryOperator *e, bool ignored);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
2011-10-01 18:32:24 +08:00
|
|
|
llvm::Value *EmitObjCThrowOperand(const Expr *expr);
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::Value *EmitObjCConsumeObject(QualType T, llvm::Value *Ptr);
|
|
|
|
llvm::Value *EmitObjCExtendObjectLifetime(QualType T, llvm::Value *Ptr);
|
|
|
|
|
2011-10-04 14:23:45 +08:00
|
|
|
llvm::Value *EmitARCExtendBlockObject(const Expr *expr);
|
2016-01-28 02:32:30 +08:00
|
|
|
llvm::Value *EmitARCReclaimReturnedObject(const Expr *e,
|
|
|
|
bool allowUnsafeClaim);
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::Value *EmitARCRetainScalarExpr(const Expr *expr);
|
|
|
|
llvm::Value *EmitARCRetainAutoreleaseScalarExpr(const Expr *expr);
|
2016-01-28 02:32:30 +08:00
|
|
|
llvm::Value *EmitARCUnsafeUnretainedScalarExpr(const Expr *expr);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
2014-06-29 07:22:23 +08:00
|
|
|
void EmitARCIntrinsicUse(ArrayRef<llvm::Value*> values);
|
2013-03-23 10:35:54 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
static Destroyer destroyARCStrongImprecise;
|
|
|
|
static Destroyer destroyARCStrongPrecise;
|
|
|
|
static Destroyer destroyARCWeak;
|
2017-04-29 02:50:57 +08:00
|
|
|
static Destroyer emitARCIntrinsicUse;
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
void EmitObjCAutoreleasePoolPop(llvm::Value *Ptr);
|
|
|
|
llvm::Value *EmitObjCAutoreleasePoolPush();
|
|
|
|
llvm::Value *EmitObjCMRRAutoreleasePoolPush();
|
|
|
|
void EmitObjCAutoreleasePoolCleanup(llvm::Value *Ptr);
|
|
|
|
void EmitObjCMRRAutoreleasePoolPop(llvm::Value *Ptr);
|
|
|
|
|
2013-06-13 07:38:09 +08:00
|
|
|
/// \brief Emits a reference binding to the passed in expression.
|
|
|
|
RValue EmitReferenceBindingToExpr(const Expr *E);
|
2010-02-01 02:34:51 +08:00
|
|
|
|
2007-08-11 08:04:45 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
2007-08-27 07:13:56 +08:00
|
|
|
// Expression Emission
|
2007-08-11 08:04:45 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
2007-08-27 07:13:56 +08:00
|
|
|
|
|
|
|
// Expressions are broken into three classes: scalar, complex, aggregate.
|
2009-02-09 07:14:22 +08:00
|
|
|
|
|
|
|
/// EmitScalarExpr - Emit the computation of the specified expression of LLVM
|
|
|
|
/// scalar type, returning the result.
|
2009-08-16 15:36:22 +08:00
|
|
|
llvm::Value *EmitScalarExpr(const Expr *E , bool IgnoreResultAssign = false);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2015-08-05 14:19:26 +08:00
|
|
|
/// Emit a conversion from the specified type to the specified destination
|
|
|
|
/// type, both of which are LLVM scalar types.
|
2007-08-26 14:48:56 +08:00
|
|
|
llvm::Value *EmitScalarConversion(llvm::Value *Src, QualType SrcTy,
|
2015-08-11 12:19:28 +08:00
|
|
|
QualType DstTy, SourceLocation Loc);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2015-08-05 14:19:26 +08:00
|
|
|
/// Emit a conversion from the specified complex type to the specified
|
|
|
|
/// destination type, where the destination type is an LLVM scalar type.
|
2007-08-27 00:34:22 +08:00
|
|
|
llvm::Value *EmitComplexToScalarConversion(ComplexPairTy Src, QualType SrcTy,
|
2015-08-11 12:19:28 +08:00
|
|
|
QualType DstTy,
|
|
|
|
SourceLocation Loc);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
/// EmitAggExpr - Emit the computation of the specified expression
|
|
|
|
/// of aggregate type. The result is computed into the given slot,
|
|
|
|
/// which may be null to indicate that the value is not needed.
|
2012-07-03 07:58:38 +08:00
|
|
|
void EmitAggExpr(const Expr *E, AggValueSlot AS);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2010-02-06 03:38:31 +08:00
|
|
|
/// EmitAggExprToLValue - Emit the computation of the specified expression of
|
|
|
|
/// aggregate type into a temporary LValue.
|
|
|
|
LValue EmitAggExprToLValue(const Expr *E);
|
|
|
|
|
2011-06-25 07:21:27 +08:00
|
|
|
/// EmitExtendGCLifetime - Given a pointer to an Objective-C object,
|
|
|
|
/// make sure it survives garbage collection until this point.
|
|
|
|
void EmitExtendGCLifetime(llvm::Value *object);
|
|
|
|
|
2007-08-21 13:54:00 +08:00
|
|
|
/// EmitComplexExpr - Emit the computation of the specified expression of
|
2007-08-24 07:43:33 +08:00
|
|
|
/// complex type, returning the result.
|
2010-11-16 18:08:07 +08:00
|
|
|
ComplexPairTy EmitComplexExpr(const Expr *E,
|
|
|
|
bool IgnoreReal = false,
|
|
|
|
bool IgnoreImag = false);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
/// EmitComplexExprIntoLValue - Emit the given expression of complex
|
|
|
|
/// type and place its result into the specified l-value.
|
2015-01-14 15:38:27 +08:00
|
|
|
void EmitComplexExprIntoLValue(const Expr *E, LValue dest, bool isInit);
|
2013-03-08 05:37:08 +08:00
|
|
|
|
|
|
|
/// EmitStoreOfComplex - Store a complex number into the specified l-value.
|
2015-01-14 15:38:27 +08:00
|
|
|
void EmitStoreOfComplex(ComplexPairTy V, LValue dest, bool isInit);
|
2008-08-30 13:35:15 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
/// EmitLoadOfComplex - Load a complex number from the specified l-value.
|
2013-10-02 10:29:49 +08:00
|
|
|
ComplexPairTy EmitLoadOfComplex(LValue src, SourceLocation loc);
|
2008-05-08 13:58:21 +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 emitAddrOfRealComponent(Address complex, QualType complexType);
|
|
|
|
Address emitAddrOfImagComponent(Address complex, QualType complexType);
|
|
|
|
|
2012-03-31 03:44:53 +08:00
|
|
|
/// AddInitializerToStaticVarDecl - Add the initializer for 'D' to the
|
|
|
|
/// global variable that has already been created for it. If the initializer
|
|
|
|
/// has a different type than GV does, this may free GV and return a different
|
|
|
|
/// one. Otherwise it just returns GV.
|
|
|
|
llvm::GlobalVariable *
|
|
|
|
AddInitializerToStaticVarDecl(const VarDecl &D,
|
|
|
|
llvm::GlobalVariable *GV);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2009-02-26 03:24:29 +08:00
|
|
|
|
2009-08-09 05:45:14 +08:00
|
|
|
/// EmitCXXGlobalVarDeclInit - Create the initializer for a C++
|
|
|
|
/// variable with global storage.
|
2012-02-14 06:16:19 +08:00
|
|
|
void EmitCXXGlobalVarDeclInit(const VarDecl &D, llvm::Constant *DeclPtr,
|
|
|
|
bool PerformInit);
|
2009-08-09 05:45:14 +08:00
|
|
|
|
2014-10-05 13:05:40 +08:00
|
|
|
llvm::Constant *createAtExitStub(const VarDecl &VD, llvm::Constant *Dtor,
|
|
|
|
llvm::Constant *Addr);
|
|
|
|
|
2012-05-01 14:13:13 +08:00
|
|
|
/// Call atexit() with a function that passes the given argument to
|
|
|
|
/// the given function.
|
2013-08-28 07:57:18 +08:00
|
|
|
void registerGlobalDtorWithAtExit(const VarDecl &D, llvm::Constant *fn,
|
|
|
|
llvm::Constant *addr);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-11-06 17:44:32 +08:00
|
|
|
/// Emit code in this function to perform a guarded variable
|
|
|
|
/// initialization. Guarded initializations are used when it's not
|
|
|
|
/// possible to prove that an initialization will be done exactly
|
|
|
|
/// once, e.g. with a static local variable or a static data member
|
|
|
|
/// of a class template.
|
2012-03-31 03:44:53 +08:00
|
|
|
void EmitCXXGuardedInit(const VarDecl &D, llvm::GlobalVariable *DeclPtr,
|
2012-02-14 06:16:19 +08:00
|
|
|
bool PerformInit);
|
2010-09-08 09:44:27 +08:00
|
|
|
|
2017-07-27 06:01:09 +08:00
|
|
|
enum class GuardKind { VariableGuard, TlsGuard };
|
|
|
|
|
|
|
|
/// Emit a branch to select whether or not to perform guarded initialization.
|
|
|
|
void EmitCXXGuardedInitBranch(llvm::Value *NeedsInit,
|
|
|
|
llvm::BasicBlock *InitBlock,
|
|
|
|
llvm::BasicBlock *NoInitBlock,
|
|
|
|
GuardKind Kind, const VarDecl *D);
|
|
|
|
|
2010-03-20 12:15:41 +08:00
|
|
|
/// GenerateCXXGlobalInitFunc - Generates code for initializing global
|
|
|
|
/// variables.
|
|
|
|
void GenerateCXXGlobalInitFunc(llvm::Function *Fn,
|
2014-10-05 13:05:40 +08:00
|
|
|
ArrayRef<llvm::Function *> CXXThreadLocals,
|
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 Guard = Address::invalid());
|
2010-03-20 12:15:41 +08:00
|
|
|
|
2012-04-07 02:21:03 +08:00
|
|
|
/// GenerateCXXGlobalDtorsFunc - Generates code for destroying global
|
2010-03-20 12:15:41 +08:00
|
|
|
/// variables.
|
2017-05-02 01:08:00 +08:00
|
|
|
void GenerateCXXGlobalDtorsFunc(
|
|
|
|
llvm::Function *Fn,
|
|
|
|
const std::vector<std::pair<llvm::WeakTrackingVH, llvm::Constant *>>
|
|
|
|
&DtorsAndObjects);
|
2010-03-20 12:15:41 +08:00
|
|
|
|
2011-03-09 12:27:21 +08:00
|
|
|
void GenerateCXXGlobalVarDeclInitFunc(llvm::Function *Fn,
|
|
|
|
const VarDecl *D,
|
2012-02-14 06:16:19 +08:00
|
|
|
llvm::GlobalVariable *Addr,
|
|
|
|
bool PerformInit);
|
2010-03-20 12:15:41 +08:00
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
void EmitCXXConstructExpr(const CXXConstructExpr *E, AggValueSlot Dest);
|
2010-11-14 05:53:34 +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
|
|
|
void EmitSynthesizedCXXCopyCtor(Address Dest, Address Src, const Expr *Exp);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
void enterFullExpression(const ExprWithCleanups *E) {
|
|
|
|
if (E->getNumObjects() == 0) return;
|
|
|
|
enterNonTrivialFullExpression(E);
|
|
|
|
}
|
|
|
|
void enterNonTrivialFullExpression(const ExprWithCleanups *E);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-05-08 05:53:22 +08:00
|
|
|
void EmitCXXThrowExpr(const CXXThrowExpr *E, bool KeepInsertionPoint = true);
|
2010-05-16 08:44:00 +08:00
|
|
|
|
2012-02-09 11:32:31 +08:00
|
|
|
void EmitLambdaExpr(const LambdaExpr *E, AggValueSlot Dest);
|
|
|
|
|
2015-11-10 03:56:35 +08:00
|
|
|
RValue EmitAtomicExpr(AtomicExpr *E);
|
2011-10-11 10:20:01 +08:00
|
|
|
|
2011-09-10 06:41:49 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Annotations Emission
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
/// Emit an annotation call (intrinsic or builtin).
|
|
|
|
llvm::Value *EmitAnnotationCall(llvm::Value *AnnotationFn,
|
|
|
|
llvm::Value *AnnotatedVal,
|
2013-01-13 03:30:44 +08:00
|
|
|
StringRef AnnotationStr,
|
2011-09-10 06:41:49 +08:00
|
|
|
SourceLocation Location);
|
|
|
|
|
|
|
|
/// Emit local annotations for the local variable V, declared by D.
|
|
|
|
void EmitVarAnnotations(const VarDecl *D, llvm::Value *V);
|
|
|
|
|
|
|
|
/// Emit field annotations for the given field & value. Returns the
|
|
|
|
/// annotation result.
|
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 EmitFieldAnnotations(const FieldDecl *D, Address V);
|
2011-09-10 06:41:49 +08:00
|
|
|
|
2008-08-05 00:51:22 +08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Internal Helpers
|
|
|
|
//===--------------------------------------------------------------------===//
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
/// ContainsLabel - Return true if the statement contains a label in it. If
|
|
|
|
/// this statement is not executed normally, it not containing a label means
|
|
|
|
/// that we can just remove the code.
|
|
|
|
static bool ContainsLabel(const Stmt *S, bool IgnoreCaseStmts = false);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
/// containsBreak - Return true if the statement contains a break out of it.
|
|
|
|
/// If the statement (recursively) contains a switch or loop with a break
|
|
|
|
/// inside of it, this is fine.
|
|
|
|
static bool containsBreak(const Stmt *S);
|
2016-09-17 07:30:39 +08:00
|
|
|
|
|
|
|
/// Determine if the given statement might introduce a declaration into the
|
|
|
|
/// current scope, by being a (possibly-labelled) DeclStmt.
|
|
|
|
static bool mightAddDeclToScope(const Stmt *S);
|
2011-02-28 08:18:40 +08:00
|
|
|
|
2008-11-12 18:12:14 +08:00
|
|
|
/// ConstantFoldsToSimpleInteger - If the specified expression does not fold
|
2011-02-28 07:02:32 +08:00
|
|
|
/// to a constant, or if it does but contains a label, return false. If it
|
|
|
|
/// constant folds return true and set the boolean result in Result.
|
2016-06-24 03:16:49 +08:00
|
|
|
bool ConstantFoldsToSimpleInteger(const Expr *Cond, bool &Result,
|
|
|
|
bool AllowLabels = false);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
/// ConstantFoldsToSimpleInteger - If the specified expression does not fold
|
|
|
|
/// to a constant, or if it does but contains a label, return false. If it
|
|
|
|
/// constant folds return true and set the folded value.
|
2016-06-24 03:16:49 +08:00
|
|
|
bool ConstantFoldsToSimpleInteger(const Expr *Cond, llvm::APSInt &Result,
|
|
|
|
bool AllowLabels = false);
|
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
/// EmitBranchOnBoolExpr - Emit a branch on a boolean condition (e.g. for an
|
|
|
|
/// if statement) to the specified blocks. Based on the condition, this might
|
|
|
|
/// try to simplify the codegen of the conditional based on the branch.
|
2014-01-07 06:27:43 +08:00
|
|
|
/// TrueCount should be the number of times we expect the condition to
|
|
|
|
/// evaluate to true based on PGO data.
|
Make emission of 'if' conditions much more sophisticated when we
have a condition that is an &&/||. Before we used to compile things like this:
int test() {
if (x && y) foo(); else bar();
}
into:
%0 = load i32* @x ; <i32> [#uses=1]
%1 = icmp ne i32 %0, 0 ; <i1> [#uses=1]
br i1 %1, label %land_rhs, label %land_cont
land_rhs: ; preds = %entry
%2 = load i32* @y ; <i32> [#uses=1]
%3 = icmp ne i32 %2, 0 ; <i1> [#uses=1]
br label %land_cont
land_cont: ; preds = %land_rhs, %entry
%4 = phi i1 [ false, %entry ], [ %3, %land_rhs ] ; <i1> [#uses=1]
br i1 %4, label %ifthen, label %ifelse
ifthen: ; preds = %land_cont
%call = call i32 (...)* @foo() ; <i32> [#uses=0]
br label %ifend
ifelse: ; preds = %land_cont
%call1 = call i32 (...)* @bar() ; <i32> [#uses=0]
br label %ifend
ifend: ; preds = %ifelse, %ifthen
Now we turn it into the much more svelte code:
%0 = load i32* @x ; <i32> [#uses=1]
%1 = icmp ne i32 %0, 0 ; <i1> [#uses=1]
br i1 %1, label %land_lhs_true, label %ifelse
land_lhs_true: ; preds = %entry
%2 = load i32* @y ; <i32> [#uses=1]
%3 = icmp ne i32 %2, 0 ; <i1> [#uses=1]
br i1 %3, label %ifthen, label %ifelse
ifthen: ; preds = %land_lhs_true
%call = call i32 (...)* @foo() ; <i32> [#uses=0]
br label %ifend
ifelse: ; preds = %land_lhs_true, %entry
%call1 = call i32 (...)* @bar() ; <i32> [#uses=0]
br label %ifend
ifend: ; preds = %ifelse, %ifthen
Note the lack of a phi node.
This shrinks the -O0 .ll file for 176.gcc/expr.c from 43176 to 40267 lines.
llvm-svn: 59111
2008-11-12 15:46:33 +08:00
|
|
|
void EmitBranchOnBoolExpr(const Expr *Cond, llvm::BasicBlock *TrueBlock,
|
2014-01-07 06:27:43 +08:00
|
|
|
llvm::BasicBlock *FalseBlock, uint64_t TrueCount);
|
2009-12-15 05:58:14 +08:00
|
|
|
|
2017-03-14 09:56:34 +08:00
|
|
|
/// Given an assignment `*LHS = RHS`, emit a test that checks if \p RHS is
|
|
|
|
/// nonnull, if \p LHS is marked _Nonnull.
|
|
|
|
void EmitNullabilityCheck(LValue LHS, llvm::Value *RHS, SourceLocation Loc);
|
|
|
|
|
2017-07-14 04:55:26 +08:00
|
|
|
/// An enumeration which makes it easier to specify whether or not an
|
|
|
|
/// operation is a subtraction.
|
|
|
|
enum { NotSubtraction = false, IsSubtraction = true };
|
|
|
|
|
2017-06-02 03:22:18 +08:00
|
|
|
/// Same as IRBuilder::CreateInBoundsGEP, but additionally emits a check to
|
|
|
|
/// detect undefined behavior when the pointer overflow sanitizer is enabled.
|
2017-06-13 02:42:51 +08:00
|
|
|
/// \p SignedIndices indicates whether any of the GEP indices are signed.
|
2017-07-14 04:55:26 +08:00
|
|
|
/// \p IsSubtraction indicates whether the expression used to form the GEP
|
|
|
|
/// is a subtraction.
|
2017-06-02 03:22:18 +08:00
|
|
|
llvm::Value *EmitCheckedInBoundsGEP(llvm::Value *Ptr,
|
|
|
|
ArrayRef<llvm::Value *> IdxList,
|
2017-06-13 02:42:51 +08:00
|
|
|
bool SignedIndices,
|
2017-07-14 04:55:26 +08:00
|
|
|
bool IsSubtraction,
|
2017-06-02 03:22:18 +08:00
|
|
|
SourceLocation Loc,
|
|
|
|
const Twine &Name = "");
|
|
|
|
|
2017-07-29 08:19:51 +08:00
|
|
|
/// Specifies which type of sanitizer check to apply when handling a
|
|
|
|
/// particular builtin.
|
|
|
|
enum BuiltinCheckKind {
|
|
|
|
BCK_CTZPassedZero,
|
|
|
|
BCK_CLZPassedZero,
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Emits an argument for a call to a builtin. If the builtin sanitizer is
|
|
|
|
/// enabled, a runtime check specified by \p Kind is also emitted.
|
|
|
|
llvm::Value *EmitCheckedArgForBuiltin(const Expr *E, BuiltinCheckKind Kind);
|
|
|
|
|
2012-10-10 03:52:38 +08:00
|
|
|
/// \brief Emit a description of a type in a format suitable for passing to
|
|
|
|
/// a runtime sanitizer handler.
|
|
|
|
llvm::Constant *EmitCheckTypeDescriptor(QualType T);
|
|
|
|
|
|
|
|
/// \brief Convert a value into a format suitable for passing to a runtime
|
|
|
|
/// sanitizer handler.
|
|
|
|
llvm::Value *EmitCheckValue(llvm::Value *V);
|
|
|
|
|
|
|
|
/// \brief Emit a description of a source location in a format suitable for
|
|
|
|
/// passing to a runtime sanitizer handler.
|
|
|
|
llvm::Constant *EmitCheckSourceLocation(SourceLocation Loc);
|
|
|
|
|
2012-11-02 06:15:34 +08:00
|
|
|
/// \brief Create a basic block that will call a handler function in a
|
|
|
|
/// sanitizer runtime with the provided arguments, and create a conditional
|
|
|
|
/// branch to it.
|
2015-05-12 05:39:14 +08:00
|
|
|
void EmitCheck(ArrayRef<std::pair<llvm::Value *, SanitizerMask>> Checked,
|
2016-12-13 00:18:40 +08:00
|
|
|
SanitizerHandler Check, ArrayRef<llvm::Constant *> StaticArgs,
|
2014-11-12 06:03:54 +08:00
|
|
|
ArrayRef<llvm::Value *> DynamicArgs);
|
2010-10-19 14:39:39 +08:00
|
|
|
|
2015-12-16 07:00:20 +08:00
|
|
|
/// \brief Emit a slow path cross-DSO CFI check which calls __cfi_slowpath
|
|
|
|
/// if Cond if false.
|
2016-01-26 07:34:52 +08:00
|
|
|
void EmitCfiSlowPathCheck(SanitizerMask Kind, llvm::Value *Cond,
|
|
|
|
llvm::ConstantInt *TypeId, llvm::Value *Ptr,
|
|
|
|
ArrayRef<llvm::Constant *> StaticArgs);
|
2015-12-16 07:00:20 +08:00
|
|
|
|
2012-11-02 06:15:34 +08:00
|
|
|
/// \brief Create a basic block that will call the trap intrinsic, and emit a
|
|
|
|
/// conditional branch to it, for the -ftrapv checks.
|
2013-01-30 07:31:22 +08:00
|
|
|
void EmitTrapCheck(llvm::Value *Checked);
|
2012-11-02 06:15:34 +08:00
|
|
|
|
2015-07-03 06:15:41 +08:00
|
|
|
/// \brief Emit a call to trap or debugtrap and attach function attribute
|
|
|
|
/// "trap-func-name" if specified.
|
|
|
|
llvm::CallInst *EmitTrapCall(llvm::Intrinsic::ID IntrID);
|
|
|
|
|
2017-04-08 07:00:38 +08:00
|
|
|
/// \brief Emit a stub for the cross-DSO CFI check function.
|
|
|
|
void EmitCfiCheckStub();
|
|
|
|
|
2016-01-26 07:34:52 +08:00
|
|
|
/// \brief Emit a cross-DSO CFI failure handling function.
|
|
|
|
void EmitCfiCheckFail();
|
|
|
|
|
2015-05-31 00:11:40 +08:00
|
|
|
/// \brief Create a check for a function parameter that may potentially be
|
|
|
|
/// declared as non-null.
|
|
|
|
void EmitNonNullArgCheck(RValue RV, QualType ArgType, SourceLocation ArgLoc,
|
2017-03-06 13:28:22 +08:00
|
|
|
AbstractCallee AC, unsigned ParmNum);
|
2015-05-31 00:11:40 +08:00
|
|
|
|
2010-03-30 11:27:09 +08:00
|
|
|
/// EmitCallArg - Emit a single call argument.
|
2011-03-12 04:59:21 +08:00
|
|
|
void EmitCallArg(CallArgList &args, const Expr *E, QualType ArgType);
|
2010-03-30 11:27:09 +08:00
|
|
|
|
2010-05-27 06:34:26 +08:00
|
|
|
/// EmitDelegateCallArg - We are performing a delegate call; that
|
|
|
|
/// is, the current function is delegating to another one. Produce
|
|
|
|
/// a r-value suitable for passing the given parameter.
|
2013-10-02 10:29:49 +08:00
|
|
|
void EmitDelegateCallArg(CallArgList &args, const VarDecl *param,
|
|
|
|
SourceLocation loc);
|
2010-05-27 06:34:26 +08:00
|
|
|
|
2011-10-28 03:19:51 +08:00
|
|
|
/// SetFPAccuracy - Set the minimum required accuracy of the given floating
|
|
|
|
/// point operation, expressed as the maximum relative error in ulp.
|
2012-04-10 16:23:07 +08:00
|
|
|
void SetFPAccuracy(llvm::Value *Val, float Accuracy);
|
2011-10-28 03:19:51 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
private:
|
2012-03-25 00:50:34 +08:00
|
|
|
llvm::MDNode *getRangeForLoadFromType(QualType Ty);
|
2008-09-24 12:00:38 +08:00
|
|
|
void EmitReturnOfRValue(RValue RV, QualType Ty);
|
|
|
|
|
2014-02-01 08:04:45 +08:00
|
|
|
void deferPlaceholderReplacement(llvm::Instruction *Old, llvm::Value *New);
|
|
|
|
|
|
|
|
llvm::SmallVector<std::pair<llvm::Instruction *, llvm::Value *>, 4>
|
|
|
|
DeferredReplacements;
|
|
|
|
|
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
|
|
|
/// Set the address of a local variable.
|
|
|
|
void setAddrOfLocalVar(const VarDecl *VD, Address Addr) {
|
|
|
|
assert(!LocalDeclMap.count(VD) && "Decl already exists in LocalDeclMap!");
|
|
|
|
LocalDeclMap.insert({VD, Addr});
|
|
|
|
}
|
|
|
|
|
2008-09-17 08:51:38 +08:00
|
|
|
/// ExpandTypeFromArgs - Reconstruct a structure of type \arg Ty
|
|
|
|
/// from function arguments into \arg Dst. See ABIArgInfo::Expand.
|
|
|
|
///
|
|
|
|
/// \param AI - The first function argument of the expansion.
|
CGCall: Factor out the logic mapping call arguments to LLVM IR arguments.
Summary:
This refactoring introduces ClangToLLVMArgMapping class, which
encapsulates the information about the order in which function arguments listed
in CGFunctionInfo should be passed to actual LLVM IR function, such as:
1) positions of sret, if there is any
2) position of inalloca argument, if there is any
3) position of helper padding argument for each call argument
4) positions of regular argument (there can be many if it's expanded).
Simplify several related methods (ConstructAttributeList, EmitFunctionProlog
and EmitCall): now they don't have to maintain iterators over the list
of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities,
and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping.
This may increase the running time of EmitFunctionProlog, as we have to traverse
expandable arguments twice, but in further refactoring we will be able
to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to
ConstructAttributeList, thus avoiding traversing expandable argument there.
No functionality change.
Test Plan: regression test suite
Reviewers: majnemer, rnk
Reviewed By: rnk
Subscribers: cfe-commits, rjmccall, timurrrr
Differential Revision: http://reviews.llvm.org/D4938
llvm-svn: 216251
2014-08-22 09:06:06 +08:00
|
|
|
void ExpandTypeFromArgs(QualType Ty, LValue Dst,
|
2016-04-05 02:33:08 +08:00
|
|
|
SmallVectorImpl<llvm::Value *>::iterator &AI);
|
CGCall: Factor out the logic mapping call arguments to LLVM IR arguments.
Summary:
This refactoring introduces ClangToLLVMArgMapping class, which
encapsulates the information about the order in which function arguments listed
in CGFunctionInfo should be passed to actual LLVM IR function, such as:
1) positions of sret, if there is any
2) position of inalloca argument, if there is any
3) position of helper padding argument for each call argument
4) positions of regular argument (there can be many if it's expanded).
Simplify several related methods (ConstructAttributeList, EmitFunctionProlog
and EmitCall): now they don't have to maintain iterators over the list
of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities,
and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping.
This may increase the running time of EmitFunctionProlog, as we have to traverse
expandable arguments twice, but in further refactoring we will be able
to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to
ConstructAttributeList, thus avoiding traversing expandable argument there.
No functionality change.
Test Plan: regression test suite
Reviewers: majnemer, rnk
Reviewed By: rnk
Subscribers: cfe-commits, rjmccall, timurrrr
Differential Revision: http://reviews.llvm.org/D4938
llvm-svn: 216251
2014-08-22 09:06:06 +08:00
|
|
|
|
|
|
|
/// ExpandTypeToArgs - Expand an RValue \arg RV, with the LLVM type for \arg
|
|
|
|
/// Ty, into individual arguments on the provided vector \arg IRCallArgs,
|
|
|
|
/// starting at index \arg IRCallArgPos. See ABIArgInfo::Expand.
|
|
|
|
void ExpandTypeToArgs(QualType Ty, RValue RV, llvm::FunctionType *IRFuncTy,
|
|
|
|
SmallVectorImpl<llvm::Value *> &IRCallArgs,
|
|
|
|
unsigned &IRCallArgPos);
|
2009-01-12 03:40:10 +08:00
|
|
|
|
2012-08-24 04:00:18 +08:00
|
|
|
llvm::Value* EmitAsmInput(const TargetInfo::ConstraintInfo &Info,
|
2009-01-12 03:40:10 +08:00
|
|
|
const Expr *InputExpr, std::string &ConstraintStr);
|
2009-02-09 07:14:22 +08:00
|
|
|
|
2012-08-24 04:00:18 +08:00
|
|
|
llvm::Value* EmitAsmInputLValue(const TargetInfo::ConstraintInfo &Info,
|
2010-07-16 08:55:21 +08:00
|
|
|
LValue InputValue, QualType InputType,
|
2013-10-02 10:29:49 +08:00
|
|
|
std::string &ConstraintStr,
|
|
|
|
SourceLocation Loc);
|
2010-07-16 08:55:21 +08:00
|
|
|
|
2015-12-03 05:58:08 +08:00
|
|
|
/// \brief Attempts to statically evaluate the object size of E. If that
|
|
|
|
/// fails, emits code to figure the size of E out for us. This is
|
|
|
|
/// pass_object_size aware.
|
2017-02-23 13:59:56 +08:00
|
|
|
///
|
|
|
|
/// If EmittedExpr is non-null, this will use that instead of re-emitting E.
|
2015-12-03 05:58:08 +08:00
|
|
|
llvm::Value *evaluateOrEmitBuiltinObjectSize(const Expr *E, unsigned Type,
|
2017-02-23 13:59:56 +08:00
|
|
|
llvm::IntegerType *ResType,
|
|
|
|
llvm::Value *EmittedE);
|
2015-12-03 05:58:08 +08:00
|
|
|
|
|
|
|
/// \brief Emits the size of E, as required by __builtin_object_size. This
|
|
|
|
/// function is aware of pass_object_size parameters, and will act accordingly
|
|
|
|
/// if E is a parameter with the pass_object_size attribute.
|
|
|
|
llvm::Value *emitBuiltinObjectSize(const Expr *E, unsigned Type,
|
2017-02-23 13:59:56 +08:00
|
|
|
llvm::IntegerType *ResType,
|
|
|
|
llvm::Value *EmittedE);
|
2015-12-03 05:58:08 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
public:
|
Substitute type arguments into uses of Objective-C interface members.
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
Example:
@interface NSSet<T : id<NSCopying>> : NSObject <NSCopying>
- (T)firstObject;
@end
void f(NSSet<NSString *> *stringSet, NSSet *anySet) {
[stringSet firstObject]; // produces NSString*
[anySet firstObject]; // produces id<NSCopying> (the bound)
}
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
llvm-svn: 241543
2015-07-07 11:57:53 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
// Determine whether the given argument is an Objective-C method
|
|
|
|
// that may have type parameters in its signature.
|
|
|
|
static bool isObjCMethodWithTypeParams(const ObjCMethodDecl *method) {
|
|
|
|
const DeclContext *dc = method->getDeclContext();
|
|
|
|
if (const ObjCInterfaceDecl *classDecl= dyn_cast<ObjCInterfaceDecl>(dc)) {
|
|
|
|
return classDecl->getTypeParamListAsWritten();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const ObjCCategoryDecl *catDecl = dyn_cast<ObjCCategoryDecl>(dc)) {
|
|
|
|
return catDecl->getTypeParamList();
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
static bool isObjCMethodWithTypeParams(const T *) { return false; }
|
|
|
|
#endif
|
|
|
|
|
Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.
We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.
Approach reviewed off-line by rnk.
llvm-svn: 282777
2016-09-30 05:30:12 +08:00
|
|
|
enum class EvaluationOrder {
|
|
|
|
///! No language constraints on evaluation order.
|
|
|
|
Default,
|
|
|
|
///! Language semantics require left-to-right evaluation.
|
|
|
|
ForceLeftToRight,
|
|
|
|
///! Language semantics require right-to-left evaluation.
|
|
|
|
ForceRightToLeft
|
|
|
|
};
|
|
|
|
|
2009-04-09 04:47:54 +08:00
|
|
|
/// EmitCallArgs - Emit call arguments for a function.
|
2013-12-05 03:23:12 +08:00
|
|
|
template <typename T>
|
|
|
|
void EmitCallArgs(CallArgList &Args, const T *CallArgTypeInfo,
|
2015-07-22 02:37:18 +08:00
|
|
|
llvm::iterator_range<CallExpr::const_arg_iterator> ArgRange,
|
2017-03-06 13:28:22 +08:00
|
|
|
AbstractCallee AC = AbstractCallee(),
|
2016-09-29 03:09:10 +08:00
|
|
|
unsigned ParamsToSkip = 0,
|
Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.
We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.
Approach reviewed off-line by rnk.
llvm-svn: 282777
2016-09-30 05:30:12 +08:00
|
|
|
EvaluationOrder Order = EvaluationOrder::Default) {
|
2013-12-05 03:23:12 +08:00
|
|
|
SmallVector<QualType, 16> ArgTypes;
|
2015-07-22 02:37:18 +08:00
|
|
|
CallExpr::const_arg_iterator Arg = ArgRange.begin();
|
2009-04-19 04:20:22 +08:00
|
|
|
|
2014-08-28 08:22:11 +08:00
|
|
|
assert((ParamsToSkip == 0 || CallArgTypeInfo) &&
|
|
|
|
"Can't skip parameters if type info is not provided");
|
|
|
|
if (CallArgTypeInfo) {
|
Substitute type arguments into uses of Objective-C interface members.
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
Example:
@interface NSSet<T : id<NSCopying>> : NSObject <NSCopying>
- (T)firstObject;
@end
void f(NSSet<NSString *> *stringSet, NSSet *anySet) {
[stringSet firstObject]; // produces NSString*
[anySet firstObject]; // produces id<NSCopying> (the bound)
}
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
llvm-svn: 241543
2015-07-07 11:57:53 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
bool isGenericMethod = isObjCMethodWithTypeParams(CallArgTypeInfo);
|
|
|
|
#endif
|
|
|
|
|
2014-08-28 08:22:11 +08:00
|
|
|
// First, use the argument types that the type info knows about
|
|
|
|
for (auto I = CallArgTypeInfo->param_type_begin() + ParamsToSkip,
|
|
|
|
E = CallArgTypeInfo->param_type_end();
|
|
|
|
I != E; ++I, ++Arg) {
|
2015-07-22 02:37:18 +08:00
|
|
|
assert(Arg != ArgRange.end() && "Running over edge of argument list!");
|
2015-07-07 21:25:57 +08:00
|
|
|
assert((isGenericMethod ||
|
|
|
|
((*I)->isVariablyModifiedType() ||
|
|
|
|
(*I).getNonReferenceType()->isObjCRetainableType() ||
|
|
|
|
getContext()
|
|
|
|
.getCanonicalType((*I).getNonReferenceType())
|
|
|
|
.getTypePtr() ==
|
|
|
|
getContext()
|
2015-07-18 22:35:53 +08:00
|
|
|
.getCanonicalType((*Arg)->getType())
|
2015-07-07 21:25:57 +08:00
|
|
|
.getTypePtr())) &&
|
|
|
|
"type mismatch in call argument!");
|
2014-08-28 08:22:11 +08:00
|
|
|
ArgTypes.push_back(*I);
|
|
|
|
}
|
2009-04-19 04:20:22 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-12-05 03:23:12 +08:00
|
|
|
// Either we've emitted all the call args, or we have a call to variadic
|
2014-08-28 08:22:11 +08:00
|
|
|
// function.
|
2015-07-22 02:37:18 +08:00
|
|
|
assert((Arg == ArgRange.end() || !CallArgTypeInfo ||
|
|
|
|
CallArgTypeInfo->isVariadic()) &&
|
|
|
|
"Extra arguments in non-variadic function!");
|
2013-12-05 03:23:12 +08:00
|
|
|
|
2009-04-19 04:20:22 +08:00
|
|
|
// If we still have any arguments, emit them using the type of the argument.
|
2015-07-22 02:59:10 +08:00
|
|
|
for (auto *A : llvm::make_range(Arg, ArgRange.end()))
|
[Win64] Don't widen integer literal zero arguments to unprototyped function calls
The special case to widen the integer literal zero when passed to
variadic function calls should only apply to variadic functions, not
unprototyped functions. This is consistent with what MSVC does. In this
test case, MSVC uses a 4-byte store to pass the 5th argument to 'kr' and
an 8-byte store to pass the zero to 'v':
void v(int, ...);
void kr();
void f(void) {
v(1, 2, 3, 4, 0);
kr(1, 2, 3, 4, 0);
}
Aaron Ballman discovered this issue in https://reviews.llvm.org/D28166
llvm-svn: 290906
2017-01-04 05:23:35 +08:00
|
|
|
ArgTypes.push_back(CallArgTypeInfo ? getVarArgType(A) : A->getType());
|
2013-07-27 04:42:57 +08:00
|
|
|
|
2017-03-06 13:28:22 +08:00
|
|
|
EmitCallArgs(Args, ArgTypes, ArgRange, AC, ParamsToSkip, Order);
|
2009-04-19 04:20:22 +08:00
|
|
|
}
|
2010-03-03 12:15:11 +08:00
|
|
|
|
2013-12-05 03:23:12 +08:00
|
|
|
void EmitCallArgs(CallArgList &Args, ArrayRef<QualType> ArgTypes,
|
2015-07-22 02:37:18 +08:00
|
|
|
llvm::iterator_range<CallExpr::const_arg_iterator> ArgRange,
|
2017-03-06 13:28:22 +08:00
|
|
|
AbstractCallee AC = AbstractCallee(),
|
2016-09-29 03:09:10 +08:00
|
|
|
unsigned ParamsToSkip = 0,
|
Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.
We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.
Approach reviewed off-line by rnk.
llvm-svn: 282777
2016-09-30 05:30:12 +08:00
|
|
|
EvaluationOrder Order = EvaluationOrder::Default);
|
2013-12-05 03:23:12 +08:00
|
|
|
|
2017-05-19 20:03:34 +08:00
|
|
|
/// EmitPointerWithAlignment - Given an expression with a pointer type,
|
|
|
|
/// emit the value and compute our best estimate of the alignment of the
|
|
|
|
/// pointee.
|
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
|
|
|
///
|
2017-05-19 20:03:34 +08:00
|
|
|
/// \param BaseInfo - If non-null, this will be initialized with
|
|
|
|
/// information about the source of the alignment and the may-alias
|
|
|
|
/// attribute. Note that this function will conservatively fall back on
|
|
|
|
/// the type when it doesn't recognize the expression and may-alias will
|
|
|
|
/// be set to false.
|
|
|
|
///
|
|
|
|
/// One reasonable way to use this information is when there's a language
|
|
|
|
/// guarantee that the pointer must be aligned to some stricter value, and
|
|
|
|
/// we're simply trying to ensure that sufficiently obvious uses of under-
|
|
|
|
/// aligned objects don't get miscompiled; for example, a placement new
|
|
|
|
/// into the address of a local variable. In such a case, it's quite
|
|
|
|
/// reasonable to just ignore the returned alignment when it isn't from an
|
|
|
|
/// explicit source.
|
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 EmitPointerWithAlignment(const Expr *Addr,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo = nullptr);
|
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
|
|
|
|
2016-01-16 08:31:22 +08:00
|
|
|
void EmitSanitizerStatReport(llvm::SanitizerStatKind SSK);
|
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
private:
|
2014-10-10 08:05:45 +08:00
|
|
|
QualType getVarArgType(const Expr *Arg);
|
|
|
|
|
2010-07-07 07:57:41 +08:00
|
|
|
void EmitDeclMetadata();
|
2011-03-31 16:03:29 +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
|
|
|
BlockByrefHelpers *buildByrefHelpers(llvm::StructType &byrefType,
|
|
|
|
const AutoVarEmission &emission);
|
2012-02-16 08:57:37 +08:00
|
|
|
|
|
|
|
void AddObjCARCExceptionMetadata(llvm::Instruction *Inst);
|
2012-03-03 02:34:30 +08:00
|
|
|
|
2014-12-04 12:52:37 +08:00
|
|
|
llvm::Value *GetValueForARMHint(unsigned BuiltinID);
|
2017-09-02 03:42:45 +08:00
|
|
|
llvm::Value *EmitX86CpuIs(const CallExpr *E);
|
|
|
|
llvm::Value *EmitX86CpuIs(StringRef CPUStr);
|
|
|
|
llvm::Value *EmitX86CpuSupports(const CallExpr *E);
|
|
|
|
llvm::Value *EmitX86CpuSupports(ArrayRef<StringRef> FeatureStrs);
|
2007-05-24 14:29:05 +08:00
|
|
|
};
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
/// Helper class with most of the code for saving a value for a
|
|
|
|
/// conditional expression cleanup.
|
2011-01-28 18:53:53 +08:00
|
|
|
struct DominatingLLVMValue {
|
2011-01-26 12:00:11 +08:00
|
|
|
typedef llvm::PointerIntPair<llvm::Value*, 1, bool> saved_type;
|
|
|
|
|
|
|
|
/// Answer whether the given value needs extra work to be saved.
|
|
|
|
static bool needsSaving(llvm::Value *value) {
|
|
|
|
// If it's not an instruction, we don't need to save.
|
|
|
|
if (!isa<llvm::Instruction>(value)) return false;
|
|
|
|
|
|
|
|
// If it's an instruction in the entry block, we don't need to save.
|
|
|
|
llvm::BasicBlock *block = cast<llvm::Instruction>(value)->getParent();
|
|
|
|
return (block != &block->getParent()->getEntryBlock());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Try to save the given value.
|
|
|
|
static saved_type save(CodeGenFunction &CGF, llvm::Value *value) {
|
|
|
|
if (!needsSaving(value)) return saved_type(value, false);
|
|
|
|
|
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
|
|
|
// Otherwise, we need an alloca.
|
|
|
|
auto align = CharUnits::fromQuantity(
|
|
|
|
CGF.CGM.getDataLayout().getPrefTypeAlignment(value->getType()));
|
|
|
|
Address alloca =
|
|
|
|
CGF.CreateTempAlloca(value->getType(), align, "cond-cleanup.save");
|
2011-01-26 12:00:11 +08:00
|
|
|
CGF.Builder.CreateStore(value, alloca);
|
|
|
|
|
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 saved_type(alloca.getPointer(), true);
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static llvm::Value *restore(CodeGenFunction &CGF, saved_type 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
|
|
|
// If the value says it wasn't saved, trust that it's still dominating.
|
2011-01-26 12:00:11 +08:00
|
|
|
if (!value.getInt()) return value.getPointer();
|
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
|
|
|
|
|
|
|
// Otherwise, it should be an alloca instruction, as set up in save().
|
|
|
|
auto alloca = cast<llvm::AllocaInst>(value.getPointer());
|
|
|
|
return CGF.Builder.CreateAlignedLoad(alloca, alloca->getAlignment());
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2011-01-28 18:53:53 +08:00
|
|
|
/// A partial specialization of DominatingValue for llvm::Values that
|
|
|
|
/// might be llvm::Instructions.
|
|
|
|
template <class T> struct DominatingPointer<T,true> : DominatingLLVMValue {
|
|
|
|
typedef T *type;
|
|
|
|
static type restore(CodeGenFunction &CGF, saved_type value) {
|
|
|
|
return static_cast<T*>(DominatingLLVMValue::restore(CGF, 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
|
|
|
/// A specialization of DominatingValue for Address.
|
|
|
|
template <> struct DominatingValue<Address> {
|
|
|
|
typedef Address type;
|
|
|
|
|
|
|
|
struct saved_type {
|
|
|
|
DominatingLLVMValue::saved_type SavedValue;
|
|
|
|
CharUnits Alignment;
|
|
|
|
};
|
|
|
|
|
|
|
|
static bool needsSaving(type value) {
|
|
|
|
return DominatingLLVMValue::needsSaving(value.getPointer());
|
|
|
|
}
|
|
|
|
static saved_type save(CodeGenFunction &CGF, type value) {
|
|
|
|
return { DominatingLLVMValue::save(CGF, value.getPointer()),
|
|
|
|
value.getAlignment() };
|
|
|
|
}
|
|
|
|
static type restore(CodeGenFunction &CGF, saved_type value) {
|
|
|
|
return Address(DominatingLLVMValue::restore(CGF, value.SavedValue),
|
|
|
|
value.Alignment);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2011-01-28 18:53:53 +08:00
|
|
|
/// A specialization of DominatingValue for RValue.
|
|
|
|
template <> struct DominatingValue<RValue> {
|
|
|
|
typedef RValue type;
|
|
|
|
class saved_type {
|
|
|
|
enum Kind { ScalarLiteral, ScalarAddress, AggregateLiteral,
|
|
|
|
AggregateAddress, ComplexAddress };
|
|
|
|
|
|
|
|
llvm::Value *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
|
|
|
unsigned K : 3;
|
|
|
|
unsigned Align : 29;
|
|
|
|
saved_type(llvm::Value *v, Kind k, unsigned a = 0)
|
|
|
|
: Value(v), K(k), Align(a) {}
|
2011-01-28 18:53:53 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
static bool needsSaving(RValue value);
|
|
|
|
static saved_type save(CodeGenFunction &CGF, RValue value);
|
|
|
|
RValue restore(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
|
|
|
// implementations in CGCleanup.cpp
|
2011-01-28 18:53:53 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static bool needsSaving(type value) {
|
|
|
|
return saved_type::needsSaving(value);
|
|
|
|
}
|
|
|
|
static saved_type save(CodeGenFunction &CGF, type value) {
|
|
|
|
return saved_type::save(CGF, value);
|
|
|
|
}
|
2011-01-26 12:00:11 +08:00
|
|
|
static type restore(CodeGenFunction &CGF, saved_type value) {
|
2011-01-28 18:53:53 +08:00
|
|
|
return value.restore(CGF);
|
2011-01-26 12:00:11 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2007-05-24 14:29:05 +08:00
|
|
|
} // end namespace CodeGen
|
|
|
|
} // end namespace clang
|
2012-01-30 04:27:13 +08:00
|
|
|
|
2007-05-24 14:29:05 +08:00
|
|
|
#endif
|