2007-05-28 09:07:47 +08:00
|
|
|
//===--- CodeGenFunction.cpp - Emit LLVM Code from ASTs for a Function ----===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
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"
|
2011-10-07 02:51:56 +08:00
|
|
|
#include "CGCUDARuntime.h"
|
2010-08-31 15:33:07 +08:00
|
|
|
#include "CGCXXABI.h"
|
2019-12-10 08:11:56 +08:00
|
|
|
#include "CGCleanup.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"
|
2017-08-25 04:10:33 +08:00
|
|
|
#include "clang/AST/ASTLambda.h"
|
2019-12-10 08:11:56 +08:00
|
|
|
#include "clang/AST/Attr.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"
|
2018-12-11 11:18:39 +08:00
|
|
|
#include "clang/Basic/CodeGenOptions.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"
|
2018-12-06 14:12:20 +08:00
|
|
|
#include "clang/Frontend/FrontendDiagnostic.h"
|
2020-09-19 02:45:51 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2020-02-13 10:52:23 +08:00
|
|
|
#include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2017-11-12 01:00:43 +08:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2019-12-05 04:23:46 +08:00
|
|
|
#include "llvm/IR/FPEnv.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/MDBuilder.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
2020-09-19 02:45:51 +08:00
|
|
|
#include "llvm/Support/CRC.h"
|
2020-10-04 20:21:00 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LowerExpectIntrinsic.h"
|
2017-11-12 01:00:43 +08:00
|
|
|
#include "llvm/Transforms/Utils/PromoteMemToReg.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;
|
|
|
|
|
2019-08-27 06:15:50 +08:00
|
|
|
// Sanitizers may use markers.
|
|
|
|
if (CGOpts.SanitizeAddressUseAfterScope ||
|
2019-08-27 06:16:05 +08:00
|
|
|
LangOpts.Sanitize.has(SanitizerKind::HWAddress) ||
|
2019-08-27 06:15:50 +08:00
|
|
|
LangOpts.Sanitize.has(SanitizerKind::Memory))
|
2017-03-31 17:19:25 +08:00
|
|
|
return true;
|
|
|
|
|
2016-10-26 09:59:57 +08:00
|
|
|
// 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)),
|
2020-06-12 06:09:36 +08:00
|
|
|
SanOpts(CGM.getLangOpts().Sanitize), CurFPFeatures(CGM.getLangOpts()),
|
|
|
|
DebugInfo(CGM.getModuleDebugInfo()), PGO(cgm),
|
|
|
|
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
|
|
|
|
2020-06-12 06:09:36 +08:00
|
|
|
SetFastMathFlags(CurFPFeatures);
|
2019-12-05 04:23:46 +08:00
|
|
|
SetFPModel();
|
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");
|
|
|
|
|
2017-01-20 16:57:28 +08:00
|
|
|
if (getLangOpts().OpenMP && CurFn)
|
2015-02-25 16:32:46 +08:00
|
|
|
CGM.getOpenMPRuntime().functionFinished(*this);
|
2020-02-13 10:52:23 +08:00
|
|
|
|
|
|
|
// If we have an OpenMPIRBuilder we want to finalize functions (incl.
|
|
|
|
// outlining etc) at some point. Doing it once the function codegen is done
|
|
|
|
// seems to be a reasonable spot. We do it here, as opposed to the deletion
|
|
|
|
// time of the CodeGenModule, because we have to ensure the IR has not yet
|
|
|
|
// been "emitted" to the outside, thus, modifications are still sensible.
|
2020-07-05 21:24:36 +08:00
|
|
|
if (CGM.getLangOpts().OpenMPIRBuilder)
|
|
|
|
CGM.getOpenMPRuntime().getOMPBuilder().finalize();
|
2011-11-10 16:15:53 +08:00
|
|
|
}
|
|
|
|
|
2019-12-05 04:23:46 +08:00
|
|
|
// Map the LangOption for exception behavior into
|
|
|
|
// the corresponding enum in the IR.
|
2020-05-02 01:32:06 +08:00
|
|
|
llvm::fp::ExceptionBehavior
|
|
|
|
clang::ToConstrainedExceptMD(LangOptions::FPExceptionModeKind Kind) {
|
2019-12-05 04:23:46 +08:00
|
|
|
|
|
|
|
switch (Kind) {
|
|
|
|
case LangOptions::FPE_Ignore: return llvm::fp::ebIgnore;
|
|
|
|
case LangOptions::FPE_MayTrap: return llvm::fp::ebMayTrap;
|
|
|
|
case LangOptions::FPE_Strict: return llvm::fp::ebStrict;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unsupported FP Exception Behavior");
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGenFunction::SetFPModel() {
|
2020-03-26 15:51:09 +08:00
|
|
|
llvm::RoundingMode RM = getLangOpts().getFPRoundingMode();
|
2019-12-05 04:23:46 +08:00
|
|
|
auto fpExceptionBehavior = ToConstrainedExceptMD(
|
|
|
|
getLangOpts().getFPExceptionMode());
|
|
|
|
|
2020-05-02 01:32:06 +08:00
|
|
|
Builder.setDefaultConstrainedRounding(RM);
|
|
|
|
Builder.setDefaultConstrainedExcept(fpExceptionBehavior);
|
|
|
|
Builder.setIsFPConstrained(fpExceptionBehavior != llvm::fp::ebIgnore ||
|
|
|
|
RM != llvm::RoundingMode::NearestTiesToEven);
|
2019-12-05 04:23:46 +08:00
|
|
|
}
|
|
|
|
|
2020-06-02 09:02:02 +08:00
|
|
|
void CodeGenFunction::SetFastMathFlags(FPOptions FPFeatures) {
|
|
|
|
llvm::FastMathFlags FMF;
|
2020-06-27 00:23:45 +08:00
|
|
|
FMF.setAllowReassoc(FPFeatures.getAllowFPReassociate());
|
|
|
|
FMF.setNoNaNs(FPFeatures.getNoHonorNaNs());
|
|
|
|
FMF.setNoInfs(FPFeatures.getNoHonorInfs());
|
|
|
|
FMF.setNoSignedZeros(FPFeatures.getNoSignedZero());
|
|
|
|
FMF.setAllowReciprocal(FPFeatures.getAllowReciprocal());
|
|
|
|
FMF.setApproxFunc(FPFeatures.getAllowApproxFunc());
|
2020-06-02 09:02:02 +08:00
|
|
|
FMF.setAllowContract(FPFeatures.allowFPContractAcrossStatement());
|
|
|
|
Builder.setFastMathFlags(FMF);
|
|
|
|
}
|
|
|
|
|
2020-06-12 06:09:36 +08:00
|
|
|
CodeGenFunction::CGFPOptionsRAII::CGFPOptionsRAII(CodeGenFunction &CGF,
|
|
|
|
FPOptions FPFeatures)
|
|
|
|
: CGF(CGF), OldFPFeatures(CGF.CurFPFeatures) {
|
|
|
|
CGF.CurFPFeatures = FPFeatures;
|
|
|
|
|
|
|
|
if (OldFPFeatures == FPFeatures)
|
|
|
|
return;
|
|
|
|
|
|
|
|
FMFGuard.emplace(CGF.Builder);
|
|
|
|
|
2020-06-27 00:23:45 +08:00
|
|
|
llvm::RoundingMode NewRoundingBehavior =
|
|
|
|
static_cast<llvm::RoundingMode>(FPFeatures.getRoundingMode());
|
2020-06-12 06:09:36 +08:00
|
|
|
CGF.Builder.setDefaultConstrainedRounding(NewRoundingBehavior);
|
|
|
|
auto NewExceptionBehavior =
|
2020-06-27 00:23:45 +08:00
|
|
|
ToConstrainedExceptMD(static_cast<LangOptions::FPExceptionModeKind>(
|
|
|
|
FPFeatures.getFPExceptionMode()));
|
2020-06-12 06:09:36 +08:00
|
|
|
CGF.Builder.setDefaultConstrainedExcept(NewExceptionBehavior);
|
|
|
|
|
|
|
|
CGF.SetFastMathFlags(FPFeatures);
|
|
|
|
|
|
|
|
assert((CGF.CurFuncDecl == nullptr || CGF.Builder.getIsFPConstrained() ||
|
|
|
|
isa<CXXConstructorDecl>(CGF.CurFuncDecl) ||
|
|
|
|
isa<CXXDestructorDecl>(CGF.CurFuncDecl) ||
|
|
|
|
(NewExceptionBehavior == llvm::fp::ebIgnore &&
|
|
|
|
NewRoundingBehavior == llvm::RoundingMode::NearestTiesToEven)) &&
|
|
|
|
"FPConstrained should be enabled on entire function");
|
|
|
|
|
|
|
|
auto mergeFnAttrValue = [&](StringRef Name, bool Value) {
|
|
|
|
auto OldValue =
|
|
|
|
CGF.CurFn->getFnAttribute(Name).getValueAsString() == "true";
|
|
|
|
auto NewValue = OldValue & Value;
|
|
|
|
if (OldValue != NewValue)
|
|
|
|
CGF.CurFn->addFnAttr(Name, llvm::toStringRef(NewValue));
|
|
|
|
};
|
2020-06-27 00:23:45 +08:00
|
|
|
mergeFnAttrValue("no-infs-fp-math", FPFeatures.getNoHonorInfs());
|
|
|
|
mergeFnAttrValue("no-nans-fp-math", FPFeatures.getNoHonorNaNs());
|
|
|
|
mergeFnAttrValue("no-signed-zeros-fp-math", FPFeatures.getNoSignedZero());
|
|
|
|
mergeFnAttrValue("unsafe-fp-math", FPFeatures.getAllowFPReassociate() &&
|
|
|
|
FPFeatures.getAllowReciprocal() &&
|
|
|
|
FPFeatures.getAllowApproxFunc() &&
|
|
|
|
FPFeatures.getNoSignedZero());
|
2020-06-12 06:09:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CodeGenFunction::CGFPOptionsRAII::~CGFPOptionsRAII() {
|
|
|
|
CGF.CurFPFeatures = OldFPFeatures;
|
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
LValue CodeGenFunction::MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T) {
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo;
|
2017-10-14 00:58:30 +08:00
|
|
|
TBAAAccessInfo TBAAInfo;
|
2020-05-19 02:29:11 +08:00
|
|
|
CharUnits Alignment = CGM.getNaturalTypeAlignment(T, &BaseInfo, &TBAAInfo);
|
2017-05-19 01:07:11 +08:00
|
|
|
return LValue::MakeAddr(Address(V, Alignment), T, getContext(), BaseInfo,
|
2017-10-14 00:58:30 +08:00
|
|
|
TBAAInfo);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// 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) {
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo;
|
2017-10-14 00:58:30 +08:00
|
|
|
TBAAAccessInfo TBAAInfo;
|
2020-05-19 02:29:11 +08:00
|
|
|
CharUnits Align = CGM.getNaturalTypeAlignment(T, &BaseInfo, &TBAAInfo,
|
|
|
|
/* forPointeeType= */ true);
|
2017-10-14 00:58:30 +08:00
|
|
|
return MakeAddrLValue(Address(V, Align), T, BaseInfo, TBAAInfo);
|
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:
|
2019-10-02 14:35:23 +08:00
|
|
|
#include "clang/AST/TypeNodes.inc"
|
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:
|
2020-05-12 00:45:51 +08:00
|
|
|
case Type::ConstantMatrix:
|
2013-03-08 05:37:08 +08:00
|
|
|
case Type::FunctionProto:
|
|
|
|
case Type::FunctionNoProto:
|
|
|
|
case Type::Enum:
|
|
|
|
case Type::ObjCObjectPointer:
|
2016-01-09 20:53:17 +08:00
|
|
|
case Type::Pipe:
|
2020-04-18 01:44:19 +08:00
|
|
|
case Type::ExtInt:
|
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();
|
2019-04-11 01:03:09 +08:00
|
|
|
ReturnBlock = JumpDest();
|
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();
|
2019-04-11 01:03:09 +08:00
|
|
|
ReturnBlock = JumpDest();
|
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
|
2018-09-25 02:24:18 +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.
|
2019-12-06 05:19:37 +08:00
|
|
|
Optional<ApplyDebugLocation> AL;
|
2019-12-06 04:26:16 +08:00
|
|
|
if (CGDebugInfo *DI = getDebugInfo()) {
|
2013-05-04 04:11:48 +08:00
|
|
|
if (OnlySimpleReturnStmts)
|
2018-09-25 02:24:18 +08:00
|
|
|
DI->EmitLocation(Builder, EndLoc);
|
2019-12-06 04:26:16 +08:00
|
|
|
else
|
2019-12-06 05:19:37 +08:00
|
|
|
// We may not have a valid end location. Try to apply it anyway, and
|
|
|
|
// fall back to an artificial location if needed.
|
|
|
|
AL = ApplyDebugLocation::CreateDefaultArtificial(*this, EndLoc);
|
2019-12-06 04:26:16 +08:00
|
|
|
}
|
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
|
|
|
|
2017-11-15 05:13:27 +08:00
|
|
|
if (ShouldInstrumentFunction()) {
|
2017-11-22 01:30:34 +08:00
|
|
|
if (CGM.getCodeGenOpts().InstrumentFunctions)
|
|
|
|
CurFn->addFnAttr("instrument-function-exit", "__cyg_profile_func_exit");
|
|
|
|
if (CGM.getCodeGenOpts().InstrumentFunctionsAfterInlining)
|
|
|
|
CurFn->addFnAttr("instrument-function-exit-inlined",
|
|
|
|
"__cyg_profile_func_exit");
|
2017-11-15 05:13:27 +08:00
|
|
|
}
|
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())
|
2017-06-02 05:14:03 +08:00
|
|
|
DI->EmitFunctionEnd(Builder, CurFn);
|
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
|
|
|
|
2018-01-03 05:34:16 +08:00
|
|
|
for (const auto &FuncletAndParent : TerminateFunclets)
|
|
|
|
EmitIfUsed(*this, FuncletAndParent.second);
|
|
|
|
|
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();
|
|
|
|
}
|
2017-11-12 01:00:43 +08:00
|
|
|
|
|
|
|
// Eliminate CleanupDestSlot alloca by replacing it with SSA values and
|
|
|
|
// PHIs if the current function is a coroutine. We don't do it for all
|
|
|
|
// functions as it may result in slight increase in numbers of instructions
|
|
|
|
// if compiled with no optimizations. We do it for coroutine as the lifetime
|
|
|
|
// of CleanupDestSlot alloca make correct coroutine frame building very
|
|
|
|
// difficult.
|
2018-01-13 06:07:01 +08:00
|
|
|
if (NormalCleanupDest.isValid() && isCoroutine()) {
|
2017-11-12 01:00:43 +08:00
|
|
|
llvm::DominatorTree DT(*CurFn);
|
2018-01-13 06:07:01 +08:00
|
|
|
llvm::PromoteMemToReg(
|
|
|
|
cast<llvm::AllocaInst>(NormalCleanupDest.getPointer()), DT);
|
|
|
|
NormalCleanupDest = Address::invalid();
|
2017-11-12 01:00:43 +08:00
|
|
|
}
|
2018-07-10 03:00:16 +08:00
|
|
|
|
2018-10-25 01:42:17 +08:00
|
|
|
// Scan function arguments for vector width.
|
|
|
|
for (llvm::Argument &A : CurFn->args())
|
|
|
|
if (auto *VT = dyn_cast<llvm::VectorType>(A.getType()))
|
2020-03-15 22:29:45 +08:00
|
|
|
LargestVectorWidth =
|
|
|
|
std::max((uint64_t)LargestVectorWidth,
|
|
|
|
VT->getPrimitiveSizeInBits().getKnownMinSize());
|
2018-10-25 01:42:17 +08:00
|
|
|
|
|
|
|
// Update vector width based on return type.
|
|
|
|
if (auto *VT = dyn_cast<llvm::VectorType>(CurFn->getReturnType()))
|
2020-03-15 22:29:45 +08:00
|
|
|
LargestVectorWidth =
|
|
|
|
std::max((uint64_t)LargestVectorWidth,
|
|
|
|
VT->getPrimitiveSizeInBits().getKnownMinSize());
|
2018-10-25 01:42:17 +08:00
|
|
|
|
|
|
|
// Add the required-vector-width attribute. This contains the max width from:
|
|
|
|
// 1. min-vector-width attribute used in the source program.
|
|
|
|
// 2. Any builtins used that have a vector width specified.
|
|
|
|
// 3. Values passed in and out of inline assembly.
|
|
|
|
// 4. Width of vector arguments and return types for this function.
|
|
|
|
// 5. Width of vector aguments and return types for functions called by this
|
|
|
|
// function.
|
2018-10-25 13:04:35 +08:00
|
|
|
CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
|
2019-04-11 01:03:09 +08:00
|
|
|
|
|
|
|
// If we generated an unreachable return block, delete it now.
|
|
|
|
if (ReturnBlock.isValid() && ReturnBlock.getBlock()->use_empty()) {
|
|
|
|
Builder.ClearInsertionPoint();
|
|
|
|
ReturnBlock.getBlock()->eraseFromParent();
|
|
|
|
}
|
|
|
|
if (ReturnValue.isValid()) {
|
|
|
|
auto *RetAlloca = dyn_cast<llvm::AllocaInst>(ReturnValue.getPointer());
|
|
|
|
if (RetAlloca && RetAlloca->use_empty()) {
|
|
|
|
RetAlloca->eraseFromParent();
|
|
|
|
ReturnValue = Address::invalid();
|
|
|
|
}
|
|
|
|
}
|
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() {
|
2017-11-15 05:13:27 +08:00
|
|
|
if (!CGM.getCodeGenOpts().InstrumentFunctions &&
|
2017-11-22 01:30:34 +08:00
|
|
|
!CGM.getCodeGenOpts().InstrumentFunctionsAfterInlining &&
|
|
|
|
!CGM.getCodeGenOpts().InstrumentFunctionEntryBare)
|
2010-06-22 08:03:40 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2017-11-30 08:04:54 +08:00
|
|
|
/// AlwaysEmitXRayCustomEvents - Return true if we should emit IR for calls to
|
2018-04-18 05:32:43 +08:00
|
|
|
/// the __xray_customevent(...) builtin calls, when doing XRay instrumentation.
|
2017-11-30 08:04:54 +08:00
|
|
|
bool CodeGenFunction::AlwaysEmitXRayCustomEvents() const {
|
2018-04-13 10:31:58 +08:00
|
|
|
return CGM.getCodeGenOpts().XRayInstrumentFunctions &&
|
|
|
|
(CGM.getCodeGenOpts().XRayAlwaysEmitCustomEvents ||
|
|
|
|
CGM.getCodeGenOpts().XRayInstrumentationBundle.Mask ==
|
|
|
|
XRayInstrKind::Custom);
|
2017-11-30 08:04:54 +08:00
|
|
|
}
|
|
|
|
|
2018-04-18 05:32:43 +08:00
|
|
|
bool CodeGenFunction::AlwaysEmitXRayTypedEvents() const {
|
|
|
|
return CGM.getCodeGenOpts().XRayInstrumentFunctions &&
|
|
|
|
(CGM.getCodeGenOpts().XRayAlwaysEmitTypedEvents ||
|
|
|
|
CGM.getCodeGenOpts().XRayInstrumentationBundle.Mask ==
|
|
|
|
XRayInstrKind::Typed);
|
|
|
|
}
|
|
|
|
|
2017-09-13 08:04:35 +08:00
|
|
|
llvm::Constant *
|
|
|
|
CodeGenFunction::EncodeAddrForUseInPrologue(llvm::Function *F,
|
|
|
|
llvm::Constant *Addr) {
|
|
|
|
// Addresses stored in prologue data can't require run-time fixups and must
|
|
|
|
// be PC-relative. Run-time fixups are undesirable because they necessitate
|
|
|
|
// writable text segments, which are unsafe. And absolute addresses are
|
|
|
|
// undesirable because they break PIE mode.
|
|
|
|
|
|
|
|
// Add a layer of indirection through a private global. Taking its address
|
|
|
|
// won't result in a run-time fixup, even if Addr has linkonce_odr linkage.
|
|
|
|
auto *GV = new llvm::GlobalVariable(CGM.getModule(), Addr->getType(),
|
|
|
|
/*isConstant=*/true,
|
|
|
|
llvm::GlobalValue::PrivateLinkage, Addr);
|
|
|
|
|
|
|
|
// Create a PC-relative address.
|
|
|
|
auto *GOTAsInt = llvm::ConstantExpr::getPtrToInt(GV, IntPtrTy);
|
|
|
|
auto *FuncAsInt = llvm::ConstantExpr::getPtrToInt(F, IntPtrTy);
|
|
|
|
auto *PCRelAsInt = llvm::ConstantExpr::getSub(GOTAsInt, FuncAsInt);
|
|
|
|
return (IntPtrTy == Int32Ty)
|
|
|
|
? PCRelAsInt
|
|
|
|
: llvm::ConstantExpr::getTrunc(PCRelAsInt, Int32Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *
|
|
|
|
CodeGenFunction::DecodeAddrUsedInPrologue(llvm::Value *F,
|
|
|
|
llvm::Value *EncodedAddr) {
|
|
|
|
// Reconstruct the address of the global.
|
|
|
|
auto *PCRelAsInt = Builder.CreateSExt(EncodedAddr, IntPtrTy);
|
|
|
|
auto *FuncAsInt = Builder.CreatePtrToInt(F, IntPtrTy, "func_addr.int");
|
|
|
|
auto *GOTAsInt = Builder.CreateAdd(PCRelAsInt, FuncAsInt, "global_addr.int");
|
|
|
|
auto *GOTAddr = Builder.CreateIntToPtr(GOTAsInt, Int8PtrPtrTy, "global_addr");
|
|
|
|
|
|
|
|
// Load the original pointer through the global.
|
|
|
|
return Builder.CreateLoad(Address(GOTAddr, getPointerAlign()),
|
|
|
|
"decoded_addr");
|
|
|
|
}
|
|
|
|
|
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();
|
|
|
|
|
2019-05-09 21:55:44 +08:00
|
|
|
CGM.GenOpenCLArgMetadata(Fn, FD, this);
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2013-12-19 11:09:10 +08:00
|
|
|
if (const VecTypeHintAttr *A = FD->getAttr<VecTypeHintAttr>()) {
|
2017-05-04 15:31:20 +08:00
|
|
|
QualType HintQTy = A->getTypeHint();
|
|
|
|
const ExtVectorType *HintEltQTy = HintQTy->getAs<ExtVectorType>();
|
|
|
|
bool IsSignedInteger =
|
|
|
|
HintQTy->isSignedIntegerType() ||
|
|
|
|
(HintEltQTy && HintEltQTy->getElementType()->isSignedIntegerType());
|
|
|
|
llvm::Metadata *AttrMDArgs[] = {
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::ConstantAsMetadata::get(llvm::UndefValue::get(
|
|
|
|
CGM.getTypes().ConvertType(A->getTypeHint()))),
|
|
|
|
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
|
|
|
|
llvm::IntegerType::get(Context, 32),
|
2017-05-04 15:31:20 +08:00
|
|
|
llvm::APInt(32, (uint64_t)(IsSignedInteger ? 1 : 0))))};
|
|
|
|
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>()) {
|
2017-05-04 15:31:20 +08:00
|
|
|
llvm::Metadata *AttrMDArgs[] = {
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getXDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getYDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getZDim()))};
|
2017-05-04 15:31:20 +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>()) {
|
2017-05-04 15:31:20 +08:00
|
|
|
llvm::Metadata *AttrMDArgs[] = {
|
2014-12-10 02:39:32 +08:00
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getXDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getYDim())),
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getZDim()))};
|
2017-05-04 15:31:20 +08:00
|
|
|
Fn->setMetadata("reqd_work_group_size", llvm::MDNode::get(Context, AttrMDArgs));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const OpenCLIntelReqdSubGroupSizeAttr *A =
|
|
|
|
FD->getAttr<OpenCLIntelReqdSubGroupSizeAttr>()) {
|
|
|
|
llvm::Metadata *AttrMDArgs[] = {
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(A->getSubGroupSize()))};
|
|
|
|
Fn->setMetadata("intel_reqd_sub_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;
|
|
|
|
}
|
|
|
|
|
2018-08-10 23:09:24 +08:00
|
|
|
void CodeGenFunction::markAsIgnoreThreadCheckingAtRuntime(llvm::Function *Fn) {
|
|
|
|
if (SanOpts.has(SanitizerKind::Thread)) {
|
|
|
|
Fn->addFnAttr("sanitize_thread_no_checking_at_run_time");
|
|
|
|
Fn->removeFnAttr(llvm::Attribute::SanitizeThread);
|
|
|
|
}
|
2017-01-13 08:50:50 +08:00
|
|
|
}
|
|
|
|
|
2019-12-10 08:11:56 +08:00
|
|
|
/// Check if the return value of this function requires sanitization.
|
|
|
|
bool CodeGenFunction::requiresReturnValueCheck() const {
|
|
|
|
return requiresReturnValueNullabilityCheck() ||
|
|
|
|
(SanOpts.has(SanitizerKind::ReturnsNonnullAttribute) && CurCodeDecl &&
|
|
|
|
CurCodeDecl->getAttr<ReturnsNonNullAttr>());
|
|
|
|
}
|
|
|
|
|
2017-08-05 05:21:00 +08:00
|
|
|
static bool matchesStlAllocatorFn(const Decl *D, const ASTContext &Ctx) {
|
|
|
|
auto *MD = dyn_cast_or_null<CXXMethodDecl>(D);
|
|
|
|
if (!MD || !MD->getDeclName().getAsIdentifierInfo() ||
|
|
|
|
!MD->getDeclName().getAsIdentifierInfo()->isStr("allocate") ||
|
|
|
|
(MD->getNumParams() != 1 && MD->getNumParams() != 2))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (MD->parameters()[0]->getType().getCanonicalType() != Ctx.getSizeType())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (MD->getNumParams() == 2) {
|
|
|
|
auto *PT = MD->parameters()[1]->getType()->getAs<PointerType>();
|
|
|
|
if (!PT || !PT->isVoidPointerType() ||
|
|
|
|
!PT->getPointeeType().isConstQualified())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-10-14 09:23:30 +08:00
|
|
|
/// Return the UBSan prologue signature for \p FD if one is available.
|
|
|
|
static llvm::Constant *getPrologueSignature(CodeGenModule &CGM,
|
|
|
|
const FunctionDecl *FD) {
|
|
|
|
if (const auto *MD = dyn_cast<CXXMethodDecl>(FD))
|
|
|
|
if (!MD->isStatic())
|
|
|
|
return nullptr;
|
|
|
|
return CGM.getTargetCodeGenInfo().getUBSanFunctionSignature(CGM);
|
|
|
|
}
|
|
|
|
|
2019-11-05 06:28:14 +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
|
|
|
|
2017-09-26 06:11:12 +08:00
|
|
|
// If this function has been blacklisted for any of the enabled sanitizers,
|
|
|
|
// disable the sanitizer for the function.
|
|
|
|
do {
|
|
|
|
#define SANITIZER(NAME, ID) \
|
|
|
|
if (SanOpts.empty()) \
|
|
|
|
break; \
|
|
|
|
if (SanOpts.has(SanitizerKind::ID)) \
|
|
|
|
if (CGM.isInSanitizerBlacklist(SanitizerKind::ID, Fn, Loc)) \
|
|
|
|
SanOpts.set(SanitizerKind::ID, false);
|
|
|
|
|
|
|
|
#include "clang/Basic/Sanitizers.def"
|
|
|
|
#undef SANITIZER
|
|
|
|
} while (0);
|
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.
|
2018-04-10 04:10:29 +08:00
|
|
|
for (auto Attr : D->specific_attrs<NoSanitizeAttr>()) {
|
|
|
|
SanitizerMask mask = Attr->getMask();
|
|
|
|
SanOpts.Mask &= ~mask;
|
|
|
|
if (mask & SanitizerKind::Address)
|
|
|
|
SanOpts.set(SanitizerKind::KernelAddress, false);
|
|
|
|
if (mask & SanitizerKind::KernelAddress)
|
|
|
|
SanOpts.set(SanitizerKind::Address, false);
|
2018-04-14 02:05:21 +08:00
|
|
|
if (mask & SanitizerKind::HWAddress)
|
|
|
|
SanOpts.set(SanitizerKind::KernelHWAddress, false);
|
|
|
|
if (mask & SanitizerKind::KernelHWAddress)
|
|
|
|
SanOpts.set(SanitizerKind::HWAddress, false);
|
2018-04-10 04:10:29 +08:00
|
|
|
}
|
2015-05-16 02:33:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// 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);
|
2018-04-14 02:05:21 +08:00
|
|
|
if (SanOpts.hasOneOf(SanitizerKind::HWAddress | SanitizerKind::KernelHWAddress))
|
2017-12-09 09:32:07 +08:00
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeHWAddress);
|
ARM MTE stack sanitizer.
Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.
It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.
The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.
Reviewers: pcc, hctim, vitalybuka, ostannard
Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64169
llvm-svn: 366123
2019-07-16 04:02:23 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::MemTag))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeMemTag);
|
2015-05-16 02:33:32 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::Thread))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeThread);
|
2018-09-07 17:21:09 +08:00
|
|
|
if (SanOpts.hasOneOf(SanitizerKind::Memory | SanitizerKind::KernelMemory))
|
2015-05-16 02:33:32 +08:00
|
|
|
Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
|
2015-06-16 05:08:13 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::SafeStack))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::SafeStack);
|
2018-04-04 06:33:53 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::ShadowCallStack))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::ShadowCallStack);
|
2015-05-16 02:33:32 +08:00
|
|
|
|
2018-03-24 07:35:28 +08:00
|
|
|
// Apply fuzzing attribute to the function.
|
|
|
|
if (SanOpts.hasOneOf(SanitizerKind::Fuzzer | SanitizerKind::FuzzerNoLink))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::OptForFuzzing);
|
|
|
|
|
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-08-05 05:21:00 +08:00
|
|
|
// Ignore unrelated casts in STL allocate() since the allocator must cast
|
|
|
|
// from void* to T* before object initialization completes. Don't match on the
|
|
|
|
// namespace because not all allocators are in std::
|
|
|
|
if (D && SanOpts.has(SanitizerKind::CFIUnrelatedCast)) {
|
|
|
|
if (matchesStlAllocatorFn(D, getContext()))
|
|
|
|
SanOpts.Mask &= ~SanitizerKind::CFIUnrelatedCast;
|
|
|
|
}
|
|
|
|
|
2019-08-13 20:02:25 +08:00
|
|
|
// Ignore null checks in coroutine functions since the coroutines passes
|
|
|
|
// are not aware of how to move the extra UBSan instructions across the split
|
|
|
|
// coroutine boundaries.
|
|
|
|
if (D && SanOpts.has(SanitizerKind::Null))
|
|
|
|
if (const auto *FD = dyn_cast<FunctionDecl>(D))
|
|
|
|
if (FD->getBody() &&
|
|
|
|
FD->getBody()->getStmtClass() == Stmt::CoroutineBodyStmtClass)
|
|
|
|
SanOpts.Mask &= ~SanitizerKind::Null;
|
|
|
|
|
2020-04-01 10:07:27 +08:00
|
|
|
// Apply xray attributes to the function (as a string, for now)
|
2020-09-19 02:45:51 +08:00
|
|
|
bool AlwaysXRayAttr = false;
|
2020-04-01 10:07:27 +08:00
|
|
|
if (const auto *XRayAttr = D ? D->getAttr<XRayInstrumentAttr>() : nullptr) {
|
|
|
|
if (CGM.getCodeGenOpts().XRayInstrumentationBundle.has(
|
|
|
|
XRayInstrKind::FunctionEntry) ||
|
|
|
|
CGM.getCodeGenOpts().XRayInstrumentationBundle.has(
|
|
|
|
XRayInstrKind::FunctionExit)) {
|
2020-09-19 02:45:51 +08:00
|
|
|
if (XRayAttr->alwaysXRayInstrument() && ShouldXRayInstrumentFunction()) {
|
2020-04-01 10:07:27 +08:00
|
|
|
Fn->addFnAttr("function-instrument", "xray-always");
|
2020-09-19 02:45:51 +08:00
|
|
|
AlwaysXRayAttr = true;
|
|
|
|
}
|
2020-04-01 10:07:27 +08:00
|
|
|
if (XRayAttr->neverXRayInstrument())
|
|
|
|
Fn->addFnAttr("function-instrument", "xray-never");
|
|
|
|
if (const auto *LogArgs = D->getAttr<XRayLogArgsAttr>())
|
|
|
|
if (ShouldXRayInstrumentFunction())
|
|
|
|
Fn->addFnAttr("xray-log-args",
|
|
|
|
llvm::utostr(LogArgs->getArgumentCount()));
|
2020-02-12 05:52:45 +08:00
|
|
|
}
|
2020-04-01 10:07:27 +08:00
|
|
|
} else {
|
|
|
|
if (ShouldXRayInstrumentFunction() && !CGM.imbueXRayAttrs(Fn, Loc))
|
|
|
|
Fn->addFnAttr(
|
|
|
|
"xray-instruction-threshold",
|
|
|
|
llvm::itostr(CGM.getCodeGenOpts().XRayInstructionThreshold));
|
|
|
|
}
|
2020-02-12 05:52:45 +08:00
|
|
|
|
2020-04-01 10:07:27 +08:00
|
|
|
if (ShouldXRayInstrumentFunction()) {
|
|
|
|
if (CGM.getCodeGenOpts().XRayIgnoreLoops)
|
|
|
|
Fn->addFnAttr("xray-ignore-loops");
|
2020-02-12 05:52:45 +08:00
|
|
|
|
2020-04-01 10:07:27 +08:00
|
|
|
if (!CGM.getCodeGenOpts().XRayInstrumentationBundle.has(
|
|
|
|
XRayInstrKind::FunctionExit))
|
|
|
|
Fn->addFnAttr("xray-skip-exit");
|
2020-02-12 05:52:45 +08:00
|
|
|
|
2020-04-01 10:07:27 +08:00
|
|
|
if (!CGM.getCodeGenOpts().XRayInstrumentationBundle.has(
|
|
|
|
XRayInstrKind::FunctionEntry))
|
|
|
|
Fn->addFnAttr("xray-skip-entry");
|
2020-09-19 02:45:51 +08:00
|
|
|
|
|
|
|
auto FuncGroups = CGM.getCodeGenOpts().XRayTotalFunctionGroups;
|
|
|
|
if (FuncGroups > 1) {
|
|
|
|
auto FuncName = llvm::makeArrayRef<uint8_t>(
|
|
|
|
CurFn->getName().bytes_begin(), CurFn->getName().bytes_end());
|
|
|
|
auto Group = crc32(FuncName) % FuncGroups;
|
|
|
|
if (Group != CGM.getCodeGenOpts().XRaySelectedFunctionGroup &&
|
|
|
|
!AlwaysXRayAttr)
|
|
|
|
Fn->addFnAttr("function-instrument", "xray-never");
|
|
|
|
}
|
2020-04-01 10:07:27 +08:00
|
|
|
}
|
2020-01-05 07:39:19 +08:00
|
|
|
|
2020-04-01 10:07:27 +08:00
|
|
|
unsigned Count, Offset;
|
|
|
|
if (const auto *Attr =
|
|
|
|
D ? D->getAttr<PatchableFunctionEntryAttr>() : nullptr) {
|
|
|
|
Count = Attr->getCount();
|
|
|
|
Offset = Attr->getOffset();
|
|
|
|
} else {
|
|
|
|
Count = CGM.getCodeGenOpts().PatchableFunctionEntryCount;
|
|
|
|
Offset = CGM.getCodeGenOpts().PatchableFunctionEntryOffset;
|
|
|
|
}
|
|
|
|
if (Count && Offset <= Count) {
|
|
|
|
Fn->addFnAttr("patchable-function-entry", std::to_string(Count - Offset));
|
|
|
|
if (Offset)
|
|
|
|
Fn->addFnAttr("patchable-function-prefix", std::to_string(Offset));
|
2016-07-14 06:32:15 +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));
|
|
|
|
|
2019-11-01 00:15:53 +08:00
|
|
|
// Add no-inline-line-tables value.
|
|
|
|
if (CGM.getCodeGenOpts().NoInlineLineTables)
|
|
|
|
Fn->addFnAttr("no-inline-line-tables");
|
|
|
|
|
2017-08-25 05:37:33 +08:00
|
|
|
// Add profile-sample-accurate value.
|
|
|
|
if (CGM.getCodeGenOpts().ProfileSampleAccurate)
|
|
|
|
Fn->addFnAttr("profile-sample-accurate");
|
|
|
|
|
2020-05-15 03:05:49 +08:00
|
|
|
if (!CGM.getCodeGenOpts().SampleProfileFile.empty())
|
|
|
|
Fn->addFnAttr("use-sample-profile");
|
|
|
|
|
cfi-icall: Allow the jump table to be optionally made non-canonical.
The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:
- There is a performance and code size overhead associated with each
exported function, because each such function must have an associated
jump table entry, which must be emitted even in the common case where the
function is never address-taken anywhere in the program, and must be used
even for direct calls between DSOs, in addition to the PLT overhead.
- There is no good way to take a CFI-valid address of a function written in
assembly or a language not supported by Clang. The reason is that the code
generator would need to insert a jump table in order to form a CFI-valid
address for assembly functions, but there is no way in general for the
code generator to determine the language of the function. This may be
possible with LTO in the intra-DSO case, but in the cross-DSO case the only
information available is the function declaration. One possible solution
is to add a C wrapper for each assembly function, but these wrappers can
present a significant maintenance burden for heavy users of assembly in
addition to adding runtime overhead.
For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.
This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.
Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.
Fixes PR41972.
Differential Revision: https://reviews.llvm.org/D65629
llvm-svn: 368495
2019-08-10 06:31:59 +08:00
|
|
|
if (D && D->hasAttr<CFICanonicalJumpTableAttr>())
|
|
|
|
Fn->addFnAttr("cfi-canonical-jump-table");
|
|
|
|
|
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)) {
|
2017-10-14 09:23:30 +08:00
|
|
|
if (llvm::Constant *PrologueSig = getPrologueSignature(CGM, FD)) {
|
2018-01-05 15:57:12 +08:00
|
|
|
// Remove any (C++17) exception specifications, to allow calling e.g. a
|
|
|
|
// noexcept function through a non-noexcept pointer.
|
|
|
|
auto ProtoTy =
|
|
|
|
getContext().getFunctionTypeWithExceptionSpec(FD->getType(),
|
|
|
|
EST_None);
|
2013-10-21 05:29:19 +08:00
|
|
|
llvm::Constant *FTRTTIConst =
|
2018-01-05 15:57:12 +08:00
|
|
|
CGM.GetAddrOfRTTIDescriptor(ProtoTy, /*ForEH=*/true);
|
2017-09-13 08:04:35 +08:00
|
|
|
llvm::Constant *FTRTTIConstEncoded =
|
|
|
|
EncodeAddrForUseInPrologue(Fn, FTRTTIConst);
|
|
|
|
llvm::Constant *PrologueStructElems[] = {PrologueSig,
|
|
|
|
FTRTTIConstEncoded};
|
2014-12-03 10:08:51 +08:00
|
|
|
llvm::Constant *PrologueStructConst =
|
|
|
|
llvm::ConstantStruct::getAnon(PrologueStructElems, /*Packed=*/true);
|
|
|
|
Fn->setPrologueData(PrologueStructConst);
|
2013-10-21 05:29:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-14 09:56:34 +08:00
|
|
|
// If we're checking nullability, we need to know whether we can check the
|
|
|
|
// return value. Initialize the flag to 'true' and refine it in EmitParmDecl.
|
|
|
|
if (SanOpts.has(SanitizerKind::NullabilityReturn)) {
|
|
|
|
auto Nullability = FnRetTy->getNullability(getContext());
|
|
|
|
if (Nullability && *Nullability == NullabilityKind::NonNull) {
|
|
|
|
if (!(SanOpts.has(SanitizerKind::ReturnsNonnullAttribute) &&
|
|
|
|
CurCodeDecl && CurCodeDecl->getAttr<ReturnsNonNullAttr>()))
|
|
|
|
RetValNullabilityPrecondition =
|
|
|
|
llvm::ConstantInt::getTrue(getLLVMContext());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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").
|
2020-01-30 03:11:37 +08:00
|
|
|
//
|
|
|
|
// OpenCL C 2.0 v2.2-11 s6.9.i:
|
|
|
|
// Recursion is not supported.
|
|
|
|
//
|
|
|
|
// SYCL v1.2.1 s3.10:
|
|
|
|
// kernels cannot include RTTI information, exception classes,
|
|
|
|
// recursive code, virtual functions or make use of C++ libraries that
|
|
|
|
// are not compiled for the device.
|
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) {
|
|
|
|
if ((getLangOpts().CPlusPlus && FD->isMain()) || getLangOpts().OpenCL ||
|
|
|
|
getLangOpts().SYCLIsDevice ||
|
|
|
|
(getLangOpts().CUDA && FD->hasAttr<CUDAGlobalAttr>()))
|
|
|
|
Fn->addFnAttr(llvm::Attribute::NoRecurse);
|
|
|
|
}
|
2016-09-01 14:14:45 +08:00
|
|
|
|
2020-05-02 01:32:06 +08:00
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) {
|
|
|
|
Builder.setIsFPConstrained(FD->usesFPIntrin());
|
2019-12-05 04:23:46 +08:00
|
|
|
if (FD->usesFPIntrin())
|
|
|
|
Fn->addFnAttr(llvm::Attribute::StrictFP);
|
2020-05-02 01:32:06 +08:00
|
|
|
}
|
2019-12-05 04:23:46 +08:00
|
|
|
|
2018-08-22 04:41:17 +08:00
|
|
|
// If a custom alignment is used, force realigning to this alignment on
|
|
|
|
// any main function which certainly will need it.
|
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if ((FD->isMain() || FD->isMSVCRTEntryPoint()) &&
|
|
|
|
CGM.getCodeGenOpts().StackAlignment)
|
|
|
|
Fn->addFnAttr("stackrealign");
|
|
|
|
|
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
|
|
|
|
2017-06-24 05:32:38 +08:00
|
|
|
// If we're checking the return value, allocate space for a pointer to a
|
|
|
|
// precise source location of the checked return statement.
|
|
|
|
if (requiresReturnValueCheck()) {
|
|
|
|
ReturnLocation = CreateDefaultAlignTempAlloca(Int8PtrTy, "return.sloc.ptr");
|
|
|
|
InitTempAlloca(ReturnLocation, llvm::ConstantPointerNull::get(Int8PtrTy));
|
|
|
|
}
|
|
|
|
|
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));
|
2018-04-17 00:53:57 +08:00
|
|
|
DI->EmitFunctionStart(GD, Loc, StartLoc, FnType, CurFn, CurFuncIsThunk,
|
|
|
|
Builder);
|
2008-07-04 19:04:26 +08:00
|
|
|
}
|
|
|
|
|
2017-11-15 05:13:27 +08:00
|
|
|
if (ShouldInstrumentFunction()) {
|
2017-11-22 01:30:34 +08:00
|
|
|
if (CGM.getCodeGenOpts().InstrumentFunctions)
|
|
|
|
CurFn->addFnAttr("instrument-function-entry", "__cyg_profile_func_enter");
|
|
|
|
if (CGM.getCodeGenOpts().InstrumentFunctionsAfterInlining)
|
|
|
|
CurFn->addFnAttr("instrument-function-entry-inlined",
|
|
|
|
"__cyg_profile_func_enter");
|
|
|
|
if (CGM.getCodeGenOpts().InstrumentFunctionEntryBare)
|
|
|
|
CurFn->addFnAttr("instrument-function-entry-inlined",
|
|
|
|
"__cyg_profile_func_enter_bare");
|
2017-11-15 05:13:27 +08:00
|
|
|
}
|
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) {
|
2018-03-03 07:52:44 +08:00
|
|
|
// Calls to fentry/mcount should not be generated if function has
|
|
|
|
// the no_instrument_function attribute.
|
|
|
|
if (!CurFuncDecl || !CurFuncDecl->hasAttr<NoInstrumentFunctionAttr>()) {
|
|
|
|
if (CGM.getCodeGenOpts().CallFEntry)
|
|
|
|
Fn->addFnAttr("fentry-call", "true");
|
|
|
|
else {
|
2017-11-15 05:13:27 +08:00
|
|
|
Fn->addFnAttr("instrument-function-entry-inlined",
|
|
|
|
getTarget().getMCountName());
|
|
|
|
}
|
2019-11-05 18:44:04 +08:00
|
|
|
if (CGM.getCodeGenOpts().MNopMCount) {
|
|
|
|
if (!CGM.getCodeGenOpts().CallFEntry)
|
|
|
|
CGM.getDiags().Report(diag::err_opt_not_valid_without_opt)
|
|
|
|
<< "-mnop-mcount" << "-mfentry";
|
2019-12-19 02:12:41 +08:00
|
|
|
Fn->addFnAttr("mnop-mcount");
|
2019-11-05 18:44:04 +08:00
|
|
|
}
|
2019-12-18 04:00:43 +08:00
|
|
|
|
|
|
|
if (CGM.getCodeGenOpts().RecordMCount) {
|
|
|
|
if (!CGM.getCodeGenOpts().CallFEntry)
|
|
|
|
CGM.getDiags().Report(diag::err_opt_not_valid_without_opt)
|
|
|
|
<< "-mrecord-mcount" << "-mfentry";
|
|
|
|
Fn->addFnAttr("mrecord-mcount");
|
|
|
|
}
|
2017-06-20 02:45:03 +08:00
|
|
|
}
|
2017-02-01 01:00:35 +08:00
|
|
|
}
|
2011-02-11 00:52:03 +08:00
|
|
|
|
2019-12-13 04:40:26 +08:00
|
|
|
if (CGM.getCodeGenOpts().PackedStack) {
|
|
|
|
if (getContext().getTargetInfo().getTriple().getArch() !=
|
|
|
|
llvm::Triple::systemz)
|
|
|
|
CGM.getDiags().Report(diag::err_opt_not_valid_on_target)
|
|
|
|
<< "-mpacked-stack";
|
|
|
|
Fn->addFnAttr("packed-stack");
|
|
|
|
}
|
|
|
|
|
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;
|
2018-12-07 16:17:26 +08:00
|
|
|
} else if (CurFnInfo->getReturnInfo().getKind() == ABIArgInfo::Indirect) {
|
|
|
|
// Indirect 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());
|
2019-06-21 01:15:21 +08:00
|
|
|
if (!CurFnInfo->getReturnInfo().getIndirectByVal()) {
|
|
|
|
ReturnValuePointer =
|
|
|
|
CreateDefaultAlignTempAlloca(Int8PtrTy, "result.ptr");
|
|
|
|
Builder.CreateStore(Builder.CreatePointerBitCastOrAddrSpaceCast(
|
|
|
|
ReturnValue.getPointer(), Int8PtrTy),
|
|
|
|
ReturnValuePointer);
|
|
|
|
}
|
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);
|
2019-06-21 01:15:21 +08:00
|
|
|
ReturnValuePointer = Address(Addr, getPointerAlign());
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more 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");
|
2020-05-19 02:29:11 +08:00
|
|
|
ReturnValue = Address(Addr, CGM.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();
|
2018-03-14 22:17:45 +08:00
|
|
|
|
|
|
|
// Emit OpenMP specific initialization of the device functions.
|
|
|
|
if (getLangOpts().OpenMP && CurCodeDecl)
|
|
|
|
CGM.getOpenMPRuntime().emitFunctionProlog(*this, CurCodeDecl);
|
|
|
|
|
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.
|
2019-12-04 07:17:01 +08:00
|
|
|
CXXThisValue = ThisFieldLValue.getAddress(*this).getPointer();
|
[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
|
|
|
} 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
|
|
|
|
2017-04-15 06:03:34 +08:00
|
|
|
// Check the 'this' pointer once per function, if it's available.
|
2017-08-25 04:10:33 +08:00
|
|
|
if (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
|
|
|
SanitizerSet SkippedChecks;
|
|
|
|
SkippedChecks.set(SanitizerKind::ObjectSize, true);
|
2019-01-11 09:54:53 +08:00
|
|
|
QualType ThisTy = MD->getThisType();
|
2017-08-25 04:10:33 +08:00
|
|
|
|
|
|
|
// If this is the call operator of a lambda with no capture-default, it
|
|
|
|
// may have a static invoker function, which may call this operator with
|
|
|
|
// a null 'this' pointer.
|
|
|
|
if (isLambdaCallOperator(MD) &&
|
2018-03-01 13:43:23 +08:00
|
|
|
MD->getParent()->getLambdaCaptureDefault() == LCD_None)
|
2017-08-25 04:10:33 +08:00
|
|
|
SkippedChecks.set(SanitizerKind::Null, true);
|
|
|
|
|
|
|
|
EmitTypeCheck(isa<CXXConstructorDecl>(MD) ? TCK_ConstructorCall
|
|
|
|
: TCK_MemberCall,
|
|
|
|
Loc, CXXABIThisValue, ThisTy,
|
2017-04-15 06:03:34 +08:00
|
|
|
getContext().getTypeAlignInChars(ThisTy->getPointeeType()),
|
|
|
|
SkippedChecks);
|
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
|
|
|
}
|
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())
|
2018-09-25 02:24:18 +08:00
|
|
|
DI->EmitLocation(Builder, StartLoc);
|
2018-07-10 03:00:16 +08:00
|
|
|
|
|
|
|
// TODO: Do we need to handle this in two places like we do with
|
|
|
|
// target-features/target-cpu?
|
|
|
|
if (CurFuncDecl)
|
|
|
|
if (const auto *VecWidth = CurFuncDecl->getAttr<MinVectorWidthAttr>())
|
|
|
|
LargestVectorWidth = VecWidth->getVectorWidth();
|
2008-09-10 07:14:03 +08:00
|
|
|
}
|
2008-08-26 05:31:01 +08:00
|
|
|
|
2018-12-13 09:33:20 +08:00
|
|
|
void CodeGenFunction::EmitFunctionBody(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))
|
2019-01-11 09:54:53 +08:00
|
|
|
ResTy = MD->getThisType();
|
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;
|
|
|
|
|
|
|
|
auto *Implicit = ImplicitParamDecl::Create(
|
2017-06-09 21:40:18 +08:00
|
|
|
getContext(), Param->getDeclContext(), Param->getLocation(),
|
|
|
|
/*Id=*/nullptr, getContext().getSizeType(), ImplicitParamDecl::Other);
|
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
|
|
|
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);
|
2017-08-05 06:38:06 +08:00
|
|
|
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).
|
2017-08-05 06:38:06 +08:00
|
|
|
EmitLambdaStaticInvokeBody(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) {
|
2018-12-13 09:33:20 +08:00
|
|
|
EmitFunctionBody(Body);
|
2013-11-05 17:12:18 +08:00
|
|
|
} 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.
|
2018-12-01 07:41:18 +08:00
|
|
|
Expr::EvalResult Result;
|
|
|
|
if (!Cond->EvaluateAsInt(Result, 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
|
|
|
|
2018-12-01 07:41:18 +08:00
|
|
|
llvm::APSInt Int = Result.Val.getInt();
|
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
|
|
|
}
|
|
|
|
|
2020-10-04 20:21:00 +08:00
|
|
|
static Optional<std::pair<uint32_t, uint32_t>>
|
|
|
|
getLikelihoodWeights(Stmt::Likelihood LH) {
|
|
|
|
switch (LH) {
|
|
|
|
case Stmt::LH_Unlikely:
|
|
|
|
return std::pair<uint32_t, uint32_t>(llvm::UnlikelyBranchWeight,
|
|
|
|
llvm::LikelyBranchWeight);
|
|
|
|
case Stmt::LH_None:
|
|
|
|
return None;
|
|
|
|
case Stmt::LH_Likely:
|
|
|
|
return std::pair<uint32_t, uint32_t>(llvm::LikelyBranchWeight,
|
|
|
|
llvm::UnlikelyBranchWeight);
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unknown Likelihood");
|
|
|
|
}
|
|
|
|
|
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.
|
2020-10-04 20:21:00 +08:00
|
|
|
/// \param LH The value of the likelihood attribute on the True branch.
|
2008-11-12 16:04:58 +08:00
|
|
|
void CodeGenFunction::EmitBranchOnBoolExpr(const Expr *Cond,
|
|
|
|
llvm::BasicBlock *TrueBlock,
|
2014-01-07 06:27:43 +08:00
|
|
|
llvm::BasicBlock *FalseBlock,
|
2020-09-10 01:12:32 +08:00
|
|
|
uint64_t TrueCount,
|
2020-10-04 20:21:00 +08:00
|
|
|
Stmt::Likelihood LH) {
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
TrueCount, LH);
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
TrueCount, LH);
|
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);
|
2020-10-04 20:21:00 +08:00
|
|
|
// Propagate the likelihood attribute like __builtin_expect
|
|
|
|
// __builtin_expect(X && Y, 1) -> X and Y are likely
|
|
|
|
// __builtin_expect(X && Y, 0) -> only Y is unlikely
|
2020-09-10 01:12:32 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), LHSTrue, FalseBlock, RHSCount,
|
2020-10-04 20:21:00 +08:00
|
|
|
LH == Stmt::LH_Unlikely ? Stmt::LH_None : LH);
|
2015-01-29 03:50:09 +08:00
|
|
|
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);
|
2020-09-10 01:12:32 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, TrueCount,
|
2020-10-04 20:21:00 +08:00
|
|
|
LH);
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
TrueCount, LH);
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
TrueCount, LH);
|
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
|
|
|
{
|
2020-10-04 20:21:00 +08:00
|
|
|
// Propagate the likelihood attribute like __builtin_expect
|
|
|
|
// __builtin_expect(X || Y, 1) -> only Y is likely
|
|
|
|
// __builtin_expect(X || Y, 0) -> both X and Y are unlikely
|
2015-01-29 03:50:09 +08:00
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
2020-09-10 01:12:32 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, LHSFalse, LHSCount,
|
2020-10-04 20:21:00 +08:00
|
|
|
LH == Stmt::LH_Likely ? Stmt::LH_None : LH);
|
2015-01-29 03:50:09 +08:00
|
|
|
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);
|
2020-09-10 01:12:32 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, RHSCount,
|
2020-10-04 20:21:00 +08:00
|
|
|
LH);
|
2014-01-07 06:27:43 +08:00
|
|
|
|
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;
|
2020-10-04 20:21:00 +08:00
|
|
|
// The values of the enum are chosen to make this negation possible.
|
|
|
|
LH = static_cast<Stmt::Likelihood>(-LH);
|
2014-01-07 06:27:43 +08:00
|
|
|
// Negate the condition and swap the destination blocks.
|
|
|
|
return EmitBranchOnBoolExpr(CondUOp->getSubExpr(), FalseBlock, TrueBlock,
|
2020-10-04 20:21:00 +08:00
|
|
|
FalseCount, LH);
|
2014-01-07 06:27:43 +08:00
|
|
|
}
|
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
|
|
|
|
2020-10-04 20:21:00 +08:00
|
|
|
// The ConditionalOperator itself has no likelihood information for its
|
|
|
|
// true and false branches. This matches the behavior of __builtin_expect.
|
2012-02-14 11:54:45 +08:00
|
|
|
ConditionalEvaluation cond(*this);
|
2015-04-24 07:06:47 +08:00
|
|
|
EmitBranchOnBoolExpr(CondOp->getCond(), LHSBlock, RHSBlock,
|
2020-10-04 20:21:00 +08:00
|
|
|
getProfileCount(CondOp), Stmt::LH_None);
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
LHSScaledTrueCount, LH);
|
2015-01-29 03:50:09 +08:00
|
|
|
}
|
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,
|
2020-10-04 20:21:00 +08:00
|
|
|
TrueCount - LHSScaledTrueCount, LH);
|
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;
|
2018-12-13 04:30:53 +08:00
|
|
|
auto *Call = dyn_cast<CallExpr>(Cond->IgnoreImpCasts());
|
2016-04-20 02:06:33 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-04 20:21:00 +08:00
|
|
|
llvm::MDNode *Weights = nullptr;
|
|
|
|
Optional<std::pair<uint32_t, uint32_t>> LHW = getLikelihoodWeights(LH);
|
|
|
|
if (LHW) {
|
|
|
|
llvm::MDBuilder MDHelper(CGM.getLLVMContext());
|
|
|
|
Weights = MDHelper.createBranchWeights(LHW->first, LHW->second);
|
|
|
|
}
|
2020-09-10 01:12:32 +08:00
|
|
|
if (!Weights) {
|
|
|
|
uint64_t CurrentCount = std::max(getCurrentProfileCount(), TrueCount);
|
|
|
|
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))) {
|
2018-02-03 21:55:59 +08:00
|
|
|
auto VlaSize = getVLASize(vlaType);
|
|
|
|
SizeVal = VlaSize.NumElts;
|
|
|
|
CharUnits eltSize = getContext().getTypeSizeInChars(VlaSize.Type);
|
2011-06-25 05:55:10 +08:00
|
|
|
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();
|
2019-10-03 21:00:29 +08:00
|
|
|
NullVariable->setAlignment(NullAlign.getAsAlign());
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
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)) {
|
2018-02-03 21:55:59 +08:00
|
|
|
numVLAElements = getVLASize(cast<VariableArrayType>(arrayType)).NumElts;
|
2011-07-09 09:37:26 +08:00
|
|
|
|
|
|
|
// 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;
|
|
|
|
}
|
|
|
|
|
2018-02-03 21:55:59 +08:00
|
|
|
CodeGenFunction::VlaSizePair CodeGenFunction::getVLASize(QualType type) {
|
2011-06-25 05:55:10 +08:00
|
|
|
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
|
|
|
|
2018-02-03 21:55:59 +08:00
|
|
|
CodeGenFunction::VlaSizePair
|
2011-06-25 05:55:10 +08:00
|
|
|
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
|
|
|
|
2018-02-03 21:55:59 +08:00
|
|
|
return { numElements, elementType };
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeGenFunction::VlaSizePair
|
|
|
|
CodeGenFunction::getVLAElements1D(QualType type) {
|
|
|
|
const VariableArrayType *vla = getContext().getAsVariableArrayType(type);
|
|
|
|
assert(vla && "type was not a variable array type!");
|
|
|
|
return getVLAElements1D(vla);
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeGenFunction::VlaSizePair
|
|
|
|
CodeGenFunction::getVLAElements1D(const VariableArrayType *Vla) {
|
|
|
|
llvm::Value *VlaSize = VLASizeMap[Vla->getSizeExpr()];
|
|
|
|
assert(VlaSize && "no size for VLA!");
|
|
|
|
assert(VlaSize->getType() == SizeTy);
|
|
|
|
return { VlaSize, Vla->getElementType() };
|
2011-06-25 05:55:10 +08:00
|
|
|
}
|
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)
|
2019-10-02 14:35:23 +08:00
|
|
|
#include "clang/AST/TypeNodes.inc"
|
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:
|
2020-05-12 00:45:51 +08:00
|
|
|
case Type::ConstantMatrix:
|
2011-06-25 05:55:10 +08:00
|
|
|
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:
|
2020-04-18 01:44:19 +08:00
|
|
|
case Type::ExtInt:
|
2011-06-25 05:55:10 +08:00
|
|
|
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[] = {
|
2018-08-10 05:08:08 +08:00
|
|
|
EmitCheckSourceLocation(size->getBeginLoc()),
|
|
|
|
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:
|
2019-05-07 11:20:17 +08:00
|
|
|
case Type::MacroQualified:
|
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);
|
2019-12-04 07:17:01 +08:00
|
|
|
return EmitLValue(E).getAddress(*this);
|
2009-01-21 01:46:04 +08:00
|
|
|
}
|
2009-02-08 06:53:43 +08:00
|
|
|
|
2015-09-18 04:55:33 +08:00
|
|
|
Address CodeGenFunction::EmitMSVAListRef(const Expr *E) {
|
2019-12-04 07:17:01 +08:00
|
|
|
return EmitLValue(E).getAddress(*this);
|
2015-09-18 04:55:33 +08:00
|
|
|
}
|
|
|
|
|
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) {
|
2019-05-22 07:15:18 +08:00
|
|
|
assert(Init.hasValue() && "Invalid DeclRefExpr initializer!");
|
2013-08-30 16:53:09 +08:00
|
|
|
if (CGDebugInfo *Dbg = getDebugInfo())
|
2020-01-14 07:54:54 +08:00
|
|
|
if (CGM.getCodeGenOpts().hasReducedDebugInfo())
|
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
|
|
|
|
2020-02-14 08:36:27 +08:00
|
|
|
void CodeGenFunction::emitAlignmentAssumption(llvm::Value *PtrValue,
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
QualType Ty, SourceLocation Loc,
|
|
|
|
SourceLocation AssumptionLoc,
|
|
|
|
llvm::Value *Alignment,
|
|
|
|
llvm::Value *OffsetValue) {
|
2020-09-12 19:36:45 +08:00
|
|
|
if (Alignment->getType() != IntPtrTy)
|
|
|
|
Alignment =
|
|
|
|
Builder.CreateIntCast(Alignment, IntPtrTy, false, "casted.align");
|
|
|
|
if (OffsetValue && OffsetValue->getType() != IntPtrTy)
|
|
|
|
OffsetValue =
|
|
|
|
Builder.CreateIntCast(OffsetValue, IntPtrTy, true, "casted.offset");
|
|
|
|
llvm::Value *TheCheck = nullptr;
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::Alignment)) {
|
2020-09-12 19:36:45 +08:00
|
|
|
llvm::Value *PtrIntValue =
|
|
|
|
Builder.CreatePtrToInt(PtrValue, IntPtrTy, "ptrint");
|
|
|
|
|
|
|
|
if (OffsetValue) {
|
|
|
|
bool IsOffsetZero = false;
|
|
|
|
if (const auto *CI = dyn_cast<llvm::ConstantInt>(OffsetValue))
|
|
|
|
IsOffsetZero = CI->isZero();
|
|
|
|
|
|
|
|
if (!IsOffsetZero)
|
|
|
|
PtrIntValue = Builder.CreateSub(PtrIntValue, OffsetValue, "offsetptr");
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Value *Zero = llvm::ConstantInt::get(IntPtrTy, 0);
|
|
|
|
llvm::Value *Mask =
|
|
|
|
Builder.CreateSub(Alignment, llvm::ConstantInt::get(IntPtrTy, 1));
|
|
|
|
llvm::Value *MaskedPtr = Builder.CreateAnd(PtrIntValue, Mask, "maskedptr");
|
|
|
|
TheCheck = Builder.CreateICmpEQ(MaskedPtr, Zero, "maskcond");
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
}
|
2020-09-12 19:36:45 +08:00
|
|
|
llvm::Instruction *Assumption = Builder.CreateAlignmentAssumption(
|
|
|
|
CGM.getDataLayout(), PtrValue, Alignment, OffsetValue);
|
|
|
|
|
|
|
|
if (!SanOpts.has(SanitizerKind::Alignment))
|
|
|
|
return;
|
|
|
|
emitAlignmentAssumptionCheck(PtrValue, Ty, Loc, AssumptionLoc, Alignment,
|
|
|
|
OffsetValue, TheCheck, Assumption);
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
}
|
|
|
|
|
2020-02-14 08:36:27 +08:00
|
|
|
void CodeGenFunction::emitAlignmentAssumption(llvm::Value *PtrValue,
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
const Expr *E,
|
|
|
|
SourceLocation AssumptionLoc,
|
2019-10-11 22:59:44 +08:00
|
|
|
llvm::Value *Alignment,
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
llvm::Value *OffsetValue) {
|
|
|
|
if (auto *CE = dyn_cast<CastExpr>(E))
|
|
|
|
E = CE->getSubExprAsWritten();
|
|
|
|
QualType Ty = E->getType();
|
|
|
|
SourceLocation Loc = E->getExprLoc();
|
|
|
|
|
2020-02-14 08:36:27 +08:00
|
|
|
emitAlignmentAssumption(PtrValue, Ty, Loc, AssumptionLoc, Alignment,
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
OffsetValue);
|
|
|
|
}
|
|
|
|
|
2019-02-04 05:53:49 +08:00
|
|
|
llvm::Value *CodeGenFunction::EmitAnnotationCall(llvm::Function *AnnotationFn,
|
2011-09-10 06:41:49 +08:00
|
|
|
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();
|
2019-02-04 05:53:49 +08:00
|
|
|
llvm::Function *F = CGM.getIntrinsic(llvm::Intrinsic::ptr_annotation,
|
2011-09-10 06:41:49 +08:00
|
|
|
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)
|
2018-12-19 00:22:21 +08:00
|
|
|
V = Builder.CreateBitCast(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;
|
2019-12-24 02:38:38 +08:00
|
|
|
CGM.getContext().getFunctionFeatureMap(CallerFeatureMap, FD);
|
2015-11-12 09:09:58 +08:00
|
|
|
|
|
|
|
// 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;
|
2018-05-04 05:01:33 +08:00
|
|
|
Feature.split(OrFeatures, '|');
|
2018-10-21 01:53:42 +08:00
|
|
|
return llvm::any_of(OrFeatures, [&](StringRef Feature) {
|
|
|
|
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) {
|
2019-06-22 06:29:32 +08:00
|
|
|
return checkTargetFeatures(E->getBeginLoc(), TargetDecl);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emits an error if we don't have a valid set of target features for the
|
|
|
|
// called function.
|
|
|
|
void CodeGenFunction::checkTargetFeatures(SourceLocation Loc,
|
|
|
|
const FunctionDecl *TargetDecl) {
|
2015-11-12 08:44:07 +08:00
|
|
|
// 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.
|
2019-08-29 04:59:25 +08:00
|
|
|
const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(CurCodeDecl);
|
2015-11-12 08:44:07 +08:00
|
|
|
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;
|
2018-05-04 05:01:33 +08:00
|
|
|
StringRef(FeatureList).split(ReqFeatures, ',');
|
2015-11-14 10:38:37 +08:00
|
|
|
if (!hasRequiredFeatures(ReqFeatures, CGM, FD, MissingFeature))
|
2019-06-22 06:29:32 +08:00
|
|
|
CGM.getDiags().Report(Loc, diag::err_builtin_needs_feature)
|
2015-11-12 08:44:12 +08:00
|
|
|
<< TargetDecl->getDeclName()
|
|
|
|
<< CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
|
|
|
|
|
2019-11-19 05:38:56 +08:00
|
|
|
} else if (!TargetDecl->isMultiVersion() &&
|
|
|
|
TargetDecl->hasAttr<TargetAttr>()) {
|
2015-11-12 08:44:12 +08:00
|
|
|
// Get the required features for the callee.
|
2018-06-07 16:48:36 +08:00
|
|
|
|
|
|
|
const TargetAttr *TD = TargetDecl->getAttr<TargetAttr>();
|
2019-12-24 02:38:38 +08:00
|
|
|
ParsedTargetAttr ParsedAttr =
|
|
|
|
CGM.getContext().filterFunctionTargetAttrs(TD);
|
2018-06-07 16:48:36 +08:00
|
|
|
|
2015-11-12 08:44:12 +08:00
|
|
|
SmallVector<StringRef, 1> ReqFeatures;
|
|
|
|
llvm::StringMap<bool> CalleeFeatureMap;
|
2020-04-09 04:14:33 +08:00
|
|
|
CGM.getContext().getFunctionFeatureMap(CalleeFeatureMap, TargetDecl);
|
2018-06-07 16:48:36 +08:00
|
|
|
|
|
|
|
for (const auto &F : ParsedAttr.Features) {
|
|
|
|
if (F[0] == '+' && CalleeFeatureMap.lookup(F.substr(1)))
|
|
|
|
ReqFeatures.push_back(StringRef(F).substr(1));
|
|
|
|
}
|
|
|
|
|
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))
|
2019-06-22 06:29:32 +08:00
|
|
|
CGM.getDiags().Report(Loc, 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
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
llvm::Value *
|
|
|
|
CodeGenFunction::FormResolverCondition(const MultiVersionResolverOption &RO) {
|
|
|
|
llvm::Value *Condition = nullptr;
|
Implement Attribute Target MultiVersioning
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
2018-01-09 05:34:17 +08:00
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
if (!RO.Conditions.Architecture.empty())
|
|
|
|
Condition = EmitX86CpuIs(RO.Conditions.Architecture);
|
Implement Attribute Target MultiVersioning
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
2018-01-09 05:34:17 +08:00
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
if (!RO.Conditions.Features.empty()) {
|
|
|
|
llvm::Value *FeatureCond = EmitX86CpuSupports(RO.Conditions.Features);
|
|
|
|
Condition =
|
|
|
|
Condition ? Builder.CreateAnd(Condition, FeatureCond) : FeatureCond;
|
Implement Attribute Target MultiVersioning
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
2018-01-09 05:34:17 +08:00
|
|
|
}
|
2018-09-14 00:58:24 +08:00
|
|
|
return Condition;
|
Implement Attribute Target MultiVersioning
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
2018-01-09 05:34:17 +08:00
|
|
|
}
|
|
|
|
|
2018-10-26 02:57:19 +08:00
|
|
|
static void CreateMultiVersionResolverReturn(CodeGenModule &CGM,
|
|
|
|
llvm::Function *Resolver,
|
|
|
|
CGBuilderTy &Builder,
|
|
|
|
llvm::Function *FuncToReturn,
|
|
|
|
bool SupportsIFunc) {
|
|
|
|
if (SupportsIFunc) {
|
|
|
|
Builder.CreateRet(FuncToReturn);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::SmallVector<llvm::Value *, 10> Args;
|
|
|
|
llvm::for_each(Resolver->args(),
|
|
|
|
[&](llvm::Argument &Arg) { Args.push_back(&Arg); });
|
|
|
|
|
|
|
|
llvm::CallInst *Result = Builder.CreateCall(FuncToReturn, Args);
|
|
|
|
Result->setTailCallKind(llvm::CallInst::TCK_MustTail);
|
|
|
|
|
|
|
|
if (Resolver->getReturnType()->isVoidTy())
|
|
|
|
Builder.CreateRetVoid();
|
|
|
|
else
|
|
|
|
Builder.CreateRet(Result);
|
|
|
|
}
|
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
void CodeGenFunction::EmitMultiVersionResolver(
|
|
|
|
llvm::Function *Resolver, ArrayRef<MultiVersionResolverOption> Options) {
|
2020-01-07 17:32:39 +08:00
|
|
|
assert(getContext().getTargetInfo().getTriple().isX86() &&
|
2018-07-20 22:13:28 +08:00
|
|
|
"Only implemented for x86 targets");
|
2018-10-26 02:57:19 +08:00
|
|
|
|
|
|
|
bool SupportsIFunc = getContext().getTargetInfo().supportsIFunc();
|
|
|
|
|
2018-07-20 22:13:28 +08:00
|
|
|
// Main function's basic block.
|
|
|
|
llvm::BasicBlock *CurBlock = createBasicBlock("resolver_entry", Resolver);
|
|
|
|
Builder.SetInsertPoint(CurBlock);
|
|
|
|
EmitX86CpuInit();
|
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
for (const MultiVersionResolverOption &RO : Options) {
|
2018-07-20 22:13:28 +08:00
|
|
|
Builder.SetInsertPoint(CurBlock);
|
2018-09-14 00:58:24 +08:00
|
|
|
llvm::Value *Condition = FormResolverCondition(RO);
|
2018-07-20 22:13:28 +08:00
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
// The 'default' or 'generic' case.
|
|
|
|
if (!Condition) {
|
|
|
|
assert(&RO == Options.end() - 1 &&
|
|
|
|
"Default or Generic case must be last");
|
2018-10-26 02:57:19 +08:00
|
|
|
CreateMultiVersionResolverReturn(CGM, Resolver, Builder, RO.Function,
|
|
|
|
SupportsIFunc);
|
2018-07-20 22:13:28 +08:00
|
|
|
return;
|
|
|
|
}
|
2018-09-14 00:58:24 +08:00
|
|
|
|
2018-07-20 22:13:28 +08:00
|
|
|
llvm::BasicBlock *RetBlock = createBasicBlock("resolver_return", Resolver);
|
2018-10-26 02:57:19 +08:00
|
|
|
CGBuilderTy RetBuilder(*this, RetBlock);
|
|
|
|
CreateMultiVersionResolverReturn(CGM, Resolver, RetBuilder, RO.Function,
|
|
|
|
SupportsIFunc);
|
2018-07-20 22:13:28 +08:00
|
|
|
CurBlock = createBasicBlock("resolver_else", Resolver);
|
2018-09-14 00:58:24 +08:00
|
|
|
Builder.CreateCondBr(Condition, RetBlock, CurBlock);
|
2018-07-20 22:13:28 +08:00
|
|
|
}
|
|
|
|
|
2018-09-14 00:58:24 +08:00
|
|
|
// If no generic/default, emit an unreachable.
|
2018-07-20 22:13:28 +08:00
|
|
|
Builder.SetInsertPoint(CurBlock);
|
|
|
|
llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap);
|
|
|
|
TrapCall->setDoesNotReturn();
|
|
|
|
TrapCall->setDoesNotThrow();
|
|
|
|
Builder.CreateUnreachable();
|
|
|
|
Builder.ClearInsertionPoint();
|
|
|
|
}
|
|
|
|
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
// Loc - where the diagnostic will point, where in the source code this
|
|
|
|
// alignment has failed.
|
|
|
|
// SecondaryLoc - if present (will be present if sufficiently different from
|
|
|
|
// Loc), the diagnostic will additionally point a "Note:" to this location.
|
|
|
|
// It should be the location where the __attribute__((assume_aligned))
|
|
|
|
// was written e.g.
|
2020-02-14 08:36:27 +08:00
|
|
|
void CodeGenFunction::emitAlignmentAssumptionCheck(
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
llvm::Value *Ptr, QualType Ty, SourceLocation Loc,
|
|
|
|
SourceLocation SecondaryLoc, llvm::Value *Alignment,
|
|
|
|
llvm::Value *OffsetValue, llvm::Value *TheCheck,
|
|
|
|
llvm::Instruction *Assumption) {
|
|
|
|
assert(Assumption && isa<llvm::CallInst>(Assumption) &&
|
2020-04-28 11:15:59 +08:00
|
|
|
cast<llvm::CallInst>(Assumption)->getCalledOperand() ==
|
[clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```
This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.
Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.
This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall
Reviewed By: rjmccall
Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54589
llvm-svn: 351177
2019-01-15 17:44:25 +08:00
|
|
|
llvm::Intrinsic::getDeclaration(
|
|
|
|
Builder.GetInsertBlock()->getParent()->getParent(),
|
|
|
|
llvm::Intrinsic::assume) &&
|
|
|
|
"Assumption should be a call to llvm.assume().");
|
|
|
|
assert(&(Builder.GetInsertBlock()->back()) == Assumption &&
|
|
|
|
"Assumption should be the last instruction of the basic block, "
|
|
|
|
"since the basic block is still being generated.");
|
|
|
|
|
|
|
|
if (!SanOpts.has(SanitizerKind::Alignment))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Don't check pointers to volatile data. The behavior here is implementation-
|
|
|
|
// defined.
|
|
|
|
if (Ty->getPointeeType().isVolatileQualified())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// We need to temorairly remove the assumption so we can insert the
|
|
|
|
// sanitizer check before it, else the check will be dropped by optimizations.
|
|
|
|
Assumption->removeFromParent();
|
|
|
|
|
|
|
|
{
|
|
|
|
SanitizerScope SanScope(this);
|
|
|
|
|
|
|
|
if (!OffsetValue)
|
|
|
|
OffsetValue = Builder.getInt1(0); // no offset.
|
|
|
|
|
|
|
|
llvm::Constant *StaticData[] = {EmitCheckSourceLocation(Loc),
|
|
|
|
EmitCheckSourceLocation(SecondaryLoc),
|
|
|
|
EmitCheckTypeDescriptor(Ty)};
|
|
|
|
llvm::Value *DynamicData[] = {EmitCheckValue(Ptr),
|
|
|
|
EmitCheckValue(Alignment),
|
|
|
|
EmitCheckValue(OffsetValue)};
|
|
|
|
EmitCheck({std::make_pair(TheCheck, SanitizerKind::Alignment)},
|
|
|
|
SanitizerHandler::AlignmentAssumption, StaticData, DynamicData);
|
|
|
|
}
|
|
|
|
|
|
|
|
// We are now in the (new, empty) "cont" basic block.
|
|
|
|
// Reintroduce the assumption.
|
|
|
|
Builder.Insert(Assumption);
|
|
|
|
// FIXME: Assumption still has it's original basic block as it's Parent.
|
|
|
|
}
|
|
|
|
|
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();
|
|
|
|
}
|