2007-05-28 09:07:47 +08:00
|
|
|
//===--- CodeGenFunction.cpp - Emit LLVM Code from ASTs for a Function ----===//
|
|
|
|
//
|
|
|
|
// 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-28 09:07:47 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This coordinates the per-function state used while generating code.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CodeGenFunction.h"
|
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
|
|
|
#include "CGBlocks.h"
|
2016-04-09 00:52:00 +08:00
|
|
|
#include "CGCleanup.h"
|
2011-10-07 02:51:56 +08:00
|
|
|
#include "CGCUDARuntime.h"
|
2010-08-31 15:33:07 +08:00
|
|
|
#include "CGCXXABI.h"
|
2008-05-22 09:40:10 +08:00
|
|
|
#include "CGDebugInfo.h"
|
2014-05-06 18:08:46 +08:00
|
|
|
#include "CGOpenMPRuntime.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "CodeGenModule.h"
|
2014-01-07 06:27:43 +08:00
|
|
|
#include "CodeGenPGO.h"
|
2013-10-21 05:29:19 +08:00
|
|
|
#include "TargetInfo.h"
|
2008-08-11 13:00:27 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2008-08-11 13:35:13 +08:00
|
|
|
#include "clang/AST/Decl.h"
|
2009-04-05 04:47:02 +08:00
|
|
|
#include "clang/AST/DeclCXX.h"
|
2009-12-05 07:26:17 +08:00
|
|
|
#include "clang/AST/StmtCXX.h"
|
2016-09-17 07:30:39 +08:00
|
|
|
#include "clang/AST/StmtObjC.h"
|
2015-09-03 04:01:30 +08:00
|
|
|
#include "clang/Basic/Builtins.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/Basic/TargetInfo.h"
|
2013-10-31 05:53:58 +08:00
|
|
|
#include "clang/CodeGen/CGFunctionInfo.h"
|
2016-04-09 00:52:00 +08:00
|
|
|
#include "clang/Frontend/CodeGenOptions.h"
|
2015-11-12 08:44:07 +08:00
|
|
|
#include "clang/Sema/SemaDiagnostic.h"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/MDBuilder.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
2007-05-28 09:07:47 +08:00
|
|
|
using namespace clang;
|
|
|
|
using namespace CodeGen;
|
|
|
|
|
2016-10-26 09:59:57 +08:00
|
|
|
/// shouldEmitLifetimeMarkers - Decide whether we need emit the life-time
|
|
|
|
/// markers.
|
|
|
|
static bool shouldEmitLifetimeMarkers(const CodeGenOptions &CGOpts,
|
|
|
|
const LangOptions &LangOpts) {
|
2017-01-07 07:18:09 +08:00
|
|
|
if (CGOpts.DisableLifetimeMarkers)
|
|
|
|
return false;
|
|
|
|
|
2016-10-26 09:59:57 +08:00
|
|
|
// Asan uses markers for use-after-scope checks.
|
|
|
|
if (CGOpts.SanitizeAddressUseAfterScope)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Disable lifetime markers in msan builds.
|
|
|
|
// FIXME: Remove this when msan works with lifetime markers.
|
|
|
|
if (LangOpts.Sanitize.has(SanitizerKind::Memory))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// For now, only in optimized builds.
|
|
|
|
return CGOpts.OptimizationLevel != 0;
|
|
|
|
}
|
|
|
|
|
2012-06-27 00:06:38 +08:00
|
|
|
CodeGenFunction::CodeGenFunction(CodeGenModule &cgm, bool suppressNewContext)
|
2013-08-27 04:33:21 +08:00
|
|
|
: CodeGenTypeCache(cgm), CGM(cgm), Target(cgm.getTarget()),
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder(cgm, cgm.getModule().getContext(), llvm::ConstantFolder(),
|
2014-10-15 01:09:38 +08:00
|
|
|
CGBuilderInserterTy(this)),
|
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
|
|
|
CurFn(nullptr), ReturnValue(Address::invalid()),
|
2016-10-26 09:59:57 +08:00
|
|
|
CapturedStmtInfo(nullptr), SanOpts(CGM.getLangOpts().Sanitize),
|
|
|
|
IsSanitizerScope(false), CurFuncIsThunk(false), AutoreleaseResult(false),
|
|
|
|
SawAsmBlock(false), IsOutlinedSEHHelper(false), BlockInfo(nullptr),
|
|
|
|
BlockPointer(nullptr), LambdaThisCaptureField(nullptr),
|
|
|
|
NormalCleanupDest(nullptr), NextCleanupDestIndex(1),
|
|
|
|
FirstBlockInfo(nullptr), EHResumeBlock(nullptr), ExceptionSlot(nullptr),
|
|
|
|
EHSelectorSlot(nullptr), DebugInfo(CGM.getModuleDebugInfo()),
|
2015-07-07 08:36:30 +08:00
|
|
|
DisableDebugInfo(false), DidCallStackSave(false), IndirectBranch(nullptr),
|
|
|
|
PGO(cgm), SwitchInsn(nullptr), SwitchWeights(nullptr),
|
|
|
|
CaseRangeBlock(nullptr), UnreachableBlock(nullptr), NumReturnExprs(0),
|
|
|
|
NumSimpleReturnExprs(0), CXXABIThisDecl(nullptr),
|
|
|
|
CXXABIThisValue(nullptr), CXXThisValue(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
|
|
|
CXXStructorImplicitParamDecl(nullptr),
|
2014-05-21 13:09:00 +08:00
|
|
|
CXXStructorImplicitParamValue(nullptr), OutermostConditional(nullptr),
|
|
|
|
CurLexicalScope(nullptr), TerminateLandingPad(nullptr),
|
2016-10-26 09:59:57 +08:00
|
|
|
TerminateHandler(nullptr), TrapBB(nullptr),
|
|
|
|
ShouldEmitLifetimeMarkers(
|
|
|
|
shouldEmitLifetimeMarkers(CGM.getCodeGenOpts(), CGM.getLangOpts())) {
|
2012-06-27 00:06:38 +08:00
|
|
|
if (!suppressNewContext)
|
|
|
|
CGM.getCXXABI().getMangleContext().startNewFunction();
|
2012-12-04 08:36:06 +08:00
|
|
|
|
|
|
|
llvm::FastMathFlags FMF;
|
|
|
|
if (CGM.getLangOpts().FastMath)
|
2012-12-10 05:58:24 +08:00
|
|
|
FMF.setUnsafeAlgebra();
|
2012-12-04 08:36:06 +08:00
|
|
|
if (CGM.getLangOpts().FiniteMathOnly) {
|
2012-12-10 05:58:24 +08:00
|
|
|
FMF.setNoNaNs();
|
|
|
|
FMF.setNoInfs();
|
2012-12-04 08:36:06 +08:00
|
|
|
}
|
2014-12-11 00:41:14 +08:00
|
|
|
if (CGM.getCodeGenOpts().NoNaNsFPMath) {
|
|
|
|
FMF.setNoNaNs();
|
|
|
|
}
|
|
|
|
if (CGM.getCodeGenOpts().NoSignedZeros) {
|
|
|
|
FMF.setNoSignedZeros();
|
|
|
|
}
|
2015-04-09 23:03:23 +08:00
|
|
|
if (CGM.getCodeGenOpts().ReciprocalMath) {
|
|
|
|
FMF.setAllowReciprocal();
|
|
|
|
}
|
2016-01-13 02:03:41 +08:00
|
|
|
Builder.setFastMathFlags(FMF);
|
2008-06-18 02:05:57 +08:00
|
|
|
}
|
2007-05-30 07:17:50 +08:00
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
CodeGenFunction::~CodeGenFunction() {
|
2013-06-13 04:42:33 +08:00
|
|
|
assert(LifetimeExtendedCleanupStack.empty() && "failed to emit a cleanup");
|
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
// If there are any unclaimed block infos, go ahead and destroy them
|
|
|
|
// now. This can happen if IR-gen gets clever and skips evaluating
|
|
|
|
// something.
|
|
|
|
if (FirstBlockInfo)
|
|
|
|
destroyBlockInfos(FirstBlockInfo);
|
2014-05-06 18:08:46 +08:00
|
|
|
|
2017-01-20 16:57:28 +08:00
|
|
|
if (getLangOpts().OpenMP && CurFn)
|
2015-02-25 16:32:46 +08:00
|
|
|
CGM.getOpenMPRuntime().functionFinished(*this);
|
2011-11-10 16:15:53 +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
|
|
|
CharUnits CodeGenFunction::getNaturalPointeeTypeAlignment(QualType T,
|
|
|
|
AlignmentSource *Source) {
|
|
|
|
return getNaturalTypeAlignment(T->getPointeeType(), Source,
|
|
|
|
/*forPointee*/ true);
|
|
|
|
}
|
|
|
|
|
|
|
|
CharUnits CodeGenFunction::getNaturalTypeAlignment(QualType T,
|
|
|
|
AlignmentSource *Source,
|
|
|
|
bool forPointeeType) {
|
|
|
|
// Honor alignment typedef attributes even on incomplete types.
|
|
|
|
// We also honor them straight for C++ class types, even as pointees;
|
|
|
|
// there's an expressivity gap here.
|
|
|
|
if (auto TT = T->getAs<TypedefType>()) {
|
|
|
|
if (auto Align = TT->getDecl()->getMaxAlignment()) {
|
|
|
|
if (Source) *Source = AlignmentSource::AttributedType;
|
|
|
|
return getContext().toCharUnitsFromBits(Align);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Source) *Source = AlignmentSource::Type;
|
|
|
|
|
2014-09-19 06:05:54 +08:00
|
|
|
CharUnits Alignment;
|
2015-09-11 05:52:00 +08:00
|
|
|
if (T->isIncompleteType()) {
|
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
|
|
|
Alignment = CharUnits::One(); // Shouldn't be used, but pessimistic is best.
|
|
|
|
} else {
|
|
|
|
// For C++ class pointees, we don't know whether we're pointing at a
|
|
|
|
// base or a complete object, so we generally need to use the
|
|
|
|
// non-virtual alignment.
|
|
|
|
const CXXRecordDecl *RD;
|
|
|
|
if (forPointeeType && (RD = T->getAsCXXRecordDecl())) {
|
|
|
|
Alignment = CGM.getClassPointerAlignment(RD);
|
|
|
|
} else {
|
|
|
|
Alignment = getContext().getTypeAlignInChars(T);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Cap to the global maximum type alignment unless the alignment
|
|
|
|
// was somehow explicit on the type.
|
|
|
|
if (unsigned MaxAlign = getLangOpts().MaxTypeAlign) {
|
|
|
|
if (Alignment.getQuantity() > MaxAlign &&
|
|
|
|
!getContext().isAlignmentRequired(T))
|
|
|
|
Alignment = CharUnits::fromQuantity(MaxAlign);
|
|
|
|
}
|
2014-09-19 06:05:54 +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 Alignment;
|
|
|
|
}
|
|
|
|
|
|
|
|
LValue CodeGenFunction::MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T) {
|
|
|
|
AlignmentSource AlignSource;
|
|
|
|
CharUnits Alignment = getNaturalTypeAlignment(T, &AlignSource);
|
|
|
|
return LValue::MakeAddr(Address(V, Alignment), T, getContext(), AlignSource,
|
|
|
|
CGM.getTBAAInfo(T));
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Given a value of type T* that may not be to a complete object,
|
|
|
|
/// construct an l-value with the natural pointee alignment of T.
|
|
|
|
LValue
|
|
|
|
CodeGenFunction::MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T) {
|
|
|
|
AlignmentSource AlignSource;
|
|
|
|
CharUnits Align = getNaturalTypeAlignment(T, &AlignSource, /*pointee*/ true);
|
|
|
|
return MakeAddrLValue(Address(V, Align), T, AlignSource);
|
2014-09-19 06:05:54 +08:00
|
|
|
}
|
2007-05-30 07:17:50 +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
|
|
|
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::Type *CodeGenFunction::ConvertTypeForMem(QualType T) {
|
2009-02-04 07:03:55 +08:00
|
|
|
return CGM.getTypes().ConvertTypeForMem(T);
|
|
|
|
}
|
|
|
|
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::Type *CodeGenFunction::ConvertType(QualType T) {
|
2007-06-23 03:05:19 +08:00
|
|
|
return CGM.getTypes().ConvertType(T);
|
2007-06-09 10:28:57 +08:00
|
|
|
}
|
2007-05-30 07:17:50 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
TypeEvaluationKind CodeGenFunction::getEvaluationKind(QualType type) {
|
|
|
|
type = type.getCanonicalType();
|
|
|
|
while (true) {
|
|
|
|
switch (type->getTypeClass()) {
|
2011-05-15 10:34:36 +08:00
|
|
|
#define TYPE(name, parent)
|
|
|
|
#define ABSTRACT_TYPE(name, parent)
|
|
|
|
#define NON_CANONICAL_TYPE(name, parent) case Type::name:
|
|
|
|
#define DEPENDENT_TYPE(name, parent) case Type::name:
|
|
|
|
#define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(name, parent) case Type::name:
|
|
|
|
#include "clang/AST/TypeNodes.def"
|
2013-03-08 05:37:08 +08:00
|
|
|
llvm_unreachable("non-canonical or dependent type in IR-generation");
|
|
|
|
|
2013-04-30 21:56:41 +08:00
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
|
|
|
llvm_unreachable("undeduced type in IR-generation");
|
2013-04-30 21:56:41 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
// Various scalar types.
|
|
|
|
case Type::Builtin:
|
|
|
|
case Type::Pointer:
|
|
|
|
case Type::BlockPointer:
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
case Type::MemberPointer:
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::FunctionProto:
|
|
|
|
case Type::FunctionNoProto:
|
|
|
|
case Type::Enum:
|
|
|
|
case Type::ObjCObjectPointer:
|
2016-01-09 20:53:17 +08:00
|
|
|
case Type::Pipe:
|
2013-03-08 05:37:08 +08:00
|
|
|
return TEK_Scalar;
|
|
|
|
|
|
|
|
// Complexes.
|
|
|
|
case Type::Complex:
|
|
|
|
return TEK_Complex;
|
|
|
|
|
|
|
|
// Arrays, records, and Objective-C objects.
|
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
case Type::VariableArray:
|
|
|
|
case Type::Record:
|
|
|
|
case Type::ObjCObject:
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
return TEK_Aggregate;
|
|
|
|
|
|
|
|
// We operate on atomic values according to their underlying type.
|
|
|
|
case Type::Atomic:
|
|
|
|
type = cast<AtomicType>(type)->getValueType();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown type kind!");
|
2011-05-15 10:34:36 +08:00
|
|
|
}
|
2008-06-18 02:05:57 +08:00
|
|
|
}
|
2008-03-31 07:03:07 +08:00
|
|
|
|
2015-01-14 15:38:27 +08:00
|
|
|
llvm::DebugLoc CodeGenFunction::EmitReturnBlock() {
|
2009-01-27 07:27:52 +08:00
|
|
|
// For cleanliness, we try to avoid emitting the return block for
|
|
|
|
// simple cases.
|
|
|
|
llvm::BasicBlock *CurBB = Builder.GetInsertBlock();
|
|
|
|
|
|
|
|
if (CurBB) {
|
|
|
|
assert(!CurBB->getTerminator() && "Unexpected terminated block.");
|
|
|
|
|
2009-07-19 16:24:34 +08:00
|
|
|
// We have a valid insert point, reuse it if it is empty or there are no
|
|
|
|
// explicit jumps to the return block.
|
2010-07-24 05:56:41 +08:00
|
|
|
if (CurBB->empty() || ReturnBlock.getBlock()->use_empty()) {
|
|
|
|
ReturnBlock.getBlock()->replaceAllUsesWith(CurBB);
|
|
|
|
delete ReturnBlock.getBlock();
|
2009-07-19 16:24:34 +08:00
|
|
|
} else
|
2010-07-24 05:56:41 +08:00
|
|
|
EmitBlock(ReturnBlock.getBlock());
|
2015-01-14 15:38:27 +08:00
|
|
|
return llvm::DebugLoc();
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, if the return block is the target of a single direct
|
|
|
|
// branch then we can just put the code in that block instead. This
|
|
|
|
// cleans up functions which started with a unified return block.
|
2010-07-24 05:56:41 +08:00
|
|
|
if (ReturnBlock.getBlock()->hasOneUse()) {
|
2009-09-09 23:08:12 +08:00
|
|
|
llvm::BranchInst *BI =
|
2014-03-09 11:16:50 +08:00
|
|
|
dyn_cast<llvm::BranchInst>(*ReturnBlock.getBlock()->user_begin());
|
2010-07-06 09:34:17 +08:00
|
|
|
if (BI && BI->isUnconditional() &&
|
2010-07-24 05:56:41 +08:00
|
|
|
BI->getSuccessor(0) == ReturnBlock.getBlock()) {
|
2015-01-14 15:38:27 +08:00
|
|
|
// Record/return the DebugLoc of the simple 'return' expression to be used
|
|
|
|
// later by the actual 'ret' instruction.
|
|
|
|
llvm::DebugLoc Loc = BI->getDebugLoc();
|
2009-01-27 07:27:52 +08:00
|
|
|
Builder.SetInsertPoint(BI->getParent());
|
|
|
|
BI->eraseFromParent();
|
2010-07-24 05:56:41 +08:00
|
|
|
delete ReturnBlock.getBlock();
|
2015-01-14 15:38:27 +08:00
|
|
|
return Loc;
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-05-16 15:57:57 +08:00
|
|
|
// FIXME: We are at an unreachable point, there is no reason to emit the block
|
|
|
|
// unless it has uses. However, we still need a place to put the debug
|
|
|
|
// region.end for now.
|
2009-01-27 07:27:52 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
EmitBlock(ReturnBlock.getBlock());
|
2015-01-14 15:38:27 +08:00
|
|
|
return llvm::DebugLoc();
|
2010-07-06 09:34:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void EmitIfUsed(CodeGenFunction &CGF, llvm::BasicBlock *BB) {
|
|
|
|
if (!BB) return;
|
|
|
|
if (!BB->use_empty())
|
|
|
|
return CGF.CurFn->getBasicBlockList().push_back(BB);
|
|
|
|
delete BB;
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
|
2008-08-26 16:29:31 +08:00
|
|
|
void CodeGenFunction::FinishFunction(SourceLocation EndLoc) {
|
2008-03-31 07:03:07 +08:00
|
|
|
assert(BreakContinueStack.empty() &&
|
|
|
|
"mismatched push/pop in break/continue stack!");
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-05-04 04:11:48 +08:00
|
|
|
bool OnlySimpleReturnStmts = NumSimpleReturnExprs > 0
|
2013-07-25 08:23:42 +08:00
|
|
|
&& NumSimpleReturnExprs == NumReturnExprs
|
|
|
|
&& ReturnBlock.getBlock()->use_empty();
|
|
|
|
// Usually the return expression is evaluated before the cleanup
|
|
|
|
// code. If the function contains only a simple return statement,
|
|
|
|
// such as a constant, the location before the cleanup code becomes
|
|
|
|
// the last useful breakpoint in the function, because the simple
|
|
|
|
// return expression will be evaluated after the cleanup code. To be
|
|
|
|
// safe, set the debug location for cleanup code to the location of
|
|
|
|
// the return statement. Otherwise the cleanup code should be at the
|
|
|
|
// end of the function's lexical scope.
|
|
|
|
//
|
|
|
|
// If there are multiple branches to the return block, the branch
|
|
|
|
// instructions will get the location of the return statements and
|
|
|
|
// all will be fine.
|
2013-05-03 01:30:20 +08:00
|
|
|
if (CGDebugInfo *DI = getDebugInfo()) {
|
2013-05-04 04:11:48 +08:00
|
|
|
if (OnlySimpleReturnStmts)
|
2014-01-08 06:05:52 +08:00
|
|
|
DI->EmitLocation(Builder, LastStopPoint);
|
2013-05-03 01:30:20 +08:00
|
|
|
else
|
2014-01-08 06:05:52 +08:00
|
|
|
DI->EmitLocation(Builder, EndLoc);
|
2013-05-03 01:30:20 +08:00
|
|
|
}
|
2013-02-02 03:09:49 +08:00
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
// Pop any cleanups that might have been associated with the
|
|
|
|
// parameters. Do this in whatever block we're currently in; it's
|
|
|
|
// important to do this before we enter the return block or return
|
|
|
|
// edges will be *really* confused.
|
2015-04-23 05:38:15 +08:00
|
|
|
bool HasCleanups = EHStack.stable_begin() != PrologueCleanupDepth;
|
|
|
|
bool HasOnlyLifetimeMarkers =
|
|
|
|
HasCleanups && EHStack.containsOnlyLifetimeMarkers(PrologueCleanupDepth);
|
|
|
|
bool EmitRetDbgLoc = !HasCleanups || HasOnlyLifetimeMarkers;
|
|
|
|
if (HasCleanups) {
|
2013-05-03 01:30:20 +08:00
|
|
|
// Make sure the line table doesn't jump back into the body for
|
|
|
|
// the ret after it's been at EndLoc.
|
|
|
|
if (CGDebugInfo *DI = getDebugInfo())
|
2013-05-04 04:11:48 +08:00
|
|
|
if (OnlySimpleReturnStmts)
|
2014-01-08 06:05:52 +08:00
|
|
|
DI->EmitLocation(Builder, EndLoc);
|
2015-02-05 03:47:54 +08:00
|
|
|
|
|
|
|
PopCleanupBlocks(PrologueCleanupDepth);
|
2013-05-03 01:30:20 +08:00
|
|
|
}
|
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
// Emit function epilog (to return).
|
2015-01-14 15:38:27 +08:00
|
|
|
llvm::DebugLoc Loc = EmitReturnBlock();
|
2008-11-12 04:59:54 +08:00
|
|
|
|
2011-02-11 01:32:22 +08:00
|
|
|
if (ShouldInstrumentFunction())
|
|
|
|
EmitFunctionInstrumentation("__cyg_profile_func_exit");
|
2010-06-22 08:03:40 +08:00
|
|
|
|
2008-11-12 04:59:54 +08:00
|
|
|
// Emit debug descriptor for function end.
|
2015-01-14 15:38:27 +08:00
|
|
|
if (CGDebugInfo *DI = getDebugInfo())
|
2010-07-23 06:29:16 +08:00
|
|
|
DI->EmitFunctionEnd(Builder);
|
2008-11-12 04:59:54 +08:00
|
|
|
|
2015-01-14 15:38:27 +08:00
|
|
|
// Reset the debug location to that of the simple 'return' expression, if any
|
|
|
|
// rather than that of the end of the function's scope '}'.
|
|
|
|
ApplyDebugLocation AL(*this, Loc);
|
2013-10-02 10:29:49 +08:00
|
|
|
EmitFunctionEpilog(*CurFnInfo, EmitRetDbgLoc, EndLoc);
|
2009-12-08 07:38:24 +08:00
|
|
|
EmitEndEHSpec(CurCodeDecl);
|
2008-09-10 05:00:17 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
assert(EHStack.empty() &&
|
|
|
|
"did not remove all scopes from cleanup stack!");
|
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// If someone did an indirect goto, emit the indirect goto block at the end of
|
|
|
|
// the function.
|
|
|
|
if (IndirectBranch) {
|
|
|
|
EmitBlock(IndirectBranch->getParent());
|
|
|
|
Builder.ClearInsertionPoint();
|
2015-04-09 06:23:48 +08:00
|
|
|
}
|
|
|
|
|
2015-07-08 06:26:07 +08:00
|
|
|
// If some of our locals escaped, insert a call to llvm.localescape in the
|
2015-04-09 06:23:48 +08:00
|
|
|
// entry block.
|
|
|
|
if (!EscapedLocals.empty()) {
|
|
|
|
// Invert the map from local to index into a simple vector. There should be
|
|
|
|
// no holes.
|
|
|
|
SmallVector<llvm::Value *, 4> EscapeArgs;
|
|
|
|
EscapeArgs.resize(EscapedLocals.size());
|
|
|
|
for (auto &Pair : EscapedLocals)
|
|
|
|
EscapeArgs[Pair.second] = Pair.first;
|
|
|
|
llvm::Function *FrameEscapeFn = llvm::Intrinsic::getDeclaration(
|
2015-07-08 06:26:07 +08:00
|
|
|
&CGM.getModule(), llvm::Intrinsic::localescape);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CGBuilderTy(*this, AllocaInsertPt).CreateCall(FrameEscapeFn, EscapeArgs);
|
2009-10-29 07:59:40 +08:00
|
|
|
}
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2008-03-31 07:03:07 +08:00
|
|
|
// Remove the AllocaInsertPt instruction, which is just a convenience for us.
|
2009-04-01 06:17:44 +08:00
|
|
|
llvm::Instruction *Ptr = AllocaInsertPt;
|
2014-05-21 13:09:00 +08:00
|
|
|
AllocaInsertPt = nullptr;
|
2009-04-01 06:17:44 +08:00
|
|
|
Ptr->eraseFromParent();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// If someone took the address of a label but never did an indirect goto, we
|
|
|
|
// made a zero entry PHI node, which is illegal, zap it now.
|
|
|
|
if (IndirectBranch) {
|
|
|
|
llvm::PHINode *PN = cast<llvm::PHINode>(IndirectBranch->getAddress());
|
|
|
|
if (PN->getNumIncomingValues() == 0) {
|
|
|
|
PN->replaceAllUsesWith(llvm::UndefValue::get(PN->getType()));
|
|
|
|
PN->eraseFromParent();
|
|
|
|
}
|
|
|
|
}
|
2010-07-06 09:34:17 +08:00
|
|
|
|
2011-08-11 10:22:43 +08:00
|
|
|
EmitIfUsed(*this, EHResumeBlock);
|
2010-07-06 09:34:17 +08:00
|
|
|
EmitIfUsed(*this, TerminateLandingPad);
|
|
|
|
EmitIfUsed(*this, TerminateHandler);
|
|
|
|
EmitIfUsed(*this, UnreachableBlock);
|
2010-07-07 07:57:41 +08:00
|
|
|
|
|
|
|
if (CGM.getCodeGenOpts().EmitDeclMetadata)
|
|
|
|
EmitDeclMetadata();
|
2014-02-01 08:04:45 +08:00
|
|
|
|
|
|
|
for (SmallVectorImpl<std::pair<llvm::Instruction *, llvm::Value *> >::iterator
|
|
|
|
I = DeferredReplacements.begin(),
|
|
|
|
E = DeferredReplacements.end();
|
|
|
|
I != E; ++I) {
|
|
|
|
I->first->replaceAllUsesWith(I->second);
|
|
|
|
I->first->eraseFromParent();
|
|
|
|
}
|
2008-04-04 12:07:35 +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 CodeGenFunction::ShouldInstrumentFunction() {
|
|
|
|
if (!CGM.getCodeGenOpts().InstrumentFunctions)
|
|
|
|
return false;
|
2011-05-17 07:49:20 +08:00
|
|
|
if (!CurFuncDecl || CurFuncDecl->hasAttr<NoInstrumentFunctionAttr>())
|
2010-06-22 08:03:40 +08:00
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-07-14 06:32:15 +08:00
|
|
|
/// ShouldXRayInstrument - Return true if the current function should be
|
|
|
|
/// instrumented with XRay nop sleds.
|
|
|
|
bool CodeGenFunction::ShouldXRayInstrumentFunction() const {
|
|
|
|
return CGM.getCodeGenOpts().XRayInstrumentFunctions;
|
|
|
|
}
|
|
|
|
|
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 CodeGenFunction::EmitFunctionInstrumentation(const char *Fn) {
|
2016-04-29 01:21:56 +08:00
|
|
|
auto NL = ApplyDebugLocation::CreateArtificial(*this);
|
2010-06-23 13:21:28 +08:00
|
|
|
// void __cyg_profile_func_{enter,exit} (void *this_fn, void *call_site);
|
2011-07-10 01:41:47 +08:00
|
|
|
llvm::PointerType *PointerTy = Int8PtrTy;
|
|
|
|
llvm::Type *ProfileFuncArgs[] = { PointerTy, PointerTy };
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::FunctionType *FunctionTy =
|
2012-02-07 08:39:47 +08:00
|
|
|
llvm::FunctionType::get(VoidTy, ProfileFuncArgs, false);
|
2010-06-22 08:03:40 +08:00
|
|
|
|
|
|
|
llvm::Constant *F = CGM.CreateRuntimeFunction(FunctionTy, Fn);
|
|
|
|
llvm::CallInst *CallSite = Builder.CreateCall(
|
2011-07-15 01:45:50 +08:00
|
|
|
CGM.getIntrinsic(llvm::Intrinsic::returnaddress),
|
2010-06-27 15:15:29 +08:00
|
|
|
llvm::ConstantInt::get(Int32Ty, 0),
|
2010-06-22 08:03:40 +08:00
|
|
|
"callsite");
|
|
|
|
|
2013-03-01 03:01:20 +08:00
|
|
|
llvm::Value *args[] = {
|
|
|
|
llvm::ConstantExpr::getBitCast(CurFn, PointerTy),
|
|
|
|
CallSite
|
|
|
|
};
|
|
|
|
|
|
|
|
EmitNounwindRuntimeCall(F, args);
|
2010-06-22 08:03:40 +08:00
|
|
|
}
|
|
|
|
|
2016-09-06 18:10:28 +08:00
|
|
|
static void removeImageAccessQualifier(std::string& TyName) {
|
|
|
|
std::string ReadOnlyQual("__read_only");
|
|
|
|
std::string::size_type ReadOnlyPos = TyName.find(ReadOnlyQual);
|
|
|
|
if (ReadOnlyPos != std::string::npos)
|
|
|
|
// "+ 1" for the space after access qualifier.
|
|
|
|
TyName.erase(ReadOnlyPos, ReadOnlyQual.size() + 1);
|
|
|
|
else {
|
|
|
|
std::string WriteOnlyQual("__write_only");
|
|
|
|
std::string::size_type WriteOnlyPos = TyName.find(WriteOnlyQual);
|
|
|
|
if (WriteOnlyPos != std::string::npos)
|
|
|
|
TyName.erase(WriteOnlyPos, WriteOnlyQual.size() + 1);
|
|
|
|
else {
|
|
|
|
std::string ReadWriteQual("__read_write");
|
|
|
|
std::string::size_type ReadWritePos = TyName.find(ReadWriteQual);
|
|
|
|
if (ReadWritePos != std::string::npos)
|
|
|
|
TyName.erase(ReadWritePos, ReadWriteQual.size() + 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-14 21:08:30 +08:00
|
|
|
// Returns the address space id that should be produced to the
|
|
|
|
// kernel_arg_addr_space metadata. This is always fixed to the ids
|
|
|
|
// as specified in the SPIR 2.0 specification in order to differentiate
|
|
|
|
// for example in clGetKernelArgInfo() implementation between the address
|
|
|
|
// spaces with targets without unique mapping to the OpenCL address spaces
|
|
|
|
// (basically all single AS CPUs).
|
|
|
|
static unsigned ArgInfoAddressSpace(unsigned LangAS) {
|
|
|
|
switch (LangAS) {
|
|
|
|
case LangAS::opencl_global: return 1;
|
|
|
|
case LangAS::opencl_constant: return 2;
|
|
|
|
case LangAS::opencl_local: return 3;
|
|
|
|
case LangAS::opencl_generic: return 4; // Not in SPIR 2.0 specs.
|
|
|
|
default:
|
|
|
|
return 0; // Assume private.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// OpenCL v1.2 s5.6.4.6 allows the compiler to store kernel argument
|
|
|
|
// information in the program executable. The argument information stored
|
|
|
|
// includes the argument name, its type, the address and access qualifiers used.
|
|
|
|
static void GenOpenCLArgMetadata(const FunctionDecl *FD, llvm::Function *Fn,
|
2014-12-10 02:39:32 +08:00
|
|
|
CodeGenModule &CGM, llvm::LLVMContext &Context,
|
|
|
|
CGBuilderTy &Builder, ASTContext &ASTCtx) {
|
2013-03-24 21:58:12 +08:00
|
|
|
// Create MDNodes that represent the kernel arg metadata.
|
2012-07-12 07:02:10 +08:00
|
|
|
// Each MDNode is a list in the form of "key", N number of values which is
|
|
|
|
// the same number of values as their are kernel arguments.
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2014-04-04 21:43:57 +08:00
|
|
|
const PrintingPolicy &Policy = ASTCtx.getPrintingPolicy();
|
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// MDNode for the kernel argument address space qualifiers.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> addressQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// MDNode for the kernel argument access qualifiers (images only).
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> accessQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// MDNode for the kernel argument type names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argTypeNames;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
// MDNode for the kernel argument base type names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argBaseTypeNames;
|
2014-07-30 22:39:53 +08:00
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// MDNode for the kernel argument type qualifiers.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argTypeQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// MDNode for the kernel argument names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argNames;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
for (unsigned i = 0, e = FD->getNumParams(); i != e; ++i) {
|
|
|
|
const ParmVarDecl *parm = FD->getParamDecl(i);
|
2013-03-24 21:58:12 +08:00
|
|
|
QualType ty = parm->getType();
|
|
|
|
std::string typeQuals;
|
|
|
|
|
|
|
|
if (ty->isPointerType()) {
|
|
|
|
QualType pointeeTy = ty->getPointeeType();
|
|
|
|
|
|
|
|
// Get address qualifier.
|
2014-12-10 02:39:32 +08:00
|
|
|
addressQuals.push_back(llvm::ConstantAsMetadata::get(Builder.getInt32(
|
2016-11-14 21:08:30 +08:00
|
|
|
ArgInfoAddressSpace(pointeeTy.getAddressSpace()))));
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Get argument type name.
|
2014-04-04 21:43:57 +08:00
|
|
|
std::string typeName =
|
|
|
|
pointeeTy.getUnqualifiedType().getAsString(Policy) + "*";
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
std::string::size_type pos = typeName.find("unsigned");
|
2014-07-30 21:41:12 +08:00
|
|
|
if (pointeeTy.isCanonical() && pos != std::string::npos)
|
2013-03-25 00:04:55 +08:00
|
|
|
typeName.erase(pos+1, 8);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
argTypeNames.push_back(llvm::MDString::get(Context, typeName));
|
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
std::string baseTypeName =
|
|
|
|
pointeeTy.getUnqualifiedType().getCanonicalType().getAsString(
|
|
|
|
Policy) +
|
|
|
|
"*";
|
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
pos = baseTypeName.find("unsigned");
|
|
|
|
if (pos != std::string::npos)
|
|
|
|
baseTypeName.erase(pos+1, 8);
|
|
|
|
|
|
|
|
argBaseTypeNames.push_back(llvm::MDString::get(Context, baseTypeName));
|
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// Get argument type qualifiers:
|
|
|
|
if (ty.isRestrictQualified())
|
|
|
|
typeQuals = "restrict";
|
|
|
|
if (pointeeTy.isConstQualified() ||
|
|
|
|
(pointeeTy.getAddressSpace() == LangAS::opencl_constant))
|
2013-03-25 00:04:55 +08:00
|
|
|
typeQuals += typeQuals.empty() ? "const" : " const";
|
2013-03-24 21:58:12 +08:00
|
|
|
if (pointeeTy.isVolatileQualified())
|
2013-03-25 00:04:55 +08:00
|
|
|
typeQuals += typeQuals.empty() ? "volatile" : " volatile";
|
2013-03-24 21:58:12 +08:00
|
|
|
} else {
|
2014-01-09 21:37:30 +08:00
|
|
|
uint32_t AddrSpc = 0;
|
2016-01-09 20:53:17 +08:00
|
|
|
bool isPipe = ty->isPipeType();
|
|
|
|
if (ty->isImageType() || isPipe)
|
2016-11-14 21:08:30 +08:00
|
|
|
AddrSpc = ArgInfoAddressSpace(LangAS::opencl_global);
|
2014-02-18 03:20:59 +08:00
|
|
|
|
2014-12-10 02:39:32 +08:00
|
|
|
addressQuals.push_back(
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(AddrSpc)));
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Get argument type name.
|
2016-01-09 20:53:17 +08:00
|
|
|
std::string typeName;
|
|
|
|
if (isPipe)
|
2016-07-13 18:28:13 +08:00
|
|
|
typeName = ty.getCanonicalType()->getAs<PipeType>()->getElementType()
|
|
|
|
.getAsString(Policy);
|
2016-01-09 20:53:17 +08:00
|
|
|
else
|
|
|
|
typeName = ty.getUnqualifiedType().getAsString(Policy);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
std::string::size_type pos = typeName.find("unsigned");
|
2014-07-30 21:41:12 +08:00
|
|
|
if (ty.isCanonical() && pos != std::string::npos)
|
2013-03-25 00:04:55 +08:00
|
|
|
typeName.erase(pos+1, 8);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
std::string baseTypeName;
|
|
|
|
if (isPipe)
|
2016-07-13 18:28:13 +08:00
|
|
|
baseTypeName = ty.getCanonicalType()->getAs<PipeType>()
|
|
|
|
->getElementType().getCanonicalType()
|
|
|
|
.getAsString(Policy);
|
2016-01-09 20:53:17 +08:00
|
|
|
else
|
|
|
|
baseTypeName =
|
2014-07-30 22:39:53 +08:00
|
|
|
ty.getUnqualifiedType().getCanonicalType().getAsString(Policy);
|
|
|
|
|
2016-09-06 18:10:28 +08:00
|
|
|
// Remove access qualifiers on images
|
|
|
|
// (as they are inseparable from type in clang implementation,
|
|
|
|
// but OpenCL spec provides a special query to get access qualifier
|
|
|
|
// via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER):
|
|
|
|
if (ty->isImageType()) {
|
|
|
|
removeImageAccessQualifier(typeName);
|
|
|
|
removeImageAccessQualifier(baseTypeName);
|
|
|
|
}
|
|
|
|
|
|
|
|
argTypeNames.push_back(llvm::MDString::get(Context, typeName));
|
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
pos = baseTypeName.find("unsigned");
|
|
|
|
if (pos != std::string::npos)
|
|
|
|
baseTypeName.erase(pos+1, 8);
|
|
|
|
|
|
|
|
argBaseTypeNames.push_back(llvm::MDString::get(Context, baseTypeName));
|
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// Get argument type qualifiers:
|
|
|
|
if (ty.isConstQualified())
|
|
|
|
typeQuals = "const";
|
|
|
|
if (ty.isVolatileQualified())
|
2013-03-25 00:04:55 +08:00
|
|
|
typeQuals += typeQuals.empty() ? "volatile" : " volatile";
|
2016-01-09 20:53:17 +08:00
|
|
|
if (isPipe)
|
|
|
|
typeQuals = "pipe";
|
2013-03-24 21:58:12 +08:00
|
|
|
}
|
2013-11-22 18:20:40 +08:00
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
argTypeQuals.push_back(llvm::MDString::get(Context, typeQuals));
|
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
// Get image and pipe access qualifier:
|
|
|
|
if (ty->isImageType()|| ty->isPipeType()) {
|
2016-02-26 11:13:03 +08:00
|
|
|
const OpenCLAccessAttr *A = parm->getAttr<OpenCLAccessAttr>();
|
2014-01-15 01:41:53 +08:00
|
|
|
if (A && A->isWriteOnly())
|
2013-03-24 21:58:12 +08:00
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "write_only"));
|
2016-02-26 11:13:03 +08:00
|
|
|
else if (A && A->isReadWrite())
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "read_write"));
|
2013-03-24 21:58:12 +08:00
|
|
|
else
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "read_only"));
|
|
|
|
} else
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "none"));
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// Get argument name.
|
|
|
|
argNames.push_back(llvm::MDString::get(Context, parm->getName()));
|
|
|
|
}
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("kernel_arg_addr_space",
|
|
|
|
llvm::MDNode::get(Context, addressQuals));
|
|
|
|
Fn->setMetadata("kernel_arg_access_qual",
|
|
|
|
llvm::MDNode::get(Context, accessQuals));
|
|
|
|
Fn->setMetadata("kernel_arg_type",
|
|
|
|
llvm::MDNode::get(Context, argTypeNames));
|
|
|
|
Fn->setMetadata("kernel_arg_base_type",
|
|
|
|
llvm::MDNode::get(Context, argBaseTypeNames));
|
|
|
|
Fn->setMetadata("kernel_arg_type_qual",
|
|
|
|
llvm::MDNode::get(Context, argTypeQuals));
|
2014-12-04 13:30:58 +08:00
|
|
|
if (CGM.getCodeGenOpts().EmitOpenCLArgMetadata)
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("kernel_arg_name",
|
|
|
|
llvm::MDNode::get(Context, argNames));
|
2012-07-12 07:02:10 +08:00
|
|
|
}
|
|
|
|
|
2012-12-04 08:29:55 +08:00
|
|
|
void CodeGenFunction::EmitOpenCLKernelMetadata(const FunctionDecl *FD,
|
2012-07-10 06:06:01 +08:00
|
|
|
llvm::Function *Fn)
|
|
|
|
{
|
|
|
|
if (!FD->hasAttr<OpenCLKernelAttr>())
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::LLVMContext &Context = getLLVMContext();
|
|
|
|
|
2016-06-22 22:56:35 +08:00
|
|
|
GenOpenCLArgMetadata(FD, Fn, CGM, Context, Builder, getContext());
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2013-12-19 11:09:10 +08:00
|
|
|
if (const VecTypeHintAttr *A = FD->getAttr<VecTypeHintAttr>()) {
|
|
|
|
QualType hintQTy = A->getTypeHint();
|
2013-03-08 17:42:32 +08:00
|
|
|
const ExtVectorType *hintEltQTy = hintQTy->getAs<ExtVectorType>();
|
|
|
|
bool isSignedInteger =
|
|
|
|
hintQTy->isSignedIntegerType() ||
|
|
|
|
(hintEltQTy && hintEltQTy->getElementType()->isSignedIntegerType());
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::Metadata *attrMDArgs[] = {
|
|
|
|
llvm::ConstantAsMetadata::get(llvm::UndefValue::get(
|
|
|
|
CGM.getTypes().ConvertType(A->getTypeHint()))),
|
|
|
|
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
|
|
|
|
llvm::IntegerType::get(Context, 32),
|
|
|
|
llvm::APInt(32, (uint64_t)(isSignedInteger ? 1 : 0))))};
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("vec_type_hint", llvm::MDNode::get(Context, attrMDArgs));
|
2013-03-08 17:42:32 +08:00
|
|
|
}
|
|
|
|
|
2013-12-19 11:09:10 +08:00
|
|
|
if (const WorkGroupSizeHintAttr *A = FD->getAttr<WorkGroupSizeHintAttr>()) {
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::Metadata *attrMDArgs[] = {
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getXDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getYDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getZDim()))};
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("work_group_size_hint", llvm::MDNode::get(Context, attrMDArgs));
|
2012-07-10 06:06:01 +08:00
|
|
|
}
|
|
|
|
|
2013-12-19 11:09:10 +08:00
|
|
|
if (const ReqdWorkGroupSizeAttr *A = FD->getAttr<ReqdWorkGroupSizeAttr>()) {
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::Metadata *attrMDArgs[] = {
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getXDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getYDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getZDim()))};
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("reqd_work_group_size", llvm::MDNode::get(Context, attrMDArgs));
|
2012-07-10 06:06:01 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-29 09:07:59 +08:00
|
|
|
/// Determine whether the function F ends with a return stmt.
|
|
|
|
static bool endsWithReturn(const Decl* F) {
|
|
|
|
const Stmt *Body = nullptr;
|
|
|
|
if (auto *FD = dyn_cast_or_null<FunctionDecl>(F))
|
|
|
|
Body = FD->getBody();
|
|
|
|
else if (auto *OMD = dyn_cast_or_null<ObjCMethodDecl>(F))
|
|
|
|
Body = OMD->getBody();
|
|
|
|
|
|
|
|
if (auto *CS = dyn_cast_or_null<CompoundStmt>(Body)) {
|
|
|
|
auto LastStmt = CS->body_rbegin();
|
|
|
|
if (LastStmt != CS->body_rend())
|
|
|
|
return isa<ReturnStmt>(*LastStmt);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-01-13 08:50:50 +08:00
|
|
|
static void markAsIgnoreThreadCheckingAtRuntime(llvm::Function *Fn) {
|
|
|
|
Fn->addFnAttr("sanitize_thread_no_checking_at_run_time");
|
|
|
|
Fn->removeFnAttr(llvm::Attribute::SanitizeThread);
|
|
|
|
}
|
|
|
|
|
2013-05-03 15:33:41 +08:00
|
|
|
void CodeGenFunction::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 07:21:53 +08:00
|
|
|
SourceLocation Loc,
|
2011-03-03 05:36:49 +08:00
|
|
|
SourceLocation StartLoc) {
|
2014-10-15 00:43:46 +08:00
|
|
|
assert(!CurFn &&
|
|
|
|
"Do not use a CodeGenFunction object for more than one function");
|
|
|
|
|
2009-09-11 08:07:24 +08:00
|
|
|
const Decl *D = GD.getDecl();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-02-10 04:20:56 +08:00
|
|
|
DidCallStackSave = false;
|
2013-05-03 15:33:41 +08:00
|
|
|
CurCodeDecl = D;
|
2016-03-02 03:42:53 +08:00
|
|
|
if (const auto *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if (FD->usesSEHTry())
|
|
|
|
CurSEHParent = FD;
|
2014-05-21 13:09:00 +08:00
|
|
|
CurFuncDecl = (D ? D->getNonClosureContext() : nullptr);
|
2008-09-10 07:14:03 +08:00
|
|
|
FnRetTy = RetTy;
|
2008-07-30 07:18:29 +08:00
|
|
|
CurFn = Fn;
|
2011-03-09 12:27:21 +08:00
|
|
|
CurFnInfo = &FnInfo;
|
2007-06-20 12:44:43 +08:00
|
|
|
assert(CurFn->isDeclaration() && "Function already has body?");
|
2008-03-03 11:28:21 +08:00
|
|
|
|
SanitizerBlacklist: blacklist functions by their source location.
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
2014-10-17 08:20:19 +08:00
|
|
|
if (CGM.isInSanitizerBlacklist(Fn, Loc))
|
2014-10-31 03:33:44 +08:00
|
|
|
SanOpts.clear();
|
2013-01-18 19:30:38 +08:00
|
|
|
|
2015-05-16 02:33:32 +08:00
|
|
|
if (D) {
|
|
|
|
// Apply the no_sanitize* attributes to SanOpts.
|
|
|
|
for (auto Attr : D->specific_attrs<NoSanitizeAttr>())
|
|
|
|
SanOpts.Mask &= ~Attr->getMask();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Apply sanitizer attributes to the function.
|
2015-06-19 20:19:07 +08:00
|
|
|
if (SanOpts.hasOneOf(SanitizerKind::Address | SanitizerKind::KernelAddress))
|
2015-05-16 02:33:32 +08:00
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
|
|
|
|
if (SanOpts.has(SanitizerKind::Thread))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeThread);
|
|
|
|
if (SanOpts.has(SanitizerKind::Memory))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
|
2015-06-16 05:08:13 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::SafeStack))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SafeStack);
|
2015-05-16 02:33:32 +08:00
|
|
|
|
2016-11-12 07:22:44 +08:00
|
|
|
// Ignore TSan memory acesses from within ObjC/ObjC++ dealloc, initialize,
|
2017-01-13 08:50:50 +08:00
|
|
|
// .cxx_destruct, __destroy_helper_block_ and all of their calees at run time.
|
2016-11-12 07:22:44 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::Thread)) {
|
|
|
|
if (const auto *OMD = dyn_cast_or_null<ObjCMethodDecl>(D)) {
|
|
|
|
IdentifierInfo *II = OMD->getSelector().getIdentifierInfoForSlot(0);
|
|
|
|
if (OMD->getMethodFamily() == OMF_dealloc ||
|
|
|
|
OMD->getMethodFamily() == OMF_initialize ||
|
|
|
|
(OMD->getSelector().isUnarySelector() && II->isStr(".cxx_destruct"))) {
|
2017-01-13 08:50:50 +08:00
|
|
|
markAsIgnoreThreadCheckingAtRuntime(Fn);
|
2016-11-12 07:22:44 +08:00
|
|
|
}
|
2017-01-13 08:50:50 +08:00
|
|
|
} else if (const auto *FD = dyn_cast_or_null<FunctionDecl>(D)) {
|
|
|
|
IdentifierInfo *II = FD->getIdentifier();
|
|
|
|
if (II && II->isStr("__destroy_helper_block_"))
|
|
|
|
markAsIgnoreThreadCheckingAtRuntime(Fn);
|
2016-11-12 07:22:44 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-14 06:32:15 +08:00
|
|
|
// Apply xray attributes to the function (as a string, for now)
|
|
|
|
if (D && ShouldXRayInstrumentFunction()) {
|
|
|
|
if (const auto *XRayAttr = D->getAttr<XRayInstrumentAttr>()) {
|
|
|
|
if (XRayAttr->alwaysXRayInstrument())
|
|
|
|
Fn->addFnAttr("function-instrument", "xray-always");
|
|
|
|
if (XRayAttr->neverXRayInstrument())
|
|
|
|
Fn->addFnAttr("function-instrument", "xray-never");
|
|
|
|
} else {
|
|
|
|
Fn->addFnAttr(
|
|
|
|
"xray-instruction-threshold",
|
|
|
|
llvm::itostr(CGM.getCodeGenOpts().XRayInstructionThreshold));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
llvm-svn: 290398
2016-12-23 09:24:49 +08:00
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
|
2016-05-06 17:40:08 +08:00
|
|
|
if (CGM.getLangOpts().OpenMP && FD->hasAttr<OMPDeclareSimdDeclAttr>())
|
|
|
|
CGM.getOpenMPRuntime().emitDeclareSimdFunction(FD, Fn);
|
2010-02-09 08:10:00 +08:00
|
|
|
|
2016-04-06 01:50:43 +08:00
|
|
|
// Add no-jump-tables value.
|
|
|
|
Fn->addFnAttr("no-jump-tables",
|
|
|
|
llvm::toStringRef(CGM.getCodeGenOpts().NoUseJumpTables));
|
|
|
|
|
2012-11-02 06:30:59 +08:00
|
|
|
if (getLangOpts().OpenCL) {
|
2011-02-14 09:42:53 +08:00
|
|
|
// Add metadata for a kernel function.
|
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
|
2012-07-10 06:06:01 +08:00
|
|
|
EmitOpenCLKernelMetadata(FD, Fn);
|
2011-02-14 09:42:53 +08:00
|
|
|
}
|
|
|
|
|
2013-10-21 05:29:19 +08:00
|
|
|
// If we are checking function types, emit a function type signature as
|
2014-12-03 10:08:51 +08:00
|
|
|
// prologue data.
|
2014-11-08 06:29:38 +08:00
|
|
|
if (getLangOpts().CPlusPlus && SanOpts.has(SanitizerKind::Function)) {
|
2013-10-21 05:29:19 +08:00
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) {
|
2014-12-03 10:08:51 +08:00
|
|
|
if (llvm::Constant *PrologueSig =
|
2013-10-21 05:29:19 +08:00
|
|
|
CGM.getTargetCodeGenInfo().getUBSanFunctionSignature(CGM)) {
|
|
|
|
llvm::Constant *FTRTTIConst =
|
|
|
|
CGM.GetAddrOfRTTIDescriptor(FD->getType(), /*ForEH=*/true);
|
2014-12-03 10:08:51 +08:00
|
|
|
llvm::Constant *PrologueStructElems[] = { PrologueSig, FTRTTIConst };
|
|
|
|
llvm::Constant *PrologueStructConst =
|
|
|
|
llvm::ConstantStruct::getAnon(PrologueStructElems, /*Packed=*/true);
|
|
|
|
Fn->setPrologueData(PrologueStructConst);
|
2013-10-21 05:29:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-11-12 23:36:04 +08:00
|
|
|
// If we're in C++ mode and the function name is "main", it is guaranteed
|
|
|
|
// to be norecurse by the standard (3.6.1.3 "The function main shall not be
|
|
|
|
// used within a program").
|
|
|
|
if (getLangOpts().CPlusPlus)
|
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if (FD->isMain())
|
|
|
|
Fn->addFnAttr(llvm::Attribute::NoRecurse);
|
2016-09-01 14:14:45 +08:00
|
|
|
|
2008-11-11 10:29:29 +08:00
|
|
|
llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
|
2008-09-10 05:00:17 +08:00
|
|
|
|
2007-06-02 12:53:11 +08:00
|
|
|
// Create a marker to make it easy to insert allocas into the entryblock
|
2007-12-18 04:50:59 +08:00
|
|
|
// later. Don't create this with the builder, because we don't want it
|
|
|
|
// folded.
|
2010-06-27 15:15:29 +08:00
|
|
|
llvm::Value *Undef = llvm::UndefValue::get(Int32Ty);
|
2016-03-14 05:05:23 +08:00
|
|
|
AllocaInsertPt = new llvm::BitCastInst(Undef, Int32Ty, "allocapt", EntryBB);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
ReturnBlock = getJumpDestInCurrentScope("return");
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2007-12-18 04:50:59 +08:00
|
|
|
Builder.SetInsertPoint(EntryBB);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-07-04 19:04:26 +08:00
|
|
|
// Emit subprogram debug descriptor.
|
2009-02-13 16:11:52 +08:00
|
|
|
if (CGDebugInfo *DI = getDebugInfo()) {
|
2016-06-09 04:41:54 +08:00
|
|
|
// Reconstruct the type from the argument list so that implicit parameters,
|
|
|
|
// such as 'this' and 'vtt', show up in the debug info. Preserve the calling
|
|
|
|
// convention.
|
|
|
|
CallingConv CC = CallingConv::CC_C;
|
|
|
|
if (auto *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if (const auto *SrcFnTy = FD->getType()->getAs<FunctionType>())
|
|
|
|
CC = SrcFnTy->getCallConv();
|
2013-03-09 05:51:21 +08:00
|
|
|
SmallVector<QualType, 16> ArgTypes;
|
2016-06-09 04:41:54 +08:00
|
|
|
for (const VarDecl *VD : Args)
|
|
|
|
ArgTypes.push_back(VD->getType());
|
|
|
|
QualType FnType = getContext().getFunctionType(
|
|
|
|
RetTy, ArgTypes, FunctionProtoType::ExtProtoInfo(CC));
|
2014-04-11 07:21:53 +08:00
|
|
|
DI->EmitFunctionStart(GD, Loc, StartLoc, FnType, CurFn, Builder);
|
2008-07-04 19:04:26 +08:00
|
|
|
}
|
|
|
|
|
2011-02-11 01:32:22 +08:00
|
|
|
if (ShouldInstrumentFunction())
|
|
|
|
EmitFunctionInstrumentation("__cyg_profile_func_enter");
|
2010-06-22 08:03:40 +08:00
|
|
|
|
[Frontend] Fix mcount inlining bug
Since some profiling tools, such as gprof, ftrace, and uftrace, use
-pg option to generate a mcount function call at the entry of each
function. Function invocation can be detected by this hook function.
But mcount insertion is done before function inlining phase in clang,
sometime a function that already has a mcount call can be inlined in the
middle of another function.
This patch adds an attribute "counting-function" to each function
rather than emitting the mcount call directly in frontend so that this
attribute can be processed in backend. Then the mcount calls can be
properly inserted in backend after all the other optimizations are
completed.
Link: https://llvm.org/bugs/show_bug.cgi?id=28660
Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd
Subscribers: shenhan, cfe-commits
Differential Revision: https://reviews.llvm.org/D22666
llvm-svn: 280355
2016-09-01 19:29:21 +08:00
|
|
|
// Since emitting the mcount call here impacts optimizations such as function
|
|
|
|
// inlining, we just add an attribute to insert a mcount call in backend.
|
|
|
|
// The attribute "counting-function" is set to mcount function name which is
|
|
|
|
// architecture dependent.
|
2017-02-01 01:00:35 +08:00
|
|
|
if (CGM.getCodeGenOpts().InstrumentForProfiling) {
|
|
|
|
if (CGM.getCodeGenOpts().CallFEntry)
|
|
|
|
Fn->addFnAttr("fentry-call", "true");
|
|
|
|
else
|
|
|
|
Fn->addFnAttr("counting-function", getTarget().getMCountName());
|
|
|
|
}
|
2011-02-11 00:52:03 +08:00
|
|
|
|
2009-12-04 10:43:40 +08:00
|
|
|
if (RetTy->isVoidType()) {
|
|
|
|
// Void type; nothing to return.
|
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 = Address::invalid();
|
2014-04-29 09:07:59 +08:00
|
|
|
|
|
|
|
// Count the implicit return.
|
|
|
|
if (!endsWithReturn(D))
|
|
|
|
++NumReturnExprs;
|
2009-12-04 10:43:40 +08:00
|
|
|
} else if (CurFnInfo->getReturnInfo().getKind() == ABIArgInfo::Indirect &&
|
2013-03-08 05:37:08 +08:00
|
|
|
!hasScalarEvaluationKind(CurFnInfo->getReturnType())) {
|
2009-12-04 10:43:40 +08:00
|
|
|
// Indirect aggregate return; emit returned value directly into sret slot.
|
2010-02-17 03:45:20 +08:00
|
|
|
// This reduces code size, and affects correctness in C++.
|
2014-05-10 06:46:15 +08:00
|
|
|
auto AI = CurFn->arg_begin();
|
|
|
|
if (CurFnInfo->getReturnInfo().isSRetAfterThis())
|
|
|
|
++AI;
|
2015-11-07 07:00:41 +08:00
|
|
|
ReturnValue = Address(&*AI, CurFnInfo->getReturnInfo().getIndirectAlign());
|
2014-02-01 08:04:45 +08:00
|
|
|
} else if (CurFnInfo->getReturnInfo().getKind() == ABIArgInfo::InAlloca &&
|
|
|
|
!hasScalarEvaluationKind(CurFnInfo->getReturnType())) {
|
|
|
|
// Load the sret pointer from the argument struct and return into that.
|
|
|
|
unsigned Idx = CurFnInfo->getReturnInfo().getInAllocaFieldIndex();
|
|
|
|
llvm::Function::arg_iterator EI = CurFn->arg_end();
|
|
|
|
--EI;
|
2015-11-07 07:00:41 +08:00
|
|
|
llvm::Value *Addr = Builder.CreateStructGEP(nullptr, &*EI, Idx);
|
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
|
|
|
Addr = Builder.CreateAlignedLoad(Addr, getPointerAlign(), "agg.result");
|
|
|
|
ReturnValue = Address(Addr, getNaturalTypeAlignment(RetTy));
|
2009-12-04 10:43:40 +08:00
|
|
|
} else {
|
2010-02-17 03:45:20 +08:00
|
|
|
ReturnValue = CreateIRTemp(RetTy, "retval");
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
// Tell the epilog emitter to autorelease the result. We do this
|
|
|
|
// now so that various specialized functions can suppress it
|
|
|
|
// during their IR-generation.
|
2012-03-11 15:00:24 +08:00
|
|
|
if (getLangOpts().ObjCAutoRefCount &&
|
2011-06-16 07:02:42 +08:00
|
|
|
!CurFnInfo->isReturnsRetained() &&
|
|
|
|
RetTy->isObjCRetainableType())
|
|
|
|
AutoreleaseResult = true;
|
2009-12-04 10:43:40 +08:00
|
|
|
}
|
|
|
|
|
2009-12-08 07:38:24 +08:00
|
|
|
EmitStartEHSpec(CurCodeDecl);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
PrologueCleanupDepth = EHStack.stable_begin();
|
2009-02-03 06:03:45 +08:00
|
|
|
EmitFunctionProlog(*CurFnInfo, CurFn, Args);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2012-02-11 10:57:39 +08:00
|
|
|
if (D && isa<CXXMethodDecl>(D) && cast<CXXMethodDecl>(D)->isInstance()) {
|
2010-08-31 15:33:07 +08:00
|
|
|
CGM.getCXXABI().EmitInstanceFunctionProlog(*this);
|
2012-02-11 10:57:39 +08:00
|
|
|
const CXXMethodDecl *MD = cast<CXXMethodDecl>(D);
|
|
|
|
if (MD->getParent()->isLambda() &&
|
|
|
|
MD->getOverloadedOperator() == OO_Call) {
|
|
|
|
// We're in a lambda; figure out the captures.
|
|
|
|
MD->getParent()->getCaptureFields(LambdaCaptureFields,
|
|
|
|
LambdaThisCaptureField);
|
|
|
|
if (LambdaThisCaptureField) {
|
[Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3)
Implement lambda capture of *this by copy.
For e.g.:
struct A {
int d = 10;
auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }
};
auto L = A{}.foo(); // A{}'s lifetime is gone.
// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);
If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.
Implementation Strategy:
- amend the parser to accept *this in the lambda introducer
- add a new king of capture LCK_StarThis
- teach Sema::CheckCXXThisCapture to handle by copy captures of the
enclosing object (i.e. *this)
- when CheckCXXThisCapture does capture by copy, the corresponding
initializer expression for the closure's data member
direct-initializes it thus making a copy of '*this'.
- in codegen, when assigning to CXXThisValue, if *this was captured by
copy, make sure it points to the corresponding field member, and
not, unlike when captured by reference, what the field member points
to.
- mark feature as implemented in svn
Much gratitude to Richard Smith for his carefully illuminating reviews!
llvm-svn: 263921
2016-03-21 17:25:37 +08:00
|
|
|
// If the lambda captures the object referred to by '*this' - either by
|
|
|
|
// value or by reference, make sure CXXThisValue points to the correct
|
|
|
|
// object.
|
|
|
|
|
|
|
|
// Get the lvalue for the field (which is a copy of the enclosing object
|
|
|
|
// or contains the address of the enclosing object).
|
|
|
|
LValue ThisFieldLValue = EmitLValueForLambdaField(LambdaThisCaptureField);
|
|
|
|
if (!LambdaThisCaptureField->getType()->isPointerType()) {
|
|
|
|
// If the enclosing object was captured by value, just use its address.
|
|
|
|
CXXThisValue = ThisFieldLValue.getAddress().getPointer();
|
|
|
|
} else {
|
|
|
|
// Load the lvalue pointed to by the field, since '*this' was captured
|
|
|
|
// by reference.
|
|
|
|
CXXThisValue =
|
|
|
|
EmitLoadOfLValue(ThisFieldLValue, SourceLocation()).getScalarVal();
|
|
|
|
}
|
2012-02-11 10:57:39 +08:00
|
|
|
}
|
2014-08-28 12:28:19 +08:00
|
|
|
for (auto *FD : MD->getParent()->fields()) {
|
|
|
|
if (FD->hasCapturedVLAType()) {
|
|
|
|
auto *ExprArg = EmitLoadOfLValue(EmitLValueForLambdaField(FD),
|
|
|
|
SourceLocation()).getScalarVal();
|
|
|
|
auto VAT = FD->getCapturedVLAType();
|
|
|
|
VLASizeMap[VAT->getSizeExpr()] = ExprArg;
|
|
|
|
}
|
|
|
|
}
|
2012-02-11 10:57:39 +08:00
|
|
|
} else {
|
|
|
|
// Not in a lambda; just use 'this' from the method.
|
|
|
|
// FIXME: Should we generate a new load for each use of 'this'? The
|
|
|
|
// fast register allocator would be happier...
|
|
|
|
CXXThisValue = CXXABIThisValue;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
// Null-check the 'this' pointer once per function, if it's available.
|
|
|
|
if (CXXThisValue) {
|
|
|
|
SanitizerSet SkippedChecks;
|
|
|
|
SkippedChecks.set(SanitizerKind::Alignment, true);
|
|
|
|
SkippedChecks.set(SanitizerKind::ObjectSize, true);
|
|
|
|
EmitTypeCheck(TCK_Load, Loc, CXXThisValue, MD->getThisType(getContext()),
|
|
|
|
/*Alignment=*/CharUnits::Zero(), SkippedChecks);
|
|
|
|
}
|
2012-02-11 10:57:39 +08:00
|
|
|
}
|
2010-02-17 06:04:33 +08:00
|
|
|
|
2008-12-21 05:28:43 +08:00
|
|
|
// If any of the arguments have a variably modified type, make sure to
|
|
|
|
// emit the type size.
|
|
|
|
for (FunctionArgList::const_iterator i = Args.begin(), e = Args.end();
|
|
|
|
i != e; ++i) {
|
2012-11-15 06:09:59 +08:00
|
|
|
const VarDecl *VD = *i;
|
|
|
|
|
|
|
|
// Dig out the type as written from ParmVarDecls; it's unclear whether
|
|
|
|
// the standard (C99 6.9.1p10) requires this, but we're following the
|
|
|
|
// precedent set by gcc.
|
|
|
|
QualType Ty;
|
|
|
|
if (const ParmVarDecl *PVD = dyn_cast<ParmVarDecl>(VD))
|
|
|
|
Ty = PVD->getOriginalType();
|
|
|
|
else
|
|
|
|
Ty = VD->getType();
|
2008-12-21 05:28:43 +08:00
|
|
|
|
|
|
|
if (Ty->isVariablyModifiedType())
|
2011-06-25 05:55:10 +08:00
|
|
|
EmitVariablyModifiedType(Ty);
|
2008-12-21 05:28:43 +08:00
|
|
|
}
|
2011-10-14 05:45:18 +08:00
|
|
|
// Emit a location at the end of the prologue.
|
|
|
|
if (CGDebugInfo *DI = getDebugInfo())
|
|
|
|
DI->EmitLocation(Builder, StartLoc);
|
2008-09-10 07:14:03 +08:00
|
|
|
}
|
2008-08-26 05:31:01 +08:00
|
|
|
|
2013-11-05 17:12:18 +08:00
|
|
|
void CodeGenFunction::EmitFunctionBody(FunctionArgList &Args,
|
|
|
|
const Stmt *Body) {
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(Body);
|
2013-11-05 17:12:18 +08:00
|
|
|
if (const CompoundStmt *S = dyn_cast<CompoundStmt>(Body))
|
2013-01-27 06:16:26 +08:00
|
|
|
EmitCompoundStmtWithoutScope(*S);
|
|
|
|
else
|
2013-11-05 17:12:18 +08:00
|
|
|
EmitStmt(Body);
|
2010-02-18 11:17:58 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
/// When instrumenting to collect profile data, the counts for some blocks
|
|
|
|
/// such as switch cases need to not include the fall-through counts, so
|
|
|
|
/// emit a branch around the instrumentation code. When not instrumenting,
|
|
|
|
/// this just calls EmitBlock().
|
|
|
|
void CodeGenFunction::EmitBlockWithFallThrough(llvm::BasicBlock *BB,
|
2015-04-24 07:06:47 +08:00
|
|
|
const Stmt *S) {
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::BasicBlock *SkipCountBB = nullptr;
|
2016-02-05 02:39:09 +08:00
|
|
|
if (HaveInsertPoint() && CGM.getCodeGenOpts().hasProfileClangInstr()) {
|
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
|
|
|
// When instrumenting for profiling, the fallthrough to certain
|
|
|
|
// statements needs to skip over the instrumentation code so that we
|
|
|
|
// get an accurate count.
|
|
|
|
SkipCountBB = createBasicBlock("skipcount");
|
|
|
|
EmitBranch(SkipCountBB);
|
|
|
|
}
|
|
|
|
EmitBlock(BB);
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t CurrentCount = getCurrentProfileCount();
|
|
|
|
incrementProfileCounter(S);
|
|
|
|
setCurrentProfileCount(getCurrentProfileCount() + CurrentCount);
|
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
|
|
|
if (SkipCountBB)
|
|
|
|
EmitBlock(SkipCountBB);
|
|
|
|
}
|
|
|
|
|
2010-08-04 06:46:07 +08:00
|
|
|
/// Tries to mark the given function nounwind based on the
|
|
|
|
/// non-existence of any throwing calls within it. We believe this is
|
|
|
|
/// lightweight enough to do at -O0.
|
|
|
|
static void TryMarkNoThrow(llvm::Function *F) {
|
2010-08-12 06:38:33 +08:00
|
|
|
// LLVM treats 'nounwind' on a function as part of the type, so we
|
|
|
|
// can't do this on functions that can be overwritten.
|
2016-04-08 09:31:02 +08:00
|
|
|
if (F->isInterposable()) return;
|
2010-08-12 06:38:33 +08:00
|
|
|
|
2015-08-01 01:58:45 +08:00
|
|
|
for (llvm::BasicBlock &BB : *F)
|
|
|
|
for (llvm::Instruction &I : BB)
|
|
|
|
if (I.mayThrow())
|
2011-09-20 04:31:14 +08:00
|
|
|
return;
|
2015-08-01 01:58:45 +08:00
|
|
|
|
2012-10-10 11:13:20 +08:00
|
|
|
F->setDoesNotThrow();
|
2010-08-04 06:46:07 +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 CodeGenFunction::BuildFunctionArgList(GlobalDecl GD,
|
|
|
|
FunctionArgList &Args) {
|
2009-09-11 08:07:24 +08:00
|
|
|
const FunctionDecl *FD = cast<FunctionDecl>(GD.getDecl());
|
2014-01-26 00:55:45 +08:00
|
|
|
QualType ResTy = FD->getReturnType();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(FD);
|
|
|
|
if (MD && MD->isInstance()) {
|
2013-07-01 04:40:16 +08:00
|
|
|
if (CGM.getCXXABI().HasThisReturn(GD))
|
|
|
|
ResTy = MD->getThisType(getContext());
|
2014-11-01 04:09:12 +08:00
|
|
|
else if (CGM.getCXXABI().hasMostDerivedReturn(GD))
|
|
|
|
ResTy = CGM.getContext().VoidPtrTy;
|
2013-12-18 03:46:40 +08:00
|
|
|
CGM.getCXXABI().buildThisParam(*this, Args);
|
2013-07-01 04:40:16 +08:00
|
|
|
}
|
2015-04-24 07:06: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
|
|
|
// The base version of an inheriting constructor whose constructed base is a
|
|
|
|
// virtual base is not passed any arguments (because it doesn't actually call
|
|
|
|
// the inherited constructor).
|
|
|
|
bool PassedParams = true;
|
|
|
|
if (const CXXConstructorDecl *CD = dyn_cast<CXXConstructorDecl>(FD))
|
|
|
|
if (auto Inherited = CD->getInheritedConstructor())
|
|
|
|
PassedParams =
|
|
|
|
getTypes().inheritingCtorHasParams(Inherited, GD.getCtorType());
|
|
|
|
|
|
|
|
if (PassedParams) {
|
|
|
|
for (auto *Param : FD->parameters()) {
|
|
|
|
Args.push_back(Param);
|
|
|
|
if (!Param->hasAttr<PassObjectSizeAttr>())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
IdentifierInfo *NoID = nullptr;
|
|
|
|
auto *Implicit = ImplicitParamDecl::Create(
|
|
|
|
getContext(), Param->getDeclContext(), Param->getLocation(), NoID,
|
|
|
|
getContext().getSizeType());
|
|
|
|
SizeArguments[Param] = Implicit;
|
|
|
|
Args.push_back(Implicit);
|
|
|
|
}
|
2015-12-03 05:58:08 +08:00
|
|
|
}
|
2008-08-26 16:29:31 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
if (MD && (isa<CXXConstructorDecl>(MD) || isa<CXXDestructorDecl>(MD)))
|
|
|
|
CGM.getCXXABI().addImplicitStructorParams(*this, ResTy, Args);
|
|
|
|
|
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
|
|
|
return ResTy;
|
|
|
|
}
|
|
|
|
|
2017-01-04 21:40:34 +08:00
|
|
|
static bool
|
|
|
|
shouldUseUndefinedBehaviorReturnOptimization(const FunctionDecl *FD,
|
|
|
|
const ASTContext &Context) {
|
|
|
|
QualType T = FD->getReturnType();
|
|
|
|
// Avoid the optimization for functions that return a record type with a
|
|
|
|
// trivial destructor or another trivially copyable type.
|
|
|
|
if (const RecordType *RT = T.getCanonicalType()->getAs<RecordType>()) {
|
|
|
|
if (const auto *ClassDecl = dyn_cast<CXXRecordDecl>(RT->getDecl()))
|
|
|
|
return !ClassDecl->hasTrivialDestructor();
|
|
|
|
}
|
|
|
|
return !T.isTriviallyCopyableType(Context);
|
|
|
|
}
|
|
|
|
|
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 CodeGenFunction::GenerateCode(GlobalDecl GD, llvm::Function *Fn,
|
|
|
|
const CGFunctionInfo &FnInfo) {
|
|
|
|
const FunctionDecl *FD = cast<FunctionDecl>(GD.getDecl());
|
|
|
|
CurGD = GD;
|
|
|
|
|
|
|
|
FunctionArgList Args;
|
|
|
|
QualType ResTy = BuildFunctionArgList(GD, Args);
|
|
|
|
|
|
|
|
// Check if we should generate debug info for this function.
|
|
|
|
if (FD->hasAttr<NoDebugAttr>())
|
|
|
|
DebugInfo = nullptr; // disable debug info indefinitely for this function
|
|
|
|
|
2017-02-09 00:09:32 +08:00
|
|
|
// The function might not have a body if we're generating thunks for a
|
|
|
|
// function declaration.
|
2010-02-18 11:17:58 +08:00
|
|
|
SourceRange BodyRange;
|
2017-02-09 00:09:32 +08:00
|
|
|
if (Stmt *Body = FD->getBody())
|
|
|
|
BodyRange = Body->getSourceRange();
|
|
|
|
else
|
|
|
|
BodyRange = FD->getLocation();
|
2013-05-16 08:41:26 +08:00
|
|
|
CurEHLocation = BodyRange.getEnd();
|
2009-11-06 10:55:43 +08:00
|
|
|
|
2014-04-11 07:21:53 +08:00
|
|
|
// Use the location of the start of the function to determine where
|
|
|
|
// the function definition is located. By default use the location
|
|
|
|
// of the declaration as the location for the subprogram. A function
|
|
|
|
// may lack a declaration in the source code if it is created by code
|
|
|
|
// gen. (examples: _GLOBAL__I_a, __cxx_global_array_dtor, thunk).
|
2014-07-09 04:23:18 +08:00
|
|
|
SourceLocation Loc = FD->getLocation();
|
|
|
|
|
|
|
|
// If this is a function specialization then use the pattern body
|
|
|
|
// as the location for the function.
|
|
|
|
if (const FunctionDecl *SpecDecl = FD->getTemplateInstantiationPattern())
|
|
|
|
if (SpecDecl->hasBody(SpecDecl))
|
|
|
|
Loc = SpecDecl->getLocation();
|
2014-04-11 07:21:53 +08:00
|
|
|
|
2016-10-26 13:42:30 +08:00
|
|
|
Stmt *Body = FD->getBody();
|
|
|
|
|
|
|
|
// Initialize helper which will detect jumps which can cause invalid lifetime
|
|
|
|
// markers.
|
|
|
|
if (Body && ShouldEmitLifetimeMarkers)
|
|
|
|
Bypasses.Init(Body);
|
|
|
|
|
2010-02-18 11:17:58 +08:00
|
|
|
// Emit the standard function prologue.
|
2014-04-11 07:21:53 +08:00
|
|
|
StartFunction(GD, ResTy, Fn, FnInfo, Args, Loc, BodyRange.getBegin());
|
2010-02-08 03:45:40 +08:00
|
|
|
|
2010-02-18 11:17:58 +08:00
|
|
|
// Generate the body of the function.
|
2015-12-06 22:32:39 +08:00
|
|
|
PGO.assignRegionCounters(GD, CurFn);
|
2010-02-19 17:25:03 +08:00
|
|
|
if (isa<CXXDestructorDecl>(FD))
|
|
|
|
EmitDestructorBody(Args);
|
|
|
|
else if (isa<CXXConstructorDecl>(FD))
|
|
|
|
EmitConstructorBody(Args);
|
2012-11-02 06:30:59 +08:00
|
|
|
else if (getLangOpts().CUDA &&
|
2015-03-20 02:58:18 +08:00
|
|
|
!getLangOpts().CUDAIsDevice &&
|
2011-10-07 02:51:56 +08:00
|
|
|
FD->hasAttr<CUDAGlobalAttr>())
|
2015-05-08 03:34:16 +08:00
|
|
|
CGM.getCUDARuntime().emitDeviceStub(*this, Args);
|
2012-02-16 09:37:33 +08:00
|
|
|
else if (isa<CXXConversionDecl>(FD) &&
|
2012-02-17 11:02:34 +08:00
|
|
|
cast<CXXConversionDecl>(FD)->isLambdaToBlockPointerConversion()) {
|
|
|
|
// The lambda conversion to block pointer is special; the semantics can't be
|
|
|
|
// expressed in the AST, so IRGen needs to special-case it.
|
|
|
|
EmitLambdaToBlockPointerBody(Args);
|
|
|
|
} else if (isa<CXXMethodDecl>(FD) &&
|
|
|
|
cast<CXXMethodDecl>(FD)->isLambdaStaticInvoker()) {
|
Implement a rudimentary form of generic lambdas.
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- generic lambdas within template functions and nested
within other generic lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
(Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)
As an example of what compiles through this commit:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics).
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately
generate a template-parameter-type when 'auto' is parsed in a generic
lambda parameter context. (i.e we do NOT use AutoType deduced to
a template parameter type - Richard seemed ok with this approach).
We encode that this template type was generated from an auto by simply
adding $auto to the name which can be used for better diagnostics if needed.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- various tests were added - but much more will be needed.
There is obviously more work to be done, and both Richard (weakly) and Doug (strongly)
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.
A greatful thanks to all reviewers including Eli Friedman, James Dennett,
and especially the two gracious wizards (Richard Smith and Doug Gregor)
who spent hours providing feedback (in person in Chicago and on the mailing lists).
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 191453
2013-09-27 03:54:12 +08:00
|
|
|
// The lambda static invoker function is special, because it forwards or
|
2012-02-17 11:02:34 +08:00
|
|
|
// clones the body of the function call operator (but is actually static).
|
|
|
|
EmitLambdaStaticInvokeFunction(cast<CXXMethodDecl>(FD));
|
2013-02-17 15:22:09 +08:00
|
|
|
} else if (FD->isDefaulted() && isa<CXXMethodDecl>(FD) &&
|
2013-09-10 13:14:39 +08:00
|
|
|
(cast<CXXMethodDecl>(FD)->isCopyAssignmentOperator() ||
|
|
|
|
cast<CXXMethodDecl>(FD)->isMoveAssignmentOperator())) {
|
2013-02-17 15:22:09 +08:00
|
|
|
// Implicit copy-assignment gets the same special treatment as implicit
|
|
|
|
// copy-constructors.
|
|
|
|
emitImplicitAssignmentOperatorBody(Args);
|
2016-10-26 13:42:30 +08:00
|
|
|
} else if (Body) {
|
2013-11-05 17:12:18 +08:00
|
|
|
EmitFunctionBody(Args, Body);
|
|
|
|
} else
|
|
|
|
llvm_unreachable("no definition for emitted function");
|
2009-10-07 02:09:57 +08:00
|
|
|
|
2012-10-05 07:52:29 +08:00
|
|
|
// C++11 [stmt.return]p2:
|
|
|
|
// Flowing off the end of a function [...] results in undefined behavior in
|
|
|
|
// a value-returning function.
|
|
|
|
// C11 6.9.1p12:
|
|
|
|
// If the '}' that terminates a function is reached, and the value of the
|
|
|
|
// function call is used by the caller, the behavior is undefined.
|
2014-09-05 04:04:38 +08:00
|
|
|
if (getLangOpts().CPlusPlus && !FD->hasImplicitReturnZero() && !SawAsmBlock &&
|
2014-01-26 00:55:45 +08:00
|
|
|
!FD->getReturnType()->isVoidType() && Builder.GetInsertBlock()) {
|
2017-01-04 21:40:34 +08:00
|
|
|
bool ShouldEmitUnreachable =
|
|
|
|
CGM.getCodeGenOpts().StrictReturn ||
|
|
|
|
shouldUseUndefinedBehaviorReturnOptimization(FD, getContext());
|
2014-11-08 06:29:38 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::Return)) {
|
2014-07-18 02:46:27 +08:00
|
|
|
SanitizerScope SanScope(this);
|
2014-11-12 06:03:54 +08:00
|
|
|
llvm::Value *IsFalse = Builder.getFalse();
|
|
|
|
EmitCheck(std::make_pair(IsFalse, SanitizerKind::Return),
|
2016-12-13 00:18:40 +08:00
|
|
|
SanitizerHandler::MissingReturn,
|
|
|
|
EmitCheckSourceLocation(FD->getLocation()), None);
|
2017-01-04 21:40:34 +08:00
|
|
|
} else if (ShouldEmitUnreachable) {
|
|
|
|
if (CGM.getCodeGenOpts().OptimizationLevel == 0)
|
|
|
|
EmitTrapCall(llvm::Intrinsic::trap);
|
|
|
|
}
|
|
|
|
if (SanOpts.has(SanitizerKind::Return) || ShouldEmitUnreachable) {
|
|
|
|
Builder.CreateUnreachable();
|
|
|
|
Builder.ClearInsertionPoint();
|
2015-07-03 06:15:41 +08:00
|
|
|
}
|
2012-10-05 07:52:29 +08:00
|
|
|
}
|
|
|
|
|
2010-02-18 11:17:58 +08:00
|
|
|
// Emit the standard function epilogue.
|
|
|
|
FinishFunction(BodyRange.getEnd());
|
2010-08-04 06:46:07 +08:00
|
|
|
|
|
|
|
// If we haven't marked the function nothrow through other means, do
|
|
|
|
// a quick pass now to see if we can.
|
|
|
|
if (!CurFn->doesNotThrow())
|
|
|
|
TryMarkNoThrow(CurFn);
|
2007-05-30 07:50:05 +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.
|
|
|
|
bool CodeGenFunction::ContainsLabel(const Stmt *S, bool IgnoreCaseStmts) {
|
|
|
|
// Null statement, not a label!
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!S) return false;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a label, we have to emit the code, consider something like:
|
|
|
|
// if (0) { ... foo: bar(); } goto foo;
|
2011-02-28 08:18:40 +08:00
|
|
|
//
|
|
|
|
// TODO: If anyone cared, we could track __label__'s, since we know that you
|
|
|
|
// can't jump to one from outside their declared region.
|
2008-11-11 15:41:27 +08:00
|
|
|
if (isa<LabelStmt>(S))
|
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a case/default statement, and we haven't seen a switch, we have
|
|
|
|
// to emit the code.
|
|
|
|
if (isa<SwitchCase>(S) && !IgnoreCaseStmts)
|
|
|
|
return true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a switch statement, we want to ignore cases below it.
|
|
|
|
if (isa<SwitchStmt>(S))
|
|
|
|
IgnoreCaseStmts = true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// Scan subexpressions for verboten labels.
|
2015-07-03 05:03:14 +08:00
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (ContainsLabel(SubStmt, IgnoreCaseStmts))
|
2008-11-11 15:41:27 +08:00
|
|
|
return true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
bool CodeGenFunction::containsBreak(const Stmt *S) {
|
|
|
|
// Null statement, not a label!
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!S) return false;
|
2011-02-28 08:18:40 +08:00
|
|
|
|
|
|
|
// If this is a switch or loop that defines its own break scope, then we can
|
|
|
|
// include it and anything inside of it.
|
|
|
|
if (isa<SwitchStmt>(S) || isa<WhileStmt>(S) || isa<DoStmt>(S) ||
|
|
|
|
isa<ForStmt>(S))
|
2011-02-28 08:42:31 +08:00
|
|
|
return false;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:42:31 +08:00
|
|
|
if (isa<BreakStmt>(S))
|
2011-02-28 08:18:40 +08:00
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
// Scan subexpressions for verboten breaks.
|
2015-07-03 05:03:14 +08:00
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (containsBreak(SubStmt))
|
2011-02-28 08:18:40 +08:00
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-09-17 07:30:39 +08:00
|
|
|
bool CodeGenFunction::mightAddDeclToScope(const Stmt *S) {
|
|
|
|
if (!S) return false;
|
|
|
|
|
|
|
|
// Some statement kinds add a scope and thus never add a decl to the current
|
|
|
|
// scope. Note, this list is longer than the list of statements that might
|
|
|
|
// have an unscoped decl nested within them, but this way is conservatively
|
|
|
|
// correct even if more statement kinds are added.
|
|
|
|
if (isa<IfStmt>(S) || isa<SwitchStmt>(S) || isa<WhileStmt>(S) ||
|
|
|
|
isa<DoStmt>(S) || isa<ForStmt>(S) || isa<CompoundStmt>(S) ||
|
|
|
|
isa<CXXForRangeStmt>(S) || isa<CXXTryStmt>(S) ||
|
|
|
|
isa<ObjCForCollectionStmt>(S) || isa<ObjCAtTryStmt>(S))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (isa<DeclStmt>(S))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (mightAddDeclToScope(SubStmt))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2008-11-12 16:04:58 +08:00
|
|
|
|
2011-02-28 07:02:32 +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 boolean result in Result.
|
|
|
|
bool CodeGenFunction::ConstantFoldsToSimpleInteger(const Expr *Cond,
|
2016-06-24 03:16:49 +08:00
|
|
|
bool &ResultBool,
|
|
|
|
bool AllowLabels) {
|
2012-07-24 04:21:35 +08:00
|
|
|
llvm::APSInt ResultInt;
|
2016-06-24 03:16:49 +08:00
|
|
|
if (!ConstantFoldsToSimpleInteger(Cond, ResultInt, AllowLabels))
|
2011-02-28 08:18:40 +08:00
|
|
|
return false;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
ResultBool = ResultInt.getBoolValue();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// 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 CodeGenFunction::ConstantFoldsToSimpleInteger(const Expr *Cond,
|
|
|
|
llvm::APSInt &ResultInt,
|
|
|
|
bool AllowLabels) {
|
2008-11-13 06:37:10 +08:00
|
|
|
// FIXME: Rename and handle conversion of other evaluatable things
|
|
|
|
// to bool.
|
2011-12-29 03:48:30 +08:00
|
|
|
llvm::APSInt Int;
|
|
|
|
if (!Cond->EvaluateAsInt(Int, getContext()))
|
2011-02-28 07:02:32 +08:00
|
|
|
return false; // Not foldable, not integer or not fully evaluatable.
|
2011-12-29 03:48:30 +08:00
|
|
|
|
2016-06-24 03:16:49 +08:00
|
|
|
if (!AllowLabels && CodeGenFunction::ContainsLabel(Cond))
|
2011-02-28 07:02:32 +08:00
|
|
|
return false; // Contains a label.
|
2011-12-29 03:48:30 +08:00
|
|
|
|
|
|
|
ResultInt = Int;
|
2011-02-28 07:02:32 +08:00
|
|
|
return true;
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
|
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.
|
|
|
|
///
|
|
|
|
void CodeGenFunction::EmitBranchOnBoolExpr(const Expr *Cond,
|
|
|
|
llvm::BasicBlock *TrueBlock,
|
2014-01-07 06:27:43 +08:00
|
|
|
llvm::BasicBlock *FalseBlock,
|
|
|
|
uint64_t TrueCount) {
|
2011-04-15 08:35:48 +08:00
|
|
|
Cond = Cond->IgnoreParens();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
if (const BinaryOperator *CondBOp = dyn_cast<BinaryOperator>(Cond)) {
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Handle X && Y in a condition.
|
2010-08-25 19:45:40 +08:00
|
|
|
if (CondBOp->getOpcode() == BO_LAnd) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "1 && X", simplify the code. "0 && X" would have constant
|
|
|
|
// folded if the case was simple enough.
|
2011-03-05 05:46:03 +08:00
|
|
|
bool ConstantBool = false;
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getLHS(), ConstantBool) &&
|
|
|
|
ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(1 && X) -> br(X).
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "X && 1", simplify the code to use an uncond branch.
|
|
|
|
// "X && 0" would have been constant folded to 0.
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getRHS(), ConstantBool) &&
|
|
|
|
ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(X && 1) -> br(X).
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the LHS as a conditional. If the LHS conditional is false, we
|
|
|
|
// want to jump to the FalseBlock.
|
2008-11-13 09:38:36 +08:00
|
|
|
llvm::BasicBlock *LHSTrue = createBasicBlock("land.lhs.true");
|
2014-01-07 06:27:43 +08:00
|
|
|
// The counter tells us how often we evaluate RHS, and all of TrueCount
|
|
|
|
// can be propagated to that branch.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t RHSCount = getProfileCount(CondBOp->getRHS());
|
2011-01-26 12:00:11 +08:00
|
|
|
|
|
|
|
ConditionalEvaluation eval(*this);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), LHSTrue, FalseBlock, RHSCount);
|
|
|
|
EmitBlock(LHSTrue);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
|
|
|
setCurrentProfileCount(getProfileCount(CondBOp->getRHS()));
|
|
|
|
|
2010-01-24 08:20:05 +08:00
|
|
|
// Any temporaries created here are conditional.
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.begin(*this);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, TrueCount);
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.end(*this);
|
2010-01-24 08:20:05 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
return;
|
2011-02-28 07:02:32 +08:00
|
|
|
}
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 07:02:32 +08:00
|
|
|
if (CondBOp->getOpcode() == BO_LOr) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "0 || X", simplify the code. "1 || X" would have constant
|
|
|
|
// folded if the case was simple enough.
|
2011-03-05 05:46:03 +08:00
|
|
|
bool ConstantBool = false;
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getLHS(), ConstantBool) &&
|
|
|
|
!ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(0 || X) -> br(X).
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "X || 0", simplify the code to use an uncond branch.
|
|
|
|
// "X || 1" would have been constant folded to 1.
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getRHS(), ConstantBool) &&
|
|
|
|
!ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(X || 0) -> br(X).
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the LHS as a conditional. If the LHS conditional is true, we
|
|
|
|
// want to jump to the TrueBlock.
|
2008-11-13 09:38:36 +08:00
|
|
|
llvm::BasicBlock *LHSFalse = createBasicBlock("lor.lhs.false");
|
2014-01-07 06:27:43 +08:00
|
|
|
// We have the count for entry to the RHS and for the whole expression
|
|
|
|
// being true, so we can divy up True count between the short circuit and
|
|
|
|
// the RHS.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t LHSCount =
|
|
|
|
getCurrentProfileCount() - getProfileCount(CondBOp->getRHS());
|
2014-01-07 06:27:43 +08:00
|
|
|
uint64_t RHSCount = TrueCount - LHSCount;
|
2011-01-26 12:00:11 +08:00
|
|
|
|
|
|
|
ConditionalEvaluation eval(*this);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, LHSFalse, LHSCount);
|
|
|
|
EmitBlock(LHSFalse);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
|
|
|
setCurrentProfileCount(getProfileCount(CondBOp->getRHS()));
|
|
|
|
|
2010-01-24 08:20:05 +08:00
|
|
|
// Any temporaries created here are conditional.
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.begin(*this);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, RHSCount);
|
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.end(*this);
|
2010-01-24 08:20:05 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
return;
|
|
|
|
}
|
2008-11-12 16:13:36 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:13:36 +08:00
|
|
|
if (const UnaryOperator *CondUOp = dyn_cast<UnaryOperator>(Cond)) {
|
|
|
|
// br(!x, t, f) -> br(x, f, t)
|
2014-01-07 06:27:43 +08:00
|
|
|
if (CondUOp->getOpcode() == UO_LNot) {
|
|
|
|
// Negate the count.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t FalseCount = getCurrentProfileCount() - TrueCount;
|
2014-01-07 06:27:43 +08:00
|
|
|
// Negate the condition and swap the destination blocks.
|
|
|
|
return EmitBranchOnBoolExpr(CondUOp->getSubExpr(), FalseBlock, TrueBlock,
|
|
|
|
FalseCount);
|
|
|
|
}
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 18:30:32 +08:00
|
|
|
if (const ConditionalOperator *CondOp = dyn_cast<ConditionalOperator>(Cond)) {
|
2012-02-14 11:54:45 +08:00
|
|
|
// br(c ? x : y, t, f) -> br(c, br(x, t, f), br(y, t, f))
|
|
|
|
llvm::BasicBlock *LHSBlock = createBasicBlock("cond.true");
|
|
|
|
llvm::BasicBlock *RHSBlock = createBasicBlock("cond.false");
|
2008-11-12 18:30:32 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
ConditionalEvaluation cond(*this);
|
2015-04-24 07:06:47 +08:00
|
|
|
EmitBranchOnBoolExpr(CondOp->getCond(), LHSBlock, RHSBlock,
|
|
|
|
getProfileCount(CondOp));
|
2014-01-07 06:27:43 +08:00
|
|
|
|
|
|
|
// When computing PGO branch weights, we only know the overall count for
|
|
|
|
// the true block. This code is essentially doing tail duplication of the
|
|
|
|
// naive code-gen, introducing new edges for which counts are not
|
|
|
|
// available. Divide the counts proportionally between the LHS and RHS of
|
|
|
|
// the conditional operator.
|
|
|
|
uint64_t LHSScaledTrueCount = 0;
|
|
|
|
if (TrueCount) {
|
2015-04-24 07:06:47 +08:00
|
|
|
double LHSRatio =
|
|
|
|
getProfileCount(CondOp) / (double)getCurrentProfileCount();
|
2014-01-07 06:27:43 +08:00
|
|
|
LHSScaledTrueCount = TrueCount * LHSRatio;
|
|
|
|
}
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.begin(*this);
|
|
|
|
EmitBlock(LHSBlock);
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondOp);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
LHSScaledTrueCount);
|
|
|
|
}
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.end(*this);
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.begin(*this);
|
|
|
|
EmitBlock(RHSBlock);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount - LHSScaledTrueCount);
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.end(*this);
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
return;
|
2008-11-12 18:30:32 +08:00
|
|
|
}
|
|
|
|
|
2013-05-08 05:53:22 +08:00
|
|
|
if (const CXXThrowExpr *Throw = dyn_cast<CXXThrowExpr>(Cond)) {
|
|
|
|
// Conditional operator handling can give us a throw expression as a
|
|
|
|
// condition for a case like:
|
|
|
|
// br(c ? throw x : y, t, f) -> br(c, br(throw x, t, f), br(y, t, f)
|
|
|
|
// Fold this to:
|
|
|
|
// br(c, throw x, br(y, t, f))
|
|
|
|
EmitCXXThrowExpr(Throw, /*KeepInsertionPoint*/false);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-03 04:01:30 +08:00
|
|
|
// If the branch has a condition wrapped by __builtin_unpredictable,
|
|
|
|
// create metadata that specifies that the branch is unpredictable.
|
|
|
|
// Don't bother if not optimizing because that metadata would not be used.
|
|
|
|
llvm::MDNode *Unpredictable = nullptr;
|
2016-04-20 02:06:33 +08:00
|
|
|
auto *Call = dyn_cast<CallExpr>(Cond);
|
|
|
|
if (Call && CGM.getCodeGenOpts().OptimizationLevel != 0) {
|
|
|
|
auto *FD = dyn_cast_or_null<FunctionDecl>(Call->getCalleeDecl());
|
|
|
|
if (FD && FD->getBuiltinID() == Builtin::BI__builtin_unpredictable) {
|
|
|
|
llvm::MDBuilder MDHelper(getLLVMContext());
|
|
|
|
Unpredictable = MDHelper.createUnpredictable();
|
2015-09-03 04:01:30 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-07 06:27:43 +08:00
|
|
|
// Create branch weights based on the number of times we get here and the
|
|
|
|
// number of times the condition should be true.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t CurrentCount = std::max(getCurrentProfileCount(), TrueCount);
|
2015-05-02 13:00:55 +08:00
|
|
|
llvm::MDNode *Weights =
|
|
|
|
createProfileWeights(TrueCount, CurrentCount - TrueCount);
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the code with the fully general case.
|
2015-01-31 09:10:11 +08:00
|
|
|
llvm::Value *CondV;
|
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
CondV = EvaluateExprAsBool(Cond);
|
|
|
|
}
|
2015-09-03 04:01:30 +08:00
|
|
|
Builder.CreateCondBr(CondV, TrueBlock, FalseBlock, Weights, Unpredictable);
|
2008-11-12 16:04:58 +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 CodeGenFunction::ErrorUnsupported(const Stmt *S, const char *Type) {
|
|
|
|
CGM.ErrorUnsupported(S, Type);
|
2007-12-02 09:43:38 +08:00
|
|
|
}
|
|
|
|
|
2011-02-02 05:35:06 +08:00
|
|
|
/// emitNonZeroVLAInit - Emit the "zero" initialization of a
|
|
|
|
/// variable-length array whose elements have a non-zero bit-pattern.
|
|
|
|
///
|
2012-06-16 06:10:14 +08:00
|
|
|
/// \param baseType the inner-most element type of the array
|
2011-02-02 05:35:06 +08:00
|
|
|
/// \param src - a char* pointing to the bit-pattern for a single
|
|
|
|
/// base element of the array
|
|
|
|
/// \param sizeInChars - the total size of the VLA, in chars
|
|
|
|
static void emitNonZeroVLAInit(CodeGenFunction &CGF, 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 dest, Address src,
|
2011-02-02 05:35:06 +08:00
|
|
|
llvm::Value *sizeInChars) {
|
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
|
|
|
|
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 baseSize = CGF.getContext().getTypeSizeInChars(baseType);
|
2011-02-02 05:35:06 +08:00
|
|
|
llvm::Value *baseSizeInChars
|
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::ConstantInt::get(CGF.IntPtrTy, baseSize.getQuantity());
|
2011-02-02 05:35:06 +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 begin =
|
|
|
|
Builder.CreateElementBitCast(dest, CGF.Int8Ty, "vla.begin");
|
|
|
|
llvm::Value *end =
|
|
|
|
Builder.CreateInBoundsGEP(begin.getPointer(), sizeInChars, "vla.end");
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
llvm::BasicBlock *originBB = CGF.Builder.GetInsertBlock();
|
|
|
|
llvm::BasicBlock *loopBB = CGF.createBasicBlock("vla-init.loop");
|
|
|
|
llvm::BasicBlock *contBB = CGF.createBasicBlock("vla-init.cont");
|
|
|
|
|
|
|
|
// Make a loop over the VLA. C99 guarantees that the VLA element
|
|
|
|
// count must be nonzero.
|
|
|
|
CGF.EmitBlock(loopBB);
|
|
|
|
|
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::PHINode *cur = Builder.CreatePHI(begin.getType(), 2, "vla.cur");
|
|
|
|
cur->addIncoming(begin.getPointer(), originBB);
|
|
|
|
|
|
|
|
CharUnits curAlign =
|
|
|
|
dest.getAlignment().alignmentOfArrayElement(baseSize);
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
// memcpy the individual element bit-pattern.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemCpy(Address(cur, curAlign), src, baseSizeInChars,
|
2011-02-02 05:35:06 +08:00
|
|
|
/*volatile*/ false);
|
|
|
|
|
|
|
|
// Go to the next element.
|
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 *next =
|
|
|
|
Builder.CreateInBoundsGEP(CGF.Int8Ty, cur, baseSizeInChars, "vla.next");
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
// Leave if that's the end of the VLA.
|
|
|
|
llvm::Value *done = Builder.CreateICmpEQ(next, end, "vla-init.isdone");
|
|
|
|
Builder.CreateCondBr(done, contBB, loopBB);
|
|
|
|
cur->addIncoming(next, loopBB);
|
|
|
|
|
|
|
|
CGF.EmitBlock(contBB);
|
2012-12-04 08:29:55 +08:00
|
|
|
}
|
2011-02-02 05:35:06 +08:00
|
|
|
|
2010-05-23 01:35:42 +08:00
|
|
|
void
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CodeGenFunction::EmitNullInitialization(Address DestPtr, QualType Ty) {
|
2010-05-03 09:20:20 +08:00
|
|
|
// Ignore empty classes in C++.
|
2012-11-02 06:30:59 +08:00
|
|
|
if (getLangOpts().CPlusPlus) {
|
2010-05-03 09:20:20 +08:00
|
|
|
if (const RecordType *RT = Ty->getAs<RecordType>()) {
|
|
|
|
if (cast<CXXRecordDecl>(RT->getDecl())->isEmpty())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2010-08-07 16:21:30 +08:00
|
|
|
|
|
|
|
// Cast the dest ptr to the appropriate i8 pointer 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
|
|
|
if (DestPtr.getElementType() != Int8Ty)
|
|
|
|
DestPtr = Builder.CreateElementBitCast(DestPtr, Int8Ty);
|
2008-08-31 03:51:14 +08:00
|
|
|
|
|
|
|
// Get size and alignment info for this aggregate.
|
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 size = getContext().getTypeSizeInChars(Ty);
|
2008-08-31 03:51:14 +08:00
|
|
|
|
2011-01-14 18:37:58 +08:00
|
|
|
llvm::Value *SizeVal;
|
2011-02-02 05:35:06 +08:00
|
|
|
const VariableArrayType *vla;
|
2010-08-07 16:21:30 +08:00
|
|
|
|
2011-01-14 18:37:58 +08:00
|
|
|
// Don't bother emitting a zero-byte memset.
|
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 (size.isZero()) {
|
2011-01-14 18:37:58 +08:00
|
|
|
// But note that getTypeInfo returns 0 for a VLA.
|
|
|
|
if (const VariableArrayType *vlaType =
|
|
|
|
dyn_cast_or_null<VariableArrayType>(
|
|
|
|
getContext().getAsArrayType(Ty))) {
|
2011-06-25 05:55:10 +08:00
|
|
|
QualType eltType;
|
|
|
|
llvm::Value *numElts;
|
2014-03-02 21:01:17 +08:00
|
|
|
std::tie(numElts, eltType) = getVLASize(vlaType);
|
2011-06-25 05:55:10 +08:00
|
|
|
|
|
|
|
SizeVal = numElts;
|
|
|
|
CharUnits eltSize = getContext().getTypeSizeInChars(eltType);
|
|
|
|
if (!eltSize.isOne())
|
|
|
|
SizeVal = Builder.CreateNUWMul(SizeVal, CGM.getSize(eltSize));
|
2011-02-02 05:35:06 +08:00
|
|
|
vla = vlaType;
|
2011-01-14 18:37:58 +08:00
|
|
|
} else {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
SizeVal = CGM.getSize(size);
|
2014-05-21 13:09:00 +08:00
|
|
|
vla = nullptr;
|
2011-01-14 18:37:58 +08:00
|
|
|
}
|
2010-08-07 16:21:30 +08:00
|
|
|
|
|
|
|
// If the type contains a pointer to data member we can't memset it to zero.
|
|
|
|
// Instead, create a null constant and copy it to the destination.
|
2011-02-02 05:35:06 +08:00
|
|
|
// TODO: there are other patterns besides zero that we can usefully memset,
|
|
|
|
// like -1, which happens to be the pattern used by member-pointers.
|
2010-08-23 05:01:12 +08:00
|
|
|
if (!CGM.getTypes().isZeroInitializable(Ty)) {
|
2011-02-02 05:35:06 +08:00
|
|
|
// For a VLA, emit a single element, then splat that over the VLA.
|
|
|
|
if (vla) Ty = getContext().getBaseElementType(vla);
|
2011-01-14 18:37:58 +08:00
|
|
|
|
2010-08-07 16:21:30 +08:00
|
|
|
llvm::Constant *NullConstant = CGM.EmitNullConstant(Ty);
|
|
|
|
|
2012-12-04 08:29:55 +08:00
|
|
|
llvm::GlobalVariable *NullVariable =
|
2010-08-07 16:21:30 +08:00
|
|
|
new llvm::GlobalVariable(CGM.getModule(), NullConstant->getType(),
|
2012-12-04 08:29:55 +08:00
|
|
|
/*isConstant=*/true,
|
2010-08-07 16:21:30 +08:00
|
|
|
llvm::GlobalVariable::PrivateLinkage,
|
2011-07-23 18:55:15 +08:00
|
|
|
NullConstant, Twine());
|
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 NullAlign = DestPtr.getAlignment();
|
|
|
|
NullVariable->setAlignment(NullAlign.getQuantity());
|
|
|
|
Address SrcPtr(Builder.CreateBitCast(NullVariable, Builder.getInt8PtrTy()),
|
|
|
|
NullAlign);
|
2010-08-07 16:21:30 +08:00
|
|
|
|
2011-02-02 05:35:06 +08:00
|
|
|
if (vla) return emitNonZeroVLAInit(*this, Ty, DestPtr, SrcPtr, SizeVal);
|
|
|
|
|
2010-08-07 16:21:30 +08:00
|
|
|
// Get and call the appropriate llvm.memcpy overload.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemCpy(DestPtr, SrcPtr, SizeVal, false);
|
2009-04-22 01:59:23 +08:00
|
|
|
return;
|
2012-12-04 08:29:55 +08:00
|
|
|
}
|
|
|
|
|
2010-08-07 16:21:30 +08:00
|
|
|
// Otherwise, just memset the whole thing to zero. This is legal
|
|
|
|
// because in LLVM, all default initializers (other than the ones we just
|
|
|
|
// handled above) are guaranteed to have a bit pattern of all zeros.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemSet(DestPtr, Builder.getInt8(0), SizeVal, false);
|
2008-08-31 03:51:14 +08:00
|
|
|
}
|
|
|
|
|
2011-02-17 15:39:24 +08:00
|
|
|
llvm::BlockAddress *CodeGenFunction::GetAddrOfLabel(const LabelDecl *L) {
|
2009-10-29 07:59:40 +08:00
|
|
|
// Make sure that there is a block for the indirect goto.
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!IndirectBranch)
|
2009-10-29 07:59:40 +08:00
|
|
|
GetIndirectGotoBlock();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
llvm::BasicBlock *BB = getJumpDestForLabel(L).getBlock();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// Make sure the indirect branch includes all of the address-taken blocks.
|
|
|
|
IndirectBranch->addDestination(BB);
|
|
|
|
return llvm::BlockAddress::get(CurFn, BB);
|
2009-10-13 14:55:33 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-10-13 14:55:33 +08:00
|
|
|
llvm::BasicBlock *CodeGenFunction::GetIndirectGotoBlock() {
|
2009-10-29 07:59:40 +08:00
|
|
|
// If we already made the indirect branch for indirect goto, return its block.
|
|
|
|
if (IndirectBranch) return IndirectBranch->getParent();
|
2012-12-04 08:29:55 +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
|
|
|
CGBuilderTy TmpBuilder(*this, createBasicBlock("indirectgoto"));
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-13 14:55:33 +08:00
|
|
|
// Create the PHI node that indirect gotos will add entries to.
|
2011-03-30 19:28:58 +08:00
|
|
|
llvm::Value *DestVal = TmpBuilder.CreatePHI(Int8PtrTy, 0,
|
|
|
|
"indirect.goto.dest");
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// Create the indirect branch instruction.
|
|
|
|
IndirectBranch = TmpBuilder.CreateIndirectBr(DestVal);
|
|
|
|
return IndirectBranch->getParent();
|
2008-08-05 00:51:22 +08:00
|
|
|
}
|
2008-11-04 13:30:00 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
/// Computes the length of an array in elements, as well as the base
|
|
|
|
/// element type and a properly-typed first element pointer.
|
|
|
|
llvm::Value *CodeGenFunction::emitArrayLength(const ArrayType *origArrayType,
|
|
|
|
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
|
|
|
const ArrayType *arrayType = origArrayType;
|
|
|
|
|
|
|
|
// If it's a VLA, we have to load the stored size. Note that
|
|
|
|
// this is the size of the VLA in bytes, not its size in elements.
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Value *numVLAElements = nullptr;
|
2011-07-09 09:37:26 +08:00
|
|
|
if (isa<VariableArrayType>(arrayType)) {
|
|
|
|
numVLAElements = getVLASize(cast<VariableArrayType>(arrayType)).first;
|
|
|
|
|
|
|
|
// Walk into all VLAs. This doesn't require changes to addr,
|
|
|
|
// which has type T* where T is the first non-VLA element type.
|
|
|
|
do {
|
|
|
|
QualType elementType = arrayType->getElementType();
|
|
|
|
arrayType = getContext().getAsArrayType(elementType);
|
|
|
|
|
|
|
|
// If we only have VLA components, 'addr' requires no adjustment.
|
|
|
|
if (!arrayType) {
|
|
|
|
baseType = elementType;
|
|
|
|
return numVLAElements;
|
|
|
|
}
|
|
|
|
} while (isa<VariableArrayType>(arrayType));
|
|
|
|
|
|
|
|
// We get out here only if we find a constant array type
|
|
|
|
// inside the VLA.
|
|
|
|
}
|
|
|
|
|
|
|
|
// We have some number of constant-length arrays, so addr should
|
|
|
|
// have LLVM type [M x [N x [...]]]*. Build a GEP that walks
|
|
|
|
// down to the first element of addr.
|
2011-07-23 18:55:15 +08:00
|
|
|
SmallVector<llvm::Value*, 8> gepIndices;
|
2011-07-09 09:37:26 +08:00
|
|
|
|
|
|
|
// GEP down to the array type.
|
|
|
|
llvm::ConstantInt *zero = Builder.getInt32(0);
|
|
|
|
gepIndices.push_back(zero);
|
|
|
|
|
|
|
|
uint64_t countFromCLAs = 1;
|
2012-04-22 13:51:36 +08:00
|
|
|
QualType eltType;
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2011-07-18 12:24:23 +08:00
|
|
|
llvm::ArrayType *llvmArrayType =
|
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
|
|
|
dyn_cast<llvm::ArrayType>(addr.getElementType());
|
2012-04-22 13:51:36 +08:00
|
|
|
while (llvmArrayType) {
|
2011-07-09 09:37:26 +08:00
|
|
|
assert(isa<ConstantArrayType>(arrayType));
|
|
|
|
assert(cast<ConstantArrayType>(arrayType)->getSize().getZExtValue()
|
|
|
|
== llvmArrayType->getNumElements());
|
|
|
|
|
|
|
|
gepIndices.push_back(zero);
|
|
|
|
countFromCLAs *= llvmArrayType->getNumElements();
|
2012-04-22 13:51:36 +08:00
|
|
|
eltType = arrayType->getElementType();
|
2011-07-09 09:37:26 +08:00
|
|
|
|
|
|
|
llvmArrayType =
|
|
|
|
dyn_cast<llvm::ArrayType>(llvmArrayType->getElementType());
|
|
|
|
arrayType = getContext().getAsArrayType(arrayType->getElementType());
|
2012-04-22 13:51:36 +08:00
|
|
|
assert((!llvmArrayType || arrayType) &&
|
|
|
|
"LLVM and Clang types are out-of-synch");
|
2011-07-09 09:37:26 +08:00
|
|
|
}
|
|
|
|
|
2012-04-22 13:51:36 +08:00
|
|
|
if (arrayType) {
|
|
|
|
// From this point onwards, the Clang array type has been emitted
|
|
|
|
// as some other type (probably a packed struct). Compute the array
|
|
|
|
// size, and just emit the 'begin' expression as a bitcast.
|
|
|
|
while (arrayType) {
|
|
|
|
countFromCLAs *=
|
|
|
|
cast<ConstantArrayType>(arrayType)->getSize().getZExtValue();
|
|
|
|
eltType = arrayType->getElementType();
|
|
|
|
arrayType = getContext().getAsArrayType(eltType);
|
|
|
|
}
|
|
|
|
|
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 *baseType = ConvertType(eltType);
|
|
|
|
addr = Builder.CreateElementBitCast(addr, baseType, "array.begin");
|
2012-04-22 13:51:36 +08:00
|
|
|
} else {
|
|
|
|
// Create the actual GEP.
|
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
|
|
|
addr = Address(Builder.CreateInBoundsGEP(addr.getPointer(),
|
|
|
|
gepIndices, "array.begin"),
|
|
|
|
addr.getAlignment());
|
2012-04-22 13:51:36 +08:00
|
|
|
}
|
2011-07-09 09:37:26 +08:00
|
|
|
|
2012-04-22 13:51:36 +08:00
|
|
|
baseType = eltType;
|
2011-07-09 09:37:26 +08:00
|
|
|
|
|
|
|
llvm::Value *numElements
|
|
|
|
= llvm::ConstantInt::get(SizeTy, countFromCLAs);
|
|
|
|
|
|
|
|
// If we had any VLA dimensions, factor them in.
|
|
|
|
if (numVLAElements)
|
|
|
|
numElements = Builder.CreateNUWMul(numVLAElements, numElements);
|
|
|
|
|
|
|
|
return numElements;
|
|
|
|
}
|
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
std::pair<llvm::Value*, QualType>
|
|
|
|
CodeGenFunction::getVLASize(QualType type) {
|
|
|
|
const VariableArrayType *vla = getContext().getAsVariableArrayType(type);
|
|
|
|
assert(vla && "type was not a variable array type!");
|
|
|
|
return getVLASize(vla);
|
2008-12-21 04:27:15 +08:00
|
|
|
}
|
2008-12-12 15:19:02 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
std::pair<llvm::Value*, QualType>
|
|
|
|
CodeGenFunction::getVLASize(const VariableArrayType *type) {
|
|
|
|
// The number of elements so far; always size_t.
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Value *numElements = nullptr;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
QualType elementType;
|
|
|
|
do {
|
|
|
|
elementType = type->getElementType();
|
|
|
|
llvm::Value *vlaSize = VLASizeMap[type->getSizeExpr()];
|
|
|
|
assert(vlaSize && "no size for VLA!");
|
|
|
|
assert(vlaSize->getType() == SizeTy);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
if (!numElements) {
|
|
|
|
numElements = vlaSize;
|
|
|
|
} else {
|
|
|
|
// It's undefined behavior if this wraps around, so mark it that way.
|
2014-03-20 18:48:29 +08:00
|
|
|
// FIXME: Teach -fsanitize=undefined to trap this.
|
2011-06-25 05:55:10 +08:00
|
|
|
numElements = Builder.CreateNUWMul(numElements, vlaSize);
|
|
|
|
}
|
|
|
|
} while ((type = getContext().getAsVariableArrayType(elementType)));
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
return std::pair<llvm::Value*,QualType>(numElements, elementType);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
void CodeGenFunction::EmitVariablyModifiedType(QualType type) {
|
|
|
|
assert(type->isVariablyModifiedType() &&
|
|
|
|
"Must pass variably modified type to EmitVLASizes!");
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
EnsureInsertPoint();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
// We're going to walk down into the type and look for VLA
|
|
|
|
// expressions.
|
|
|
|
do {
|
|
|
|
assert(type->isVariablyModifiedType());
|
|
|
|
|
|
|
|
const Type *ty = type.getTypePtr();
|
|
|
|
switch (ty->getTypeClass()) {
|
2012-01-07 18:52:36 +08:00
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
#define TYPE(Class, Base)
|
|
|
|
#define ABSTRACT_TYPE(Class, Base)
|
2012-01-07 18:52:36 +08:00
|
|
|
#define NON_CANONICAL_TYPE(Class, Base)
|
2011-06-25 05:55:10 +08:00
|
|
|
#define DEPENDENT_TYPE(Class, Base) case Type::Class:
|
2012-01-07 18:52:36 +08:00
|
|
|
#define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(Class, Base)
|
2011-06-25 05:55:10 +08:00
|
|
|
#include "clang/AST/TypeNodes.def"
|
2012-01-07 18:52:36 +08:00
|
|
|
llvm_unreachable("unexpected dependent type!");
|
2011-06-25 05:55:10 +08:00
|
|
|
|
|
|
|
// These types are never variably-modified.
|
|
|
|
case Type::Builtin:
|
|
|
|
case Type::Complex:
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::Record:
|
|
|
|
case Type::Enum:
|
2012-01-11 16:19:46 +08:00
|
|
|
case Type::Elaborated:
|
|
|
|
case Type::TemplateSpecialization:
|
2016-09-14 01:25:08 +08:00
|
|
|
case Type::ObjCTypeParam:
|
2011-06-25 05:55:10 +08:00
|
|
|
case Type::ObjCObject:
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
case Type::ObjCObjectPointer:
|
|
|
|
llvm_unreachable("type class is never variably-modified!");
|
|
|
|
|
2013-12-05 09:23:43 +08:00
|
|
|
case Type::Adjusted:
|
|
|
|
type = cast<AdjustedType>(ty)->getAdjustedType();
|
|
|
|
break;
|
|
|
|
|
2013-06-25 01:51:48 +08:00
|
|
|
case Type::Decayed:
|
|
|
|
type = cast<DecayedType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
case Type::Pointer:
|
|
|
|
type = cast<PointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::BlockPointer:
|
|
|
|
type = cast<BlockPointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
type = cast<ReferenceType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::MemberPointer:
|
|
|
|
type = cast<MemberPointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
// Losing element qualification here is fine.
|
|
|
|
type = cast<ArrayType>(ty)->getElementType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::VariableArray: {
|
|
|
|
// Losing element qualification here is fine.
|
|
|
|
const VariableArrayType *vat = cast<VariableArrayType>(ty);
|
|
|
|
|
|
|
|
// Unknown size indication requires no size computation.
|
|
|
|
// Otherwise, evaluate and record it.
|
|
|
|
if (const Expr *size = vat->getSizeExpr()) {
|
|
|
|
// It's possible that we might have emitted this already,
|
|
|
|
// e.g. with a typedef and a pointer to it.
|
|
|
|
llvm::Value *&entry = VLASizeMap[size];
|
|
|
|
if (!entry) {
|
2012-10-10 09:11:12 +08:00
|
|
|
llvm::Value *Size = EmitScalarExpr(size);
|
|
|
|
|
|
|
|
// C11 6.7.6.2p5:
|
|
|
|
// If the size is an expression that is not an integer constant
|
|
|
|
// expression [...] each time it is evaluated it shall have a value
|
|
|
|
// greater than zero.
|
2014-11-08 06:29:38 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::VLABound) &&
|
2012-11-06 06:21:05 +08:00
|
|
|
size->getType()->isSignedIntegerType()) {
|
2014-07-18 02:46:27 +08:00
|
|
|
SanitizerScope SanScope(this);
|
2012-10-10 09:11:12 +08:00
|
|
|
llvm::Value *Zero = llvm::Constant::getNullValue(Size->getType());
|
|
|
|
llvm::Constant *StaticArgs[] = {
|
|
|
|
EmitCheckSourceLocation(size->getLocStart()),
|
|
|
|
EmitCheckTypeDescriptor(size->getType())
|
|
|
|
};
|
2014-11-12 06:03:54 +08:00
|
|
|
EmitCheck(std::make_pair(Builder.CreateICmpSGT(Size, Zero),
|
|
|
|
SanitizerKind::VLABound),
|
2016-12-13 00:18:40 +08:00
|
|
|
SanitizerHandler::VLABoundNotPositive, StaticArgs, Size);
|
2012-10-10 09:11:12 +08:00
|
|
|
}
|
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
// Always zexting here would be wrong if it weren't
|
|
|
|
// undefined behavior to have a negative bound.
|
2012-10-10 09:12:11 +08:00
|
|
|
entry = Builder.CreateIntCast(Size, SizeTy, /*signed*/ false);
|
2011-06-25 05:55:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
type = vat->getElementType();
|
|
|
|
break;
|
2008-12-21 05:51:53 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2012-01-07 18:52:36 +08:00
|
|
|
case Type::FunctionProto:
|
2011-06-25 05:55:10 +08:00
|
|
|
case Type::FunctionNoProto:
|
2014-01-26 00:55:45 +08:00
|
|
|
type = cast<FunctionType>(ty)->getReturnType();
|
2011-06-25 05:55:10 +08:00
|
|
|
break;
|
2011-10-07 07:00:33 +08:00
|
|
|
|
2012-01-11 16:19:46 +08:00
|
|
|
case Type::Paren:
|
|
|
|
case Type::TypeOf:
|
|
|
|
case Type::UnaryTransform:
|
|
|
|
case Type::Attributed:
|
|
|
|
case Type::SubstTemplateTypeParm:
|
2013-07-14 05:08:08 +08:00
|
|
|
case Type::PackExpansion:
|
2012-01-11 16:19:46 +08:00
|
|
|
// Keep walking after single level desugaring.
|
|
|
|
type = type.getSingleStepDesugaredType(getContext());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Typedef:
|
|
|
|
case Type::Decltype:
|
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
2012-01-11 16:19:46 +08:00
|
|
|
// Stop walking: nothing to do.
|
|
|
|
return;
|
|
|
|
|
|
|
|
case Type::TypeOfExpr:
|
|
|
|
// Stop walking: emit typeof expression.
|
|
|
|
EmitIgnoredExpr(cast<TypeOfExprType>(ty)->getUnderlyingExpr());
|
|
|
|
return;
|
|
|
|
|
2011-10-07 07:00:33 +08:00
|
|
|
case Type::Atomic:
|
|
|
|
type = cast<AtomicType>(ty)->getValueType();
|
|
|
|
break;
|
2016-01-09 20:53:17 +08:00
|
|
|
|
|
|
|
case Type::Pipe:
|
|
|
|
type = cast<PipeType>(ty)->getElementType();
|
|
|
|
break;
|
2011-06-25 05:55:10 +08:00
|
|
|
}
|
|
|
|
} while (type->isVariablyModifiedType());
|
2008-12-12 15:19:02 +08:00
|
|
|
}
|
2009-01-21 01:46:04 +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 CodeGenFunction::EmitVAListRef(const Expr* E) {
|
2010-10-30 06:47:07 +08:00
|
|
|
if (getContext().getBuiltinVaListType()->isArrayType())
|
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 EmitPointerWithAlignment(E);
|
2009-01-21 01:46:04 +08:00
|
|
|
return EmitLValue(E).getAddress();
|
|
|
|
}
|
2009-02-08 06:53:43 +08:00
|
|
|
|
2015-09-18 04:55:33 +08:00
|
|
|
Address CodeGenFunction::EmitMSVAListRef(const Expr *E) {
|
|
|
|
return EmitLValue(E).getAddress();
|
|
|
|
}
|
|
|
|
|
2013-08-30 16:53:09 +08:00
|
|
|
void CodeGenFunction::EmitDeclRefExprDbgValue(const DeclRefExpr *E,
|
2016-09-13 09:13:19 +08:00
|
|
|
const APValue &Init) {
|
|
|
|
assert(!Init.isUninit() && "Invalid DeclRefExpr initializer!");
|
2013-08-30 16:53:09 +08:00
|
|
|
if (CGDebugInfo *Dbg = getDebugInfo())
|
2016-02-02 19:06:51 +08:00
|
|
|
if (CGM.getCodeGenOpts().getDebugInfo() >= codegenoptions::LimitedDebugInfo)
|
2013-08-30 16:53:09 +08:00
|
|
|
Dbg->EmitGlobalVariable(E->getDecl(), Init);
|
2010-08-10 15:24:25 +08:00
|
|
|
}
|
2011-02-17 18:25:35 +08:00
|
|
|
|
|
|
|
CodeGenFunction::PeepholeProtection
|
|
|
|
CodeGenFunction::protectFromPeepholes(RValue rvalue) {
|
|
|
|
// At the moment, the only aggressive peephole we do in IR gen
|
|
|
|
// is trunc(zext) folding, but if we add more, we can easily
|
|
|
|
// extend this protection.
|
|
|
|
|
|
|
|
if (!rvalue.isScalar()) return PeepholeProtection();
|
|
|
|
llvm::Value *value = rvalue.getScalarVal();
|
|
|
|
if (!isa<llvm::ZExtInst>(value)) return PeepholeProtection();
|
|
|
|
|
|
|
|
// Just make an extra bitcast.
|
|
|
|
assert(HaveInsertPoint());
|
|
|
|
llvm::Instruction *inst = new llvm::BitCastInst(value, value->getType(), "",
|
|
|
|
Builder.GetInsertBlock());
|
|
|
|
|
|
|
|
PeepholeProtection protection;
|
|
|
|
protection.Inst = inst;
|
|
|
|
return protection;
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGenFunction::unprotectFromPeepholes(PeepholeProtection protection) {
|
|
|
|
if (!protection.Inst) return;
|
|
|
|
|
|
|
|
// In theory, we could try to duplicate the peepholes now, but whatever.
|
|
|
|
protection.Inst->eraseFromParent();
|
|
|
|
}
|
2011-09-10 06:41:49 +08:00
|
|
|
|
|
|
|
llvm::Value *CodeGenFunction::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) {
|
|
|
|
llvm::Value *Args[4] = {
|
|
|
|
AnnotatedVal,
|
|
|
|
Builder.CreateBitCast(CGM.EmitAnnotationString(AnnotationStr), Int8PtrTy),
|
|
|
|
Builder.CreateBitCast(CGM.EmitAnnotationUnit(Location), Int8PtrTy),
|
|
|
|
CGM.EmitAnnotationLineNo(Location)
|
|
|
|
};
|
|
|
|
return Builder.CreateCall(AnnotationFn, Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGenFunction::EmitVarAnnotations(const VarDecl *D, llvm::Value *V) {
|
|
|
|
assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
|
|
|
|
// FIXME We create a new bitcast for every annotation because that's what
|
|
|
|
// llvm-gcc was doing.
|
2014-03-11 01:08:28 +08:00
|
|
|
for (const auto *I : D->specific_attrs<AnnotateAttr>())
|
2011-09-10 06:41:49 +08:00
|
|
|
EmitAnnotationCall(CGM.getIntrinsic(llvm::Intrinsic::var_annotation),
|
|
|
|
Builder.CreateBitCast(V, CGM.Int8PtrTy, V->getName()),
|
2014-03-11 01:08:28 +08:00
|
|
|
I->getAnnotation(), D->getLocation());
|
2011-09-10 06:41:49 +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 CodeGenFunction::EmitFieldAnnotations(const FieldDecl *D,
|
|
|
|
Address Addr) {
|
2011-09-10 06:41:49 +08:00
|
|
|
assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
|
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 *V = Addr.getPointer();
|
2011-09-10 06:41:49 +08:00
|
|
|
llvm::Type *VTy = V->getType();
|
|
|
|
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::ptr_annotation,
|
|
|
|
CGM.Int8PtrTy);
|
|
|
|
|
2014-03-11 01:08:28 +08:00
|
|
|
for (const auto *I : D->specific_attrs<AnnotateAttr>()) {
|
2011-09-10 06:41:49 +08:00
|
|
|
// FIXME Always emit the cast inst so we can differentiate between
|
|
|
|
// annotation on the first field of a struct and annotation on the struct
|
|
|
|
// itself.
|
|
|
|
if (VTy != CGM.Int8PtrTy)
|
|
|
|
V = Builder.Insert(new llvm::BitCastInst(V, CGM.Int8PtrTy));
|
2014-03-11 01:08:28 +08:00
|
|
|
V = EmitAnnotationCall(F, V, I->getAnnotation(), D->getLocation());
|
2011-09-10 06:41:49 +08:00
|
|
|
V = Builder.CreateBitCast(V, VTy);
|
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return Address(V, Addr.getAlignment());
|
2011-09-10 06:41:49 +08:00
|
|
|
}
|
2013-05-10 03:17:11 +08:00
|
|
|
|
2015-10-20 21:23:58 +08:00
|
|
|
CodeGenFunction::CGCapturedStmtInfo::~CGCapturedStmtInfo() { }
|
2014-05-22 16:54:05 +08:00
|
|
|
|
2014-07-18 02:46:27 +08:00
|
|
|
CodeGenFunction::SanitizerScope::SanitizerScope(CodeGenFunction *CGF)
|
|
|
|
: CGF(CGF) {
|
|
|
|
assert(!CGF->IsSanitizerScope);
|
|
|
|
CGF->IsSanitizerScope = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeGenFunction::SanitizerScope::~SanitizerScope() {
|
|
|
|
CGF->IsSanitizerScope = false;
|
|
|
|
}
|
|
|
|
|
2014-05-22 16:54:05 +08:00
|
|
|
void CodeGenFunction::InsertHelper(llvm::Instruction *I,
|
|
|
|
const llvm::Twine &Name,
|
|
|
|
llvm::BasicBlock *BB,
|
|
|
|
llvm::BasicBlock::iterator InsertPt) const {
|
|
|
|
LoopStack.InsertHelper(I);
|
2014-08-26 10:29:59 +08:00
|
|
|
if (IsSanitizerScope)
|
|
|
|
CGM.getSanitizerMetadata()->disableSanitizerForInstruction(I);
|
2014-05-22 16:54:05 +08:00
|
|
|
}
|
|
|
|
|
2016-03-14 05:05:23 +08:00
|
|
|
void CGBuilderInserter::InsertHelper(
|
2014-05-22 16:54:05 +08:00
|
|
|
llvm::Instruction *I, const llvm::Twine &Name, llvm::BasicBlock *BB,
|
|
|
|
llvm::BasicBlock::iterator InsertPt) const {
|
2016-03-14 05:05:23 +08:00
|
|
|
llvm::IRBuilderDefaultInserter::InsertHelper(I, Name, BB, InsertPt);
|
2014-05-22 16:54:05 +08:00
|
|
|
if (CGF)
|
|
|
|
CGF->InsertHelper(I, Name, BB, InsertPt);
|
|
|
|
}
|
|
|
|
|
2015-11-12 09:09:58 +08:00
|
|
|
static bool hasRequiredFeatures(const SmallVectorImpl<StringRef> &ReqFeatures,
|
2015-11-14 10:38:37 +08:00
|
|
|
CodeGenModule &CGM, const FunctionDecl *FD,
|
|
|
|
std::string &FirstMissing) {
|
2015-11-12 09:09:58 +08:00
|
|
|
// If there aren't any required features listed then go ahead and return.
|
|
|
|
if (ReqFeatures.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Now build up the set of caller features and verify that all the required
|
|
|
|
// features are there.
|
|
|
|
llvm::StringMap<bool> CallerFeatureMap;
|
|
|
|
CGM.getFunctionFeatureMap(CallerFeatureMap, FD);
|
|
|
|
|
|
|
|
// If we have at least one of the features in the feature list return
|
|
|
|
// true, otherwise return false.
|
|
|
|
return std::all_of(
|
|
|
|
ReqFeatures.begin(), ReqFeatures.end(), [&](StringRef Feature) {
|
|
|
|
SmallVector<StringRef, 1> OrFeatures;
|
|
|
|
Feature.split(OrFeatures, "|");
|
|
|
|
return std::any_of(OrFeatures.begin(), OrFeatures.end(),
|
|
|
|
[&](StringRef Feature) {
|
2015-11-14 10:38:37 +08:00
|
|
|
if (!CallerFeatureMap.lookup(Feature)) {
|
|
|
|
FirstMissing = Feature.str();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
2015-11-12 09:09:58 +08:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-11-12 08:44:12 +08:00
|
|
|
// Emits an error if we don't have a valid set of target features for the
|
|
|
|
// called function.
|
2015-11-12 08:44:07 +08:00
|
|
|
void CodeGenFunction::checkTargetFeatures(const CallExpr *E,
|
|
|
|
const FunctionDecl *TargetDecl) {
|
|
|
|
// Early exit if this is an indirect call.
|
|
|
|
if (!TargetDecl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Get the current enclosing function if it exists. If it doesn't
|
|
|
|
// we can't check the target features anyhow.
|
|
|
|
const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(CurFuncDecl);
|
|
|
|
if (!FD)
|
|
|
|
return;
|
|
|
|
|
2015-11-12 08:44:12 +08:00
|
|
|
// Grab the required features for the call. For a builtin this is listed in
|
|
|
|
// the td file with the default cpu, for an always_inline function this is any
|
|
|
|
// listed cpu and any listed features.
|
2015-11-12 08:44:07 +08:00
|
|
|
unsigned BuiltinID = TargetDecl->getBuiltinID();
|
2015-11-14 10:38:37 +08:00
|
|
|
std::string MissingFeature;
|
2015-11-12 08:44:12 +08:00
|
|
|
if (BuiltinID) {
|
|
|
|
SmallVector<StringRef, 1> ReqFeatures;
|
|
|
|
const char *FeatureList =
|
|
|
|
CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
|
|
|
|
// Return if the builtin doesn't have any required features.
|
|
|
|
if (!FeatureList || StringRef(FeatureList) == "")
|
|
|
|
return;
|
|
|
|
StringRef(FeatureList).split(ReqFeatures, ",");
|
2015-11-14 10:38:37 +08:00
|
|
|
if (!hasRequiredFeatures(ReqFeatures, CGM, FD, MissingFeature))
|
2015-11-12 08:44:12 +08:00
|
|
|
CGM.getDiags().Report(E->getLocStart(), diag::err_builtin_needs_feature)
|
|
|
|
<< TargetDecl->getDeclName()
|
|
|
|
<< CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
|
|
|
|
|
|
|
|
} else if (TargetDecl->hasAttr<TargetAttr>()) {
|
|
|
|
// Get the required features for the callee.
|
|
|
|
SmallVector<StringRef, 1> ReqFeatures;
|
|
|
|
llvm::StringMap<bool> CalleeFeatureMap;
|
|
|
|
CGM.getFunctionFeatureMap(CalleeFeatureMap, TargetDecl);
|
2015-11-17 02:29:59 +08:00
|
|
|
for (const auto &F : CalleeFeatureMap) {
|
|
|
|
// Only positive features are "required".
|
|
|
|
if (F.getValue())
|
|
|
|
ReqFeatures.push_back(F.getKey());
|
|
|
|
}
|
2015-11-14 10:38:37 +08:00
|
|
|
if (!hasRequiredFeatures(ReqFeatures, CGM, FD, MissingFeature))
|
2015-11-12 08:44:12 +08:00
|
|
|
CGM.getDiags().Report(E->getLocStart(), diag::err_function_needs_feature)
|
2015-11-14 10:38:37 +08:00
|
|
|
<< FD->getDeclName() << TargetDecl->getDeclName() << MissingFeature;
|
2015-11-12 08:44:12 +08:00
|
|
|
}
|
|
|
|
}
|
2016-01-16 08:31:22 +08:00
|
|
|
|
|
|
|
void CodeGenFunction::EmitSanitizerStatReport(llvm::SanitizerStatKind SSK) {
|
|
|
|
if (!CGM.getCodeGenOpts().SanitizeStats)
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::IRBuilder<> IRB(Builder.GetInsertBlock(), Builder.GetInsertPoint());
|
|
|
|
IRB.SetCurrentDebugLocation(Builder.getCurrentDebugLocation());
|
|
|
|
CGM.getSanStats().create(IRB, SSK);
|
|
|
|
}
|
2016-11-10 22:44:30 +08:00
|
|
|
|
|
|
|
llvm::DebugLoc CodeGenFunction::SourceLocToDebugLoc(SourceLocation Location) {
|
|
|
|
if (CGDebugInfo *DI = getDebugInfo())
|
|
|
|
return DI->SourceLocToDebugLoc(Location);
|
|
|
|
|
|
|
|
return llvm::DebugLoc();
|
|
|
|
}
|