2007-05-28 09:07:47 +08:00
|
|
|
//===--- CodeGenFunction.cpp - Emit LLVM Code from ASTs for a Function ----===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 03:59:25 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-05-28 09:07:47 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This coordinates the per-function state used while generating code.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CodeGenFunction.h"
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
#include "CGBlocks.h"
|
2016-04-09 00:52:00 +08:00
|
|
|
#include "CGCleanup.h"
|
2011-10-07 02:51:56 +08:00
|
|
|
#include "CGCUDARuntime.h"
|
2010-08-31 15:33:07 +08:00
|
|
|
#include "CGCXXABI.h"
|
2008-05-22 09:40:10 +08:00
|
|
|
#include "CGDebugInfo.h"
|
2014-05-06 18:08:46 +08:00
|
|
|
#include "CGOpenMPRuntime.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "CodeGenModule.h"
|
2014-01-07 06:27:43 +08:00
|
|
|
#include "CodeGenPGO.h"
|
2013-10-21 05:29:19 +08:00
|
|
|
#include "TargetInfo.h"
|
2008-08-11 13:00:27 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2017-08-25 04:10:33 +08:00
|
|
|
#include "clang/AST/ASTLambda.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"
|
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"
|
2013-01-02 19:45:17 +08:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/MDBuilder.h"
|
|
|
|
#include "llvm/IR/Operator.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;
|
|
|
|
|
2016-10-26 09:59:57 +08:00
|
|
|
// Disable lifetime markers in msan builds.
|
|
|
|
// FIXME: Remove this when msan works with lifetime markers.
|
|
|
|
if (LangOpts.Sanitize.has(SanitizerKind::Memory))
|
|
|
|
return false;
|
|
|
|
|
2017-03-31 17:19:25 +08:00
|
|
|
// Asan uses markers for use-after-scope checks.
|
|
|
|
if (CGOpts.SanitizeAddressUseAfterScope)
|
|
|
|
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)),
|
2018-07-11 05:07:50 +08:00
|
|
|
SanOpts(CGM.getLangOpts().Sanitize), 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
|
|
|
|
|
|
|
llvm::FastMathFlags FMF;
|
|
|
|
if (CGM.getLangOpts().FastMath)
|
2017-11-07 00:27:36 +08:00
|
|
|
FMF.setFast();
|
2012-12-04 08:36:06 +08:00
|
|
|
if (CGM.getLangOpts().FiniteMathOnly) {
|
2012-12-10 05:58:24 +08:00
|
|
|
FMF.setNoNaNs();
|
|
|
|
FMF.setNoInfs();
|
2012-12-04 08:36:06 +08:00
|
|
|
}
|
2014-12-11 00:41:14 +08:00
|
|
|
if (CGM.getCodeGenOpts().NoNaNsFPMath) {
|
|
|
|
FMF.setNoNaNs();
|
|
|
|
}
|
|
|
|
if (CGM.getCodeGenOpts().NoSignedZeros) {
|
|
|
|
FMF.setNoSignedZeros();
|
|
|
|
}
|
2015-04-09 23:03:23 +08:00
|
|
|
if (CGM.getCodeGenOpts().ReciprocalMath) {
|
|
|
|
FMF.setAllowReciprocal();
|
|
|
|
}
|
[Driver, CodeGen] pass through and apply -fassociative-math
There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF:
1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the
interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math.
This was mostly already done - we just need to translate the flag as a codegen option.
The test file is complicated because there are many potential combinations of flags here.
Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math.
2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and
corresponding test.
For the motivating example from PR27372:
float foo(float a, float x) { return ((a + x) - x); }
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub'
%add = fadd nnan ninf nsz arcp contract float %0, %1
%sub = fsub nnan ninf nsz arcp contract float %add, %2
So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch).
This case now works as expected end-to-end although the underlying logic is still wrong:
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example:
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd
%add = fadd reassoc float %0, %1
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
Differential Revision: https://reviews.llvm.org/D39812
llvm-svn: 320920
2017-12-17 00:11:17 +08:00
|
|
|
if (CGM.getCodeGenOpts().Reassociate) {
|
|
|
|
FMF.setAllowReassoc();
|
|
|
|
}
|
2016-01-13 02:03:41 +08:00
|
|
|
Builder.setFastMathFlags(FMF);
|
2008-06-18 02:05:57 +08:00
|
|
|
}
|
2007-05-30 07:17:50 +08:00
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
CodeGenFunction::~CodeGenFunction() {
|
2013-06-13 04:42:33 +08:00
|
|
|
assert(LifetimeExtendedCleanupStack.empty() && "failed to emit a cleanup");
|
|
|
|
|
2011-11-10 16:15:53 +08:00
|
|
|
// If there are any unclaimed block infos, go ahead and destroy them
|
|
|
|
// now. This can happen if IR-gen gets clever and skips evaluating
|
|
|
|
// something.
|
|
|
|
if (FirstBlockInfo)
|
|
|
|
destroyBlockInfos(FirstBlockInfo);
|
2014-05-06 18:08:46 +08:00
|
|
|
|
2017-01-20 16:57:28 +08:00
|
|
|
if (getLangOpts().OpenMP && CurFn)
|
2015-02-25 16:32:46 +08:00
|
|
|
CGM.getOpenMPRuntime().functionFinished(*this);
|
2011-11-10 16:15:53 +08:00
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CharUnits CodeGenFunction::getNaturalPointeeTypeAlignment(QualType T,
|
2017-10-17 17:12:13 +08:00
|
|
|
LValueBaseInfo *BaseInfo,
|
|
|
|
TBAAAccessInfo *TBAAInfo) {
|
|
|
|
return getNaturalTypeAlignment(T->getPointeeType(), BaseInfo, TBAAInfo,
|
2017-10-14 00:58:30 +08:00
|
|
|
/* forPointeeType= */ true);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CharUnits CodeGenFunction::getNaturalTypeAlignment(QualType T,
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo *BaseInfo,
|
2017-10-14 00:58:30 +08:00
|
|
|
TBAAAccessInfo *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
|
|
|
bool forPointeeType) {
|
2017-10-14 00:58:30 +08:00
|
|
|
if (TBAAInfo)
|
|
|
|
*TBAAInfo = CGM.getTBAAAccessInfo(T);
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
// Honor alignment typedef attributes even on incomplete types.
|
|
|
|
// We also honor them straight for C++ class types, even as pointees;
|
|
|
|
// there's an expressivity gap here.
|
|
|
|
if (auto TT = T->getAs<TypedefType>()) {
|
|
|
|
if (auto Align = TT->getDecl()->getMaxAlignment()) {
|
2017-05-19 01:07:11 +08:00
|
|
|
if (BaseInfo)
|
2017-10-31 19:05:34 +08:00
|
|
|
*BaseInfo = LValueBaseInfo(AlignmentSource::AttributedType);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more 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 getContext().toCharUnitsFromBits(Align);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-19 01:07:11 +08:00
|
|
|
if (BaseInfo)
|
2017-10-31 19:05:34 +08:00
|
|
|
*BaseInfo = LValueBaseInfo(AlignmentSource::Type);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
|
2014-09-19 06:05:54 +08:00
|
|
|
CharUnits Alignment;
|
2015-09-11 05:52:00 +08:00
|
|
|
if (T->isIncompleteType()) {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Alignment = CharUnits::One(); // Shouldn't be used, but pessimistic is best.
|
|
|
|
} else {
|
|
|
|
// For C++ class pointees, we don't know whether we're pointing at a
|
|
|
|
// base or a complete object, so we generally need to use the
|
|
|
|
// non-virtual alignment.
|
|
|
|
const CXXRecordDecl *RD;
|
|
|
|
if (forPointeeType && (RD = T->getAsCXXRecordDecl())) {
|
|
|
|
Alignment = CGM.getClassPointerAlignment(RD);
|
|
|
|
} else {
|
|
|
|
Alignment = getContext().getTypeAlignInChars(T);
|
2017-03-08 22:00:44 +08:00
|
|
|
if (T.getQualifiers().hasUnaligned())
|
|
|
|
Alignment = CharUnits::One();
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Cap to the global maximum type alignment unless the alignment
|
|
|
|
// was somehow explicit on the type.
|
|
|
|
if (unsigned MaxAlign = getLangOpts().MaxTypeAlign) {
|
|
|
|
if (Alignment.getQuantity() > MaxAlign &&
|
|
|
|
!getContext().isAlignmentRequired(T))
|
|
|
|
Alignment = CharUnits::fromQuantity(MaxAlign);
|
|
|
|
}
|
2014-09-19 06:05:54 +08:00
|
|
|
}
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return Alignment;
|
|
|
|
}
|
|
|
|
|
|
|
|
LValue CodeGenFunction::MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T) {
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo BaseInfo;
|
2017-10-14 00:58:30 +08:00
|
|
|
TBAAAccessInfo TBAAInfo;
|
|
|
|
CharUnits Alignment = 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;
|
|
|
|
CharUnits Align = getNaturalTypeAlignment(T, &BaseInfo, &TBAAInfo,
|
|
|
|
/* forPointeeType= */ true);
|
|
|
|
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:
|
|
|
|
#include "clang/AST/TypeNodes.def"
|
2013-03-08 05:37:08 +08:00
|
|
|
llvm_unreachable("non-canonical or dependent type in IR-generation");
|
|
|
|
|
2013-04-30 21:56:41 +08:00
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
|
|
|
llvm_unreachable("undeduced type in IR-generation");
|
2013-04-30 21:56:41 +08:00
|
|
|
|
2013-03-08 05:37:08 +08:00
|
|
|
// Various scalar types.
|
|
|
|
case Type::Builtin:
|
|
|
|
case Type::Pointer:
|
|
|
|
case Type::BlockPointer:
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
case Type::MemberPointer:
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::FunctionProto:
|
|
|
|
case Type::FunctionNoProto:
|
|
|
|
case Type::Enum:
|
|
|
|
case Type::ObjCObjectPointer:
|
2016-01-09 20:53:17 +08:00
|
|
|
case Type::Pipe:
|
2013-03-08 05:37:08 +08:00
|
|
|
return TEK_Scalar;
|
|
|
|
|
|
|
|
// Complexes.
|
|
|
|
case Type::Complex:
|
|
|
|
return TEK_Complex;
|
|
|
|
|
|
|
|
// Arrays, records, and Objective-C objects.
|
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
case Type::VariableArray:
|
|
|
|
case Type::Record:
|
|
|
|
case Type::ObjCObject:
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
return TEK_Aggregate;
|
|
|
|
|
|
|
|
// We operate on atomic values according to their underlying type.
|
|
|
|
case Type::Atomic:
|
|
|
|
type = cast<AtomicType>(type)->getValueType();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown type kind!");
|
2011-05-15 10:34:36 +08:00
|
|
|
}
|
2008-06-18 02:05:57 +08:00
|
|
|
}
|
2008-03-31 07:03:07 +08:00
|
|
|
|
2015-01-14 15:38:27 +08:00
|
|
|
llvm::DebugLoc CodeGenFunction::EmitReturnBlock() {
|
2009-01-27 07:27:52 +08:00
|
|
|
// For cleanliness, we try to avoid emitting the return block for
|
|
|
|
// simple cases.
|
|
|
|
llvm::BasicBlock *CurBB = Builder.GetInsertBlock();
|
|
|
|
|
|
|
|
if (CurBB) {
|
|
|
|
assert(!CurBB->getTerminator() && "Unexpected terminated block.");
|
|
|
|
|
2009-07-19 16:24:34 +08:00
|
|
|
// We have a valid insert point, reuse it if it is empty or there are no
|
|
|
|
// explicit jumps to the return block.
|
2010-07-24 05:56:41 +08:00
|
|
|
if (CurBB->empty() || ReturnBlock.getBlock()->use_empty()) {
|
|
|
|
ReturnBlock.getBlock()->replaceAllUsesWith(CurBB);
|
|
|
|
delete ReturnBlock.getBlock();
|
2009-07-19 16:24:34 +08:00
|
|
|
} else
|
2010-07-24 05:56:41 +08:00
|
|
|
EmitBlock(ReturnBlock.getBlock());
|
2015-01-14 15:38:27 +08:00
|
|
|
return llvm::DebugLoc();
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, if the return block is the target of a single direct
|
|
|
|
// branch then we can just put the code in that block instead. This
|
|
|
|
// cleans up functions which started with a unified return block.
|
2010-07-24 05:56:41 +08:00
|
|
|
if (ReturnBlock.getBlock()->hasOneUse()) {
|
2009-09-09 23:08:12 +08:00
|
|
|
llvm::BranchInst *BI =
|
2014-03-09 11:16:50 +08:00
|
|
|
dyn_cast<llvm::BranchInst>(*ReturnBlock.getBlock()->user_begin());
|
2010-07-06 09:34:17 +08:00
|
|
|
if (BI && BI->isUnconditional() &&
|
2010-07-24 05:56:41 +08:00
|
|
|
BI->getSuccessor(0) == ReturnBlock.getBlock()) {
|
2015-01-14 15:38:27 +08:00
|
|
|
// Record/return the DebugLoc of the simple 'return' expression to be used
|
|
|
|
// later by the actual 'ret' instruction.
|
|
|
|
llvm::DebugLoc Loc = BI->getDebugLoc();
|
2009-01-27 07:27:52 +08:00
|
|
|
Builder.SetInsertPoint(BI->getParent());
|
|
|
|
BI->eraseFromParent();
|
2010-07-24 05:56:41 +08:00
|
|
|
delete ReturnBlock.getBlock();
|
2015-01-14 15:38:27 +08:00
|
|
|
return Loc;
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-05-16 15:57:57 +08:00
|
|
|
// FIXME: We are at an unreachable point, there is no reason to emit the block
|
|
|
|
// unless it has uses. However, we still need a place to put the debug
|
|
|
|
// region.end for now.
|
2009-01-27 07:27:52 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
EmitBlock(ReturnBlock.getBlock());
|
2015-01-14 15:38:27 +08:00
|
|
|
return llvm::DebugLoc();
|
2010-07-06 09:34:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void EmitIfUsed(CodeGenFunction &CGF, llvm::BasicBlock *BB) {
|
|
|
|
if (!BB) return;
|
|
|
|
if (!BB->use_empty())
|
|
|
|
return CGF.CurFn->getBasicBlockList().push_back(BB);
|
|
|
|
delete BB;
|
2009-01-27 07:27:52 +08:00
|
|
|
}
|
|
|
|
|
2008-08-26 16:29:31 +08:00
|
|
|
void CodeGenFunction::FinishFunction(SourceLocation EndLoc) {
|
2008-03-31 07:03:07 +08:00
|
|
|
assert(BreakContinueStack.empty() &&
|
|
|
|
"mismatched push/pop in break/continue stack!");
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-05-04 04:11:48 +08:00
|
|
|
bool OnlySimpleReturnStmts = NumSimpleReturnExprs > 0
|
2013-07-25 08:23:42 +08:00
|
|
|
&& NumSimpleReturnExprs == NumReturnExprs
|
|
|
|
&& ReturnBlock.getBlock()->use_empty();
|
|
|
|
// Usually the return expression is evaluated before the cleanup
|
|
|
|
// code. If the function contains only a simple return statement,
|
|
|
|
// such as a constant, the location before the cleanup code becomes
|
|
|
|
// the last useful breakpoint in the function, because the simple
|
|
|
|
// return expression will be evaluated after the cleanup code. To be
|
|
|
|
// safe, set the debug location for cleanup code to the location of
|
|
|
|
// the return statement. Otherwise the cleanup code should be at the
|
|
|
|
// end of the function's lexical scope.
|
|
|
|
//
|
|
|
|
// If there are multiple branches to the return block, the branch
|
|
|
|
// instructions will get the location of the return statements and
|
|
|
|
// all will be fine.
|
2013-05-03 01:30:20 +08:00
|
|
|
if (CGDebugInfo *DI = getDebugInfo()) {
|
2013-05-04 04:11:48 +08:00
|
|
|
if (OnlySimpleReturnStmts)
|
2014-01-08 06:05:52 +08:00
|
|
|
DI->EmitLocation(Builder, LastStopPoint);
|
2013-05-03 01:30:20 +08:00
|
|
|
else
|
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.
|
|
|
|
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);
|
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()))
|
|
|
|
LargestVectorWidth = std::max(LargestVectorWidth,
|
|
|
|
VT->getPrimitiveSizeInBits());
|
|
|
|
|
|
|
|
// Update vector width based on return type.
|
|
|
|
if (auto *VT = dyn_cast<llvm::VectorType>(CurFn->getReturnType()))
|
|
|
|
LargestVectorWidth = std::max(LargestVectorWidth,
|
|
|
|
VT->getPrimitiveSizeInBits());
|
|
|
|
|
|
|
|
// 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));
|
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");
|
|
|
|
}
|
|
|
|
|
2016-09-06 18:10:28 +08:00
|
|
|
static void removeImageAccessQualifier(std::string& TyName) {
|
|
|
|
std::string ReadOnlyQual("__read_only");
|
|
|
|
std::string::size_type ReadOnlyPos = TyName.find(ReadOnlyQual);
|
|
|
|
if (ReadOnlyPos != std::string::npos)
|
|
|
|
// "+ 1" for the space after access qualifier.
|
|
|
|
TyName.erase(ReadOnlyPos, ReadOnlyQual.size() + 1);
|
|
|
|
else {
|
|
|
|
std::string WriteOnlyQual("__write_only");
|
|
|
|
std::string::size_type WriteOnlyPos = TyName.find(WriteOnlyQual);
|
|
|
|
if (WriteOnlyPos != std::string::npos)
|
|
|
|
TyName.erase(WriteOnlyPos, WriteOnlyQual.size() + 1);
|
|
|
|
else {
|
|
|
|
std::string ReadWriteQual("__read_write");
|
|
|
|
std::string::size_type ReadWritePos = TyName.find(ReadWriteQual);
|
|
|
|
if (ReadWritePos != std::string::npos)
|
|
|
|
TyName.erase(ReadWritePos, ReadWriteQual.size() + 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-14 21:08:30 +08:00
|
|
|
// Returns the address space id that should be produced to the
|
|
|
|
// kernel_arg_addr_space metadata. This is always fixed to the ids
|
|
|
|
// as specified in the SPIR 2.0 specification in order to differentiate
|
|
|
|
// for example in clGetKernelArgInfo() implementation between the address
|
|
|
|
// spaces with targets without unique mapping to the OpenCL address spaces
|
|
|
|
// (basically all single AS CPUs).
|
Convert clang::LangAS to a strongly typed enum
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
2017-10-16 02:48:14 +08:00
|
|
|
static unsigned ArgInfoAddressSpace(LangAS AS) {
|
|
|
|
switch (AS) {
|
2016-11-14 21:08:30 +08:00
|
|
|
case LangAS::opencl_global: return 1;
|
|
|
|
case LangAS::opencl_constant: return 2;
|
|
|
|
case LangAS::opencl_local: return 3;
|
|
|
|
case LangAS::opencl_generic: return 4; // Not in SPIR 2.0 specs.
|
|
|
|
default:
|
|
|
|
return 0; // Assume private.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// OpenCL v1.2 s5.6.4.6 allows the compiler to store kernel argument
|
|
|
|
// information in the program executable. The argument information stored
|
|
|
|
// includes the argument name, its type, the address and access qualifiers used.
|
|
|
|
static void GenOpenCLArgMetadata(const FunctionDecl *FD, llvm::Function *Fn,
|
2014-12-10 02:39:32 +08:00
|
|
|
CodeGenModule &CGM, llvm::LLVMContext &Context,
|
|
|
|
CGBuilderTy &Builder, ASTContext &ASTCtx) {
|
2013-03-24 21:58:12 +08:00
|
|
|
// Create MDNodes that represent the kernel arg metadata.
|
2012-07-12 07:02:10 +08:00
|
|
|
// Each MDNode is a list in the form of "key", N number of values which is
|
|
|
|
// the same number of values as their are kernel arguments.
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2014-04-04 21:43:57 +08:00
|
|
|
const PrintingPolicy &Policy = ASTCtx.getPrintingPolicy();
|
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// MDNode for the kernel argument address space qualifiers.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> addressQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// MDNode for the kernel argument access qualifiers (images only).
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> accessQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// MDNode for the kernel argument type names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argTypeNames;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
// MDNode for the kernel argument base type names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argBaseTypeNames;
|
2014-07-30 22:39:53 +08:00
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// MDNode for the kernel argument type qualifiers.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argTypeQuals;
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// MDNode for the kernel argument names.
|
2014-12-10 02:39:32 +08:00
|
|
|
SmallVector<llvm::Metadata *, 8> argNames;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
for (unsigned i = 0, e = FD->getNumParams(); i != e; ++i) {
|
|
|
|
const ParmVarDecl *parm = FD->getParamDecl(i);
|
2013-03-24 21:58:12 +08:00
|
|
|
QualType ty = parm->getType();
|
|
|
|
std::string typeQuals;
|
|
|
|
|
|
|
|
if (ty->isPointerType()) {
|
|
|
|
QualType pointeeTy = ty->getPointeeType();
|
|
|
|
|
|
|
|
// Get address qualifier.
|
2014-12-10 02:39:32 +08:00
|
|
|
addressQuals.push_back(llvm::ConstantAsMetadata::get(Builder.getInt32(
|
2016-11-14 21:08:30 +08:00
|
|
|
ArgInfoAddressSpace(pointeeTy.getAddressSpace()))));
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Get argument type name.
|
2014-04-04 21:43:57 +08:00
|
|
|
std::string typeName =
|
|
|
|
pointeeTy.getUnqualifiedType().getAsString(Policy) + "*";
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
std::string::size_type pos = typeName.find("unsigned");
|
2014-07-30 21:41:12 +08:00
|
|
|
if (pointeeTy.isCanonical() && pos != std::string::npos)
|
2013-03-25 00:04:55 +08:00
|
|
|
typeName.erase(pos+1, 8);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
argTypeNames.push_back(llvm::MDString::get(Context, typeName));
|
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
std::string baseTypeName =
|
|
|
|
pointeeTy.getUnqualifiedType().getCanonicalType().getAsString(
|
|
|
|
Policy) +
|
|
|
|
"*";
|
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
pos = baseTypeName.find("unsigned");
|
|
|
|
if (pos != std::string::npos)
|
|
|
|
baseTypeName.erase(pos+1, 8);
|
|
|
|
|
|
|
|
argBaseTypeNames.push_back(llvm::MDString::get(Context, baseTypeName));
|
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
// Get argument type qualifiers:
|
|
|
|
if (ty.isRestrictQualified())
|
|
|
|
typeQuals = "restrict";
|
|
|
|
if (pointeeTy.isConstQualified() ||
|
|
|
|
(pointeeTy.getAddressSpace() == LangAS::opencl_constant))
|
2013-03-25 00:04:55 +08:00
|
|
|
typeQuals += typeQuals.empty() ? "const" : " const";
|
2013-03-24 21:58:12 +08:00
|
|
|
if (pointeeTy.isVolatileQualified())
|
2013-03-25 00:04:55 +08:00
|
|
|
typeQuals += typeQuals.empty() ? "volatile" : " volatile";
|
2013-03-24 21:58:12 +08:00
|
|
|
} else {
|
2014-01-09 21:37:30 +08:00
|
|
|
uint32_t AddrSpc = 0;
|
2016-01-09 20:53:17 +08:00
|
|
|
bool isPipe = ty->isPipeType();
|
|
|
|
if (ty->isImageType() || isPipe)
|
2016-11-14 21:08:30 +08:00
|
|
|
AddrSpc = ArgInfoAddressSpace(LangAS::opencl_global);
|
2014-02-18 03:20:59 +08:00
|
|
|
|
2014-12-10 02:39:32 +08:00
|
|
|
addressQuals.push_back(
|
|
|
|
llvm::ConstantAsMetadata::get(Builder.getInt32(AddrSpc)));
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Get argument type name.
|
2016-01-09 20:53:17 +08:00
|
|
|
std::string typeName;
|
|
|
|
if (isPipe)
|
2016-07-13 18:28:13 +08:00
|
|
|
typeName = ty.getCanonicalType()->getAs<PipeType>()->getElementType()
|
|
|
|
.getAsString(Policy);
|
2016-01-09 20:53:17 +08:00
|
|
|
else
|
|
|
|
typeName = ty.getUnqualifiedType().getAsString(Policy);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
std::string::size_type pos = typeName.find("unsigned");
|
2014-07-30 21:41:12 +08:00
|
|
|
if (ty.isCanonical() && pos != std::string::npos)
|
2013-03-25 00:04:55 +08:00
|
|
|
typeName.erase(pos+1, 8);
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
std::string baseTypeName;
|
|
|
|
if (isPipe)
|
2016-07-13 18:28:13 +08:00
|
|
|
baseTypeName = ty.getCanonicalType()->getAs<PipeType>()
|
|
|
|
->getElementType().getCanonicalType()
|
|
|
|
.getAsString(Policy);
|
2016-01-09 20:53:17 +08:00
|
|
|
else
|
|
|
|
baseTypeName =
|
2014-07-30 22:39:53 +08:00
|
|
|
ty.getUnqualifiedType().getCanonicalType().getAsString(Policy);
|
|
|
|
|
2016-09-06 18:10:28 +08:00
|
|
|
// Remove access qualifiers on images
|
|
|
|
// (as they are inseparable from type in clang implementation,
|
|
|
|
// but OpenCL spec provides a special query to get access qualifier
|
|
|
|
// via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER):
|
|
|
|
if (ty->isImageType()) {
|
|
|
|
removeImageAccessQualifier(typeName);
|
|
|
|
removeImageAccessQualifier(baseTypeName);
|
|
|
|
}
|
|
|
|
|
|
|
|
argTypeNames.push_back(llvm::MDString::get(Context, typeName));
|
|
|
|
|
2014-07-30 22:39:53 +08:00
|
|
|
// Turn "unsigned type" to "utype"
|
|
|
|
pos = baseTypeName.find("unsigned");
|
|
|
|
if (pos != std::string::npos)
|
|
|
|
baseTypeName.erase(pos+1, 8);
|
|
|
|
|
|
|
|
argBaseTypeNames.push_back(llvm::MDString::get(Context, baseTypeName));
|
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
if (isPipe)
|
|
|
|
typeQuals = "pipe";
|
2013-03-24 21:58:12 +08:00
|
|
|
}
|
2013-11-22 18:20:40 +08:00
|
|
|
|
2013-03-24 21:58:12 +08:00
|
|
|
argTypeQuals.push_back(llvm::MDString::get(Context, typeQuals));
|
|
|
|
|
2016-01-09 20:53:17 +08:00
|
|
|
// Get image and pipe access qualifier:
|
|
|
|
if (ty->isImageType()|| ty->isPipeType()) {
|
2017-07-27 02:49:54 +08:00
|
|
|
const Decl *PDecl = parm;
|
|
|
|
if (auto *TD = dyn_cast<TypedefType>(ty))
|
|
|
|
PDecl = TD->getDecl();
|
|
|
|
const OpenCLAccessAttr *A = PDecl->getAttr<OpenCLAccessAttr>();
|
2014-01-15 01:41:53 +08:00
|
|
|
if (A && A->isWriteOnly())
|
2013-03-24 21:58:12 +08:00
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "write_only"));
|
2016-02-26 11:13:03 +08:00
|
|
|
else if (A && A->isReadWrite())
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "read_write"));
|
2013-03-24 21:58:12 +08:00
|
|
|
else
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "read_only"));
|
|
|
|
} else
|
|
|
|
accessQuals.push_back(llvm::MDString::get(Context, "none"));
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2012-07-12 07:02:10 +08:00
|
|
|
// Get argument name.
|
|
|
|
argNames.push_back(llvm::MDString::get(Context, parm->getName()));
|
|
|
|
}
|
2013-03-24 21:58:12 +08:00
|
|
|
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("kernel_arg_addr_space",
|
|
|
|
llvm::MDNode::get(Context, addressQuals));
|
|
|
|
Fn->setMetadata("kernel_arg_access_qual",
|
|
|
|
llvm::MDNode::get(Context, accessQuals));
|
|
|
|
Fn->setMetadata("kernel_arg_type",
|
|
|
|
llvm::MDNode::get(Context, argTypeNames));
|
|
|
|
Fn->setMetadata("kernel_arg_base_type",
|
|
|
|
llvm::MDNode::get(Context, argBaseTypeNames));
|
|
|
|
Fn->setMetadata("kernel_arg_type_qual",
|
|
|
|
llvm::MDNode::get(Context, argTypeQuals));
|
2014-12-04 13:30:58 +08:00
|
|
|
if (CGM.getCodeGenOpts().EmitOpenCLArgMetadata)
|
2016-06-22 22:56:35 +08:00
|
|
|
Fn->setMetadata("kernel_arg_name",
|
|
|
|
llvm::MDNode::get(Context, argNames));
|
2012-07-12 07:02:10 +08:00
|
|
|
}
|
|
|
|
|
2012-12-04 08:29:55 +08:00
|
|
|
void CodeGenFunction::EmitOpenCLKernelMetadata(const FunctionDecl *FD,
|
2012-07-10 06:06:01 +08:00
|
|
|
llvm::Function *Fn)
|
|
|
|
{
|
|
|
|
if (!FD->hasAttr<OpenCLKernelAttr>())
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::LLVMContext &Context = getLLVMContext();
|
|
|
|
|
2016-06-22 22:56:35 +08:00
|
|
|
GenOpenCLArgMetadata(FD, Fn, CGM, Context, Builder, getContext());
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2013-12-19 11:09:10 +08:00
|
|
|
if (const VecTypeHintAttr *A = FD->getAttr<VecTypeHintAttr>()) {
|
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
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2013-05-03 15:33:41 +08:00
|
|
|
void CodeGenFunction::StartFunction(GlobalDecl GD,
|
|
|
|
QualType RetTy,
|
2008-09-10 07:14:03 +08:00
|
|
|
llvm::Function *Fn,
|
2011-03-09 12:27:21 +08:00
|
|
|
const CGFunctionInfo &FnInfo,
|
2008-10-19 02:22:23 +08:00
|
|
|
const FunctionArgList &Args,
|
2014-04-11 07:21:53 +08:00
|
|
|
SourceLocation Loc,
|
2011-03-03 05:36:49 +08:00
|
|
|
SourceLocation StartLoc) {
|
2014-10-15 00:43:46 +08:00
|
|
|
assert(!CurFn &&
|
|
|
|
"Do not use a CodeGenFunction object for more than one function");
|
|
|
|
|
2009-09-11 08:07:24 +08:00
|
|
|
const Decl *D = GD.getDecl();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-02-10 04:20:56 +08:00
|
|
|
DidCallStackSave = false;
|
2013-05-03 15:33:41 +08:00
|
|
|
CurCodeDecl = D;
|
2016-03-02 03:42:53 +08:00
|
|
|
if (const auto *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if (FD->usesSEHTry())
|
|
|
|
CurSEHParent = FD;
|
2014-05-21 13:09:00 +08:00
|
|
|
CurFuncDecl = (D ? D->getNonClosureContext() : nullptr);
|
2008-09-10 07:14:03 +08:00
|
|
|
FnRetTy = RetTy;
|
2008-07-30 07:18:29 +08:00
|
|
|
CurFn = Fn;
|
2011-03-09 12:27:21 +08:00
|
|
|
CurFnInfo = &FnInfo;
|
2007-06-20 12:44:43 +08:00
|
|
|
assert(CurFn->isDeclaration() && "Function already has body?");
|
2008-03-03 11:28:21 +08:00
|
|
|
|
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);
|
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;
|
|
|
|
}
|
|
|
|
|
2016-07-14 06:32:15 +08:00
|
|
|
// Apply xray attributes to the function (as a string, for now)
|
2018-09-14 09:59:12 +08:00
|
|
|
if (D) {
|
2016-07-14 06:32:15 +08:00
|
|
|
if (const auto *XRayAttr = D->getAttr<XRayInstrumentAttr>()) {
|
2018-09-14 09:59:12 +08:00
|
|
|
if (CGM.getCodeGenOpts().XRayInstrumentationBundle.has(
|
|
|
|
XRayInstrKind::Function)) {
|
|
|
|
if (XRayAttr->alwaysXRayInstrument() && ShouldXRayInstrumentFunction())
|
|
|
|
Fn->addFnAttr("function-instrument", "xray-always");
|
|
|
|
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()));
|
2017-03-06 15:08:21 +08:00
|
|
|
}
|
2016-07-14 06:32:15 +08:00
|
|
|
} else {
|
2018-09-14 09:59:12 +08:00
|
|
|
if (ShouldXRayInstrumentFunction() && !CGM.imbueXRayAttrs(Fn, Loc))
|
2017-03-30 08:29:36 +08:00
|
|
|
Fn->addFnAttr(
|
|
|
|
"xray-instruction-threshold",
|
|
|
|
llvm::itostr(CGM.getCodeGenOpts().XRayInstructionThreshold));
|
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));
|
|
|
|
|
2017-08-25 05:37:33 +08:00
|
|
|
// Add profile-sample-accurate value.
|
|
|
|
if (CGM.getCodeGenOpts().ProfileSampleAccurate)
|
|
|
|
Fn->addFnAttr("profile-sample-accurate");
|
|
|
|
|
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").
|
|
|
|
if (getLangOpts().CPlusPlus)
|
|
|
|
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
|
|
|
|
if (FD->isMain())
|
|
|
|
Fn->addFnAttr(llvm::Attribute::NoRecurse);
|
2016-09-01 14:14:45 +08:00
|
|
|
|
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());
|
|
|
|
}
|
2017-06-20 02:45:03 +08:00
|
|
|
}
|
2017-02-01 01:00:35 +08:00
|
|
|
}
|
2011-02-11 00:52:03 +08:00
|
|
|
|
2009-12-04 10:43:40 +08:00
|
|
|
if (RetTy->isVoidType()) {
|
|
|
|
// Void type; nothing to return.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
ReturnValue = Address::invalid();
|
2014-04-29 09:07:59 +08:00
|
|
|
|
|
|
|
// Count the implicit return.
|
|
|
|
if (!endsWithReturn(D))
|
|
|
|
++NumReturnExprs;
|
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());
|
2014-02-01 08:04:45 +08:00
|
|
|
} else if (CurFnInfo->getReturnInfo().getKind() == ABIArgInfo::InAlloca &&
|
|
|
|
!hasScalarEvaluationKind(CurFnInfo->getReturnType())) {
|
|
|
|
// Load the sret pointer from the argument struct and return into that.
|
|
|
|
unsigned Idx = CurFnInfo->getReturnInfo().getInAllocaFieldIndex();
|
|
|
|
llvm::Function::arg_iterator EI = CurFn->arg_end();
|
|
|
|
--EI;
|
2015-11-07 07:00:41 +08:00
|
|
|
llvm::Value *Addr = Builder.CreateStructGEP(nullptr, &*EI, Idx);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Addr = Builder.CreateAlignedLoad(Addr, getPointerAlign(), "agg.result");
|
|
|
|
ReturnValue = Address(Addr, getNaturalTypeAlignment(RetTy));
|
2009-12-04 10:43:40 +08:00
|
|
|
} else {
|
2010-02-17 03:45:20 +08:00
|
|
|
ReturnValue = CreateIRTemp(RetTy, "retval");
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
// Tell the epilog emitter to autorelease the result. We do this
|
|
|
|
// now so that various specialized functions can suppress it
|
|
|
|
// during their IR-generation.
|
2012-03-11 15:00:24 +08:00
|
|
|
if (getLangOpts().ObjCAutoRefCount &&
|
2011-06-16 07:02:42 +08:00
|
|
|
!CurFnInfo->isReturnsRetained() &&
|
|
|
|
RetTy->isObjCRetainableType())
|
|
|
|
AutoreleaseResult = true;
|
2009-12-04 10:43:40 +08:00
|
|
|
}
|
|
|
|
|
2009-12-08 07:38:24 +08:00
|
|
|
EmitStartEHSpec(CurCodeDecl);
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
PrologueCleanupDepth = EHStack.stable_begin();
|
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.
|
|
|
|
CXXThisValue = ThisFieldLValue.getAddress().getPointer();
|
|
|
|
} else {
|
|
|
|
// Load the lvalue pointed to by the field, since '*this' was captured
|
|
|
|
// by reference.
|
|
|
|
CXXThisValue =
|
|
|
|
EmitLoadOfLValue(ThisFieldLValue, SourceLocation()).getScalarVal();
|
|
|
|
}
|
2012-02-11 10:57:39 +08:00
|
|
|
}
|
2014-08-28 12:28:19 +08:00
|
|
|
for (auto *FD : MD->getParent()->fields()) {
|
|
|
|
if (FD->hasCapturedVLAType()) {
|
|
|
|
auto *ExprArg = EmitLoadOfLValue(EmitLValueForLambdaField(FD),
|
|
|
|
SourceLocation()).getScalarVal();
|
|
|
|
auto VAT = FD->getCapturedVLAType();
|
|
|
|
VLASizeMap[VAT->getSizeExpr()] = ExprArg;
|
|
|
|
}
|
|
|
|
}
|
2012-02-11 10:57:39 +08:00
|
|
|
} else {
|
|
|
|
// Not in a lambda; just use 'this' from the method.
|
|
|
|
// FIXME: Should we generate a new load for each use of 'this'? The
|
|
|
|
// fast register allocator would be happier...
|
|
|
|
CXXThisValue = CXXABIThisValue;
|
|
|
|
}
|
Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
I also compiled X86FastISel.cpp with -fsanitize=null using
patched/unpatched clangs based on r293572. Here are the number of null
checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit:
- Don't introduce any unintentional object-size or alignment checks.
- Don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295515
2017-02-18 07:22:59 +08:00
|
|
|
|
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);
|
2017-04-15 06:03:34 +08:00
|
|
|
QualType ThisTy = MD->getThisType(getContext());
|
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
|
|
|
|
2013-11-05 17:12:18 +08:00
|
|
|
void CodeGenFunction::EmitFunctionBody(FunctionArgList &Args,
|
|
|
|
const Stmt *Body) {
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(Body);
|
2013-11-05 17:12:18 +08:00
|
|
|
if (const CompoundStmt *S = dyn_cast<CompoundStmt>(Body))
|
2013-01-27 06:16:26 +08:00
|
|
|
EmitCompoundStmtWithoutScope(*S);
|
|
|
|
else
|
2013-11-05 17:12:18 +08:00
|
|
|
EmitStmt(Body);
|
2010-02-18 11:17:58 +08:00
|
|
|
}
|
|
|
|
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
/// When instrumenting to collect profile data, the counts for some blocks
|
|
|
|
/// such as switch cases need to not include the fall-through counts, so
|
|
|
|
/// emit a branch around the instrumentation code. When not instrumenting,
|
|
|
|
/// this just calls EmitBlock().
|
|
|
|
void CodeGenFunction::EmitBlockWithFallThrough(llvm::BasicBlock *BB,
|
2015-04-24 07:06:47 +08:00
|
|
|
const Stmt *S) {
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::BasicBlock *SkipCountBB = nullptr;
|
2016-02-05 02:39:09 +08:00
|
|
|
if (HaveInsertPoint() && CGM.getCodeGenOpts().hasProfileClangInstr()) {
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
// When instrumenting for profiling, the fallthrough to certain
|
|
|
|
// statements needs to skip over the instrumentation code so that we
|
|
|
|
// get an accurate count.
|
|
|
|
SkipCountBB = createBasicBlock("skipcount");
|
|
|
|
EmitBranch(SkipCountBB);
|
|
|
|
}
|
|
|
|
EmitBlock(BB);
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t CurrentCount = getCurrentProfileCount();
|
|
|
|
incrementProfileCounter(S);
|
|
|
|
setCurrentProfileCount(getCurrentProfileCount() + CurrentCount);
|
Change PGO instrumentation to compute counts in a separate AST traversal.
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
llvm-svn: 201528
2014-02-18 03:21:09 +08:00
|
|
|
if (SkipCountBB)
|
|
|
|
EmitBlock(SkipCountBB);
|
|
|
|
}
|
|
|
|
|
2010-08-04 06:46:07 +08:00
|
|
|
/// Tries to mark the given function nounwind based on the
|
|
|
|
/// non-existence of any throwing calls within it. We believe this is
|
|
|
|
/// lightweight enough to do at -O0.
|
|
|
|
static void TryMarkNoThrow(llvm::Function *F) {
|
2010-08-12 06:38:33 +08:00
|
|
|
// LLVM treats 'nounwind' on a function as part of the type, so we
|
|
|
|
// can't do this on functions that can be overwritten.
|
2016-04-08 09:31:02 +08:00
|
|
|
if (F->isInterposable()) return;
|
2010-08-12 06:38:33 +08:00
|
|
|
|
2015-08-01 01:58:45 +08:00
|
|
|
for (llvm::BasicBlock &BB : *F)
|
|
|
|
for (llvm::Instruction &I : BB)
|
|
|
|
if (I.mayThrow())
|
2011-09-20 04:31:14 +08:00
|
|
|
return;
|
2015-08-01 01:58:45 +08:00
|
|
|
|
2012-10-10 11:13:20 +08:00
|
|
|
F->setDoesNotThrow();
|
2010-08-04 06:46:07 +08:00
|
|
|
}
|
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
QualType CodeGenFunction::BuildFunctionArgList(GlobalDecl GD,
|
|
|
|
FunctionArgList &Args) {
|
2009-09-11 08:07:24 +08:00
|
|
|
const FunctionDecl *FD = cast<FunctionDecl>(GD.getDecl());
|
2014-01-26 00:55:45 +08:00
|
|
|
QualType ResTy = FD->getReturnType();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-12-18 03:46:40 +08:00
|
|
|
const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(FD);
|
|
|
|
if (MD && MD->isInstance()) {
|
2013-07-01 04:40:16 +08:00
|
|
|
if (CGM.getCXXABI().HasThisReturn(GD))
|
|
|
|
ResTy = MD->getThisType(getContext());
|
2014-11-01 04:09:12 +08:00
|
|
|
else if (CGM.getCXXABI().hasMostDerivedReturn(GD))
|
|
|
|
ResTy = CGM.getContext().VoidPtrTy;
|
2013-12-18 03:46:40 +08:00
|
|
|
CGM.getCXXABI().buildThisParam(*this, Args);
|
2013-07-01 04:40:16 +08:00
|
|
|
}
|
2015-04-24 07:06:47 +08:00
|
|
|
|
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
2016-06-29 03:03:57 +08:00
|
|
|
// The base version of an inheriting constructor whose constructed base is a
|
|
|
|
// virtual base is not passed any arguments (because it doesn't actually call
|
|
|
|
// the inherited constructor).
|
|
|
|
bool PassedParams = true;
|
|
|
|
if (const CXXConstructorDecl *CD = dyn_cast<CXXConstructorDecl>(FD))
|
|
|
|
if (auto Inherited = CD->getInheritedConstructor())
|
|
|
|
PassedParams =
|
|
|
|
getTypes().inheritingCtorHasParams(Inherited, GD.getCtorType());
|
|
|
|
|
|
|
|
if (PassedParams) {
|
|
|
|
for (auto *Param : FD->parameters()) {
|
|
|
|
Args.push_back(Param);
|
|
|
|
if (!Param->hasAttr<PassObjectSizeAttr>())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
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) {
|
2013-11-05 17:12:18 +08:00
|
|
|
EmitFunctionBody(Args, Body);
|
|
|
|
} else
|
|
|
|
llvm_unreachable("no definition for emitted function");
|
2009-10-07 02:09:57 +08:00
|
|
|
|
2012-10-05 07:52:29 +08:00
|
|
|
// C++11 [stmt.return]p2:
|
|
|
|
// Flowing off the end of a function [...] results in undefined behavior in
|
|
|
|
// a value-returning function.
|
|
|
|
// C11 6.9.1p12:
|
|
|
|
// If the '}' that terminates a function is reached, and the value of the
|
|
|
|
// function call is used by the caller, the behavior is undefined.
|
2014-09-05 04:04:38 +08:00
|
|
|
if (getLangOpts().CPlusPlus && !FD->hasImplicitReturnZero() && !SawAsmBlock &&
|
2014-01-26 00:55:45 +08:00
|
|
|
!FD->getReturnType()->isVoidType() && Builder.GetInsertBlock()) {
|
2017-01-04 21:40:34 +08:00
|
|
|
bool ShouldEmitUnreachable =
|
|
|
|
CGM.getCodeGenOpts().StrictReturn ||
|
|
|
|
shouldUseUndefinedBehaviorReturnOptimization(FD, getContext());
|
2014-11-08 06:29:38 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::Return)) {
|
2014-07-18 02:46:27 +08:00
|
|
|
SanitizerScope SanScope(this);
|
2014-11-12 06:03:54 +08:00
|
|
|
llvm::Value *IsFalse = Builder.getFalse();
|
|
|
|
EmitCheck(std::make_pair(IsFalse, SanitizerKind::Return),
|
2016-12-13 00:18:40 +08:00
|
|
|
SanitizerHandler::MissingReturn,
|
|
|
|
EmitCheckSourceLocation(FD->getLocation()), None);
|
2017-01-04 21:40:34 +08:00
|
|
|
} else if (ShouldEmitUnreachable) {
|
|
|
|
if (CGM.getCodeGenOpts().OptimizationLevel == 0)
|
|
|
|
EmitTrapCall(llvm::Intrinsic::trap);
|
|
|
|
}
|
|
|
|
if (SanOpts.has(SanitizerKind::Return) || ShouldEmitUnreachable) {
|
|
|
|
Builder.CreateUnreachable();
|
|
|
|
Builder.ClearInsertionPoint();
|
2015-07-03 06:15:41 +08:00
|
|
|
}
|
2012-10-05 07:52:29 +08:00
|
|
|
}
|
|
|
|
|
2010-02-18 11:17:58 +08:00
|
|
|
// Emit the standard function epilogue.
|
|
|
|
FinishFunction(BodyRange.getEnd());
|
2010-08-04 06:46:07 +08:00
|
|
|
|
|
|
|
// If we haven't marked the function nothrow through other means, do
|
|
|
|
// a quick pass now to see if we can.
|
|
|
|
if (!CurFn->doesNotThrow())
|
|
|
|
TryMarkNoThrow(CurFn);
|
2007-05-30 07:50:05 +08:00
|
|
|
}
|
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
/// ContainsLabel - Return true if the statement contains a label in it. If
|
|
|
|
/// this statement is not executed normally, it not containing a label means
|
|
|
|
/// that we can just remove the code.
|
|
|
|
bool CodeGenFunction::ContainsLabel(const Stmt *S, bool IgnoreCaseStmts) {
|
|
|
|
// Null statement, not a label!
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!S) return false;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a label, we have to emit the code, consider something like:
|
|
|
|
// if (0) { ... foo: bar(); } goto foo;
|
2011-02-28 08:18:40 +08:00
|
|
|
//
|
|
|
|
// TODO: If anyone cared, we could track __label__'s, since we know that you
|
|
|
|
// can't jump to one from outside their declared region.
|
2008-11-11 15:41:27 +08:00
|
|
|
if (isa<LabelStmt>(S))
|
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a case/default statement, and we haven't seen a switch, we have
|
|
|
|
// to emit the code.
|
|
|
|
if (isa<SwitchCase>(S) && !IgnoreCaseStmts)
|
|
|
|
return true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// If this is a switch statement, we want to ignore cases below it.
|
|
|
|
if (isa<SwitchStmt>(S))
|
|
|
|
IgnoreCaseStmts = true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
// Scan subexpressions for verboten labels.
|
2015-07-03 05:03:14 +08:00
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (ContainsLabel(SubStmt, IgnoreCaseStmts))
|
2008-11-11 15:41:27 +08:00
|
|
|
return true;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-11 15:41:27 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
/// containsBreak - Return true if the statement contains a break out of it.
|
|
|
|
/// If the statement (recursively) contains a switch or loop with a break
|
|
|
|
/// inside of it, this is fine.
|
|
|
|
bool CodeGenFunction::containsBreak(const Stmt *S) {
|
|
|
|
// Null statement, not a label!
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!S) return false;
|
2011-02-28 08:18:40 +08:00
|
|
|
|
|
|
|
// If this is a switch or loop that defines its own break scope, then we can
|
|
|
|
// include it and anything inside of it.
|
|
|
|
if (isa<SwitchStmt>(S) || isa<WhileStmt>(S) || isa<DoStmt>(S) ||
|
|
|
|
isa<ForStmt>(S))
|
2011-02-28 08:42:31 +08:00
|
|
|
return false;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:42:31 +08:00
|
|
|
if (isa<BreakStmt>(S))
|
2011-02-28 08:18:40 +08:00
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
// Scan subexpressions for verboten breaks.
|
2015-07-03 05:03:14 +08:00
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (containsBreak(SubStmt))
|
2011-02-28 08:18:40 +08:00
|
|
|
return true;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-09-17 07:30:39 +08:00
|
|
|
bool CodeGenFunction::mightAddDeclToScope(const Stmt *S) {
|
|
|
|
if (!S) return false;
|
|
|
|
|
|
|
|
// Some statement kinds add a scope and thus never add a decl to the current
|
|
|
|
// scope. Note, this list is longer than the list of statements that might
|
|
|
|
// have an unscoped decl nested within them, but this way is conservatively
|
|
|
|
// correct even if more statement kinds are added.
|
|
|
|
if (isa<IfStmt>(S) || isa<SwitchStmt>(S) || isa<WhileStmt>(S) ||
|
|
|
|
isa<DoStmt>(S) || isa<ForStmt>(S) || isa<CompoundStmt>(S) ||
|
|
|
|
isa<CXXForRangeStmt>(S) || isa<CXXTryStmt>(S) ||
|
|
|
|
isa<ObjCForCollectionStmt>(S) || isa<ObjCAtTryStmt>(S))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (isa<DeclStmt>(S))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (const Stmt *SubStmt : S->children())
|
|
|
|
if (mightAddDeclToScope(SubStmt))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2008-11-12 16:04:58 +08:00
|
|
|
|
2011-02-28 07:02:32 +08:00
|
|
|
/// ConstantFoldsToSimpleInteger - If the specified expression does not fold
|
|
|
|
/// to a constant, or if it does but contains a label, return false. If it
|
|
|
|
/// constant folds return true and set the boolean result in Result.
|
|
|
|
bool CodeGenFunction::ConstantFoldsToSimpleInteger(const Expr *Cond,
|
2016-06-24 03:16:49 +08:00
|
|
|
bool &ResultBool,
|
|
|
|
bool AllowLabels) {
|
2012-07-24 04:21:35 +08:00
|
|
|
llvm::APSInt ResultInt;
|
2016-06-24 03:16:49 +08:00
|
|
|
if (!ConstantFoldsToSimpleInteger(Cond, ResultInt, AllowLabels))
|
2011-02-28 08:18:40 +08:00
|
|
|
return false;
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
ResultBool = ResultInt.getBoolValue();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ConstantFoldsToSimpleInteger - If the specified expression does not fold
|
|
|
|
/// to a constant, or if it does but contains a label, return false. If it
|
|
|
|
/// constant folds return true and set the folded value.
|
2016-06-24 03:16:49 +08:00
|
|
|
bool CodeGenFunction::ConstantFoldsToSimpleInteger(const Expr *Cond,
|
|
|
|
llvm::APSInt &ResultInt,
|
|
|
|
bool AllowLabels) {
|
2008-11-13 06:37:10 +08:00
|
|
|
// FIXME: Rename and handle conversion of other evaluatable things
|
|
|
|
// to bool.
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-02-28 08:18:40 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
/// EmitBranchOnBoolExpr - Emit a branch on a boolean condition (e.g. for an if
|
|
|
|
/// statement) to the specified blocks. Based on the condition, this might try
|
|
|
|
/// to simplify the codegen of the conditional based on the branch.
|
|
|
|
///
|
|
|
|
void CodeGenFunction::EmitBranchOnBoolExpr(const Expr *Cond,
|
|
|
|
llvm::BasicBlock *TrueBlock,
|
2014-01-07 06:27:43 +08:00
|
|
|
llvm::BasicBlock *FalseBlock,
|
|
|
|
uint64_t TrueCount) {
|
2011-04-15 08:35:48 +08:00
|
|
|
Cond = Cond->IgnoreParens();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
if (const BinaryOperator *CondBOp = dyn_cast<BinaryOperator>(Cond)) {
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Handle X && Y in a condition.
|
2010-08-25 19:45:40 +08:00
|
|
|
if (CondBOp->getOpcode() == BO_LAnd) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "1 && X", simplify the code. "0 && X" would have constant
|
|
|
|
// folded if the case was simple enough.
|
2011-03-05 05:46:03 +08:00
|
|
|
bool ConstantBool = false;
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getLHS(), ConstantBool) &&
|
|
|
|
ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(1 && X) -> br(X).
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "X && 1", simplify the code to use an uncond branch.
|
|
|
|
// "X && 0" would have been constant folded to 0.
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getRHS(), ConstantBool) &&
|
|
|
|
ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(X && 1) -> br(X).
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the LHS as a conditional. If the LHS conditional is false, we
|
|
|
|
// want to jump to the FalseBlock.
|
2008-11-13 09:38:36 +08:00
|
|
|
llvm::BasicBlock *LHSTrue = createBasicBlock("land.lhs.true");
|
2014-01-07 06:27:43 +08:00
|
|
|
// The counter tells us how often we evaluate RHS, and all of TrueCount
|
|
|
|
// can be propagated to that branch.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t RHSCount = getProfileCount(CondBOp->getRHS());
|
2011-01-26 12:00:11 +08:00
|
|
|
|
|
|
|
ConditionalEvaluation eval(*this);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), LHSTrue, FalseBlock, RHSCount);
|
|
|
|
EmitBlock(LHSTrue);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
|
|
|
setCurrentProfileCount(getProfileCount(CondBOp->getRHS()));
|
|
|
|
|
2010-01-24 08:20:05 +08:00
|
|
|
// Any temporaries created here are conditional.
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.begin(*this);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, TrueCount);
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.end(*this);
|
2010-01-24 08:20:05 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
return;
|
2011-02-28 07:02:32 +08:00
|
|
|
}
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2011-02-28 07:02:32 +08:00
|
|
|
if (CondBOp->getOpcode() == BO_LOr) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "0 || X", simplify the code. "1 || X" would have constant
|
|
|
|
// folded if the case was simple enough.
|
2011-03-05 05:46:03 +08:00
|
|
|
bool ConstantBool = false;
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getLHS(), ConstantBool) &&
|
|
|
|
!ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(0 || X) -> br(X).
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// If we have "X || 0", simplify the code to use an uncond branch.
|
|
|
|
// "X || 1" would have been constant folded to 1.
|
2011-02-28 07:02:32 +08:00
|
|
|
if (ConstantFoldsToSimpleInteger(CondBOp->getRHS(), ConstantBool) &&
|
|
|
|
!ConstantBool) {
|
2008-11-12 16:04:58 +08:00
|
|
|
// br(X || 0) -> br(X).
|
2014-01-07 06:27:43 +08:00
|
|
|
return EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the LHS as a conditional. If the LHS conditional is true, we
|
|
|
|
// want to jump to the TrueBlock.
|
2008-11-13 09:38:36 +08:00
|
|
|
llvm::BasicBlock *LHSFalse = createBasicBlock("lor.lhs.false");
|
2014-01-07 06:27:43 +08:00
|
|
|
// We have the count for entry to the RHS and for the whole expression
|
|
|
|
// being true, so we can divy up True count between the short circuit and
|
|
|
|
// the RHS.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t LHSCount =
|
|
|
|
getCurrentProfileCount() - getProfileCount(CondBOp->getRHS());
|
2014-01-07 06:27:43 +08:00
|
|
|
uint64_t RHSCount = TrueCount - LHSCount;
|
2011-01-26 12:00:11 +08:00
|
|
|
|
|
|
|
ConditionalEvaluation eval(*this);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondBOp->getLHS(), TrueBlock, LHSFalse, LHSCount);
|
|
|
|
EmitBlock(LHSFalse);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondBOp);
|
|
|
|
setCurrentProfileCount(getProfileCount(CondBOp->getRHS()));
|
|
|
|
|
2010-01-24 08:20:05 +08:00
|
|
|
// Any temporaries created here are conditional.
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.begin(*this);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondBOp->getRHS(), TrueBlock, FalseBlock, RHSCount);
|
|
|
|
|
2011-01-26 12:00:11 +08:00
|
|
|
eval.end(*this);
|
2010-01-24 08:20:05 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
return;
|
|
|
|
}
|
2008-11-12 16:13:36 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 16:13:36 +08:00
|
|
|
if (const UnaryOperator *CondUOp = dyn_cast<UnaryOperator>(Cond)) {
|
|
|
|
// br(!x, t, f) -> br(x, f, t)
|
2014-01-07 06:27:43 +08:00
|
|
|
if (CondUOp->getOpcode() == UO_LNot) {
|
|
|
|
// Negate the count.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t FalseCount = getCurrentProfileCount() - TrueCount;
|
2014-01-07 06:27:43 +08:00
|
|
|
// Negate the condition and swap the destination blocks.
|
|
|
|
return EmitBranchOnBoolExpr(CondUOp->getSubExpr(), FalseBlock, TrueBlock,
|
|
|
|
FalseCount);
|
|
|
|
}
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-11-12 18:30:32 +08:00
|
|
|
if (const ConditionalOperator *CondOp = dyn_cast<ConditionalOperator>(Cond)) {
|
2012-02-14 11:54:45 +08:00
|
|
|
// br(c ? x : y, t, f) -> br(c, br(x, t, f), br(y, t, f))
|
|
|
|
llvm::BasicBlock *LHSBlock = createBasicBlock("cond.true");
|
|
|
|
llvm::BasicBlock *RHSBlock = createBasicBlock("cond.false");
|
2008-11-12 18:30:32 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
ConditionalEvaluation cond(*this);
|
2015-04-24 07:06:47 +08:00
|
|
|
EmitBranchOnBoolExpr(CondOp->getCond(), LHSBlock, RHSBlock,
|
|
|
|
getProfileCount(CondOp));
|
2014-01-07 06:27:43 +08:00
|
|
|
|
|
|
|
// When computing PGO branch weights, we only know the overall count for
|
|
|
|
// the true block. This code is essentially doing tail duplication of the
|
|
|
|
// naive code-gen, introducing new edges for which counts are not
|
|
|
|
// available. Divide the counts proportionally between the LHS and RHS of
|
|
|
|
// the conditional operator.
|
|
|
|
uint64_t LHSScaledTrueCount = 0;
|
|
|
|
if (TrueCount) {
|
2015-04-24 07:06:47 +08:00
|
|
|
double LHSRatio =
|
|
|
|
getProfileCount(CondOp) / (double)getCurrentProfileCount();
|
2014-01-07 06:27:43 +08:00
|
|
|
LHSScaledTrueCount = TrueCount * LHSRatio;
|
|
|
|
}
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.begin(*this);
|
|
|
|
EmitBlock(LHSBlock);
|
2015-04-24 07:06:47 +08:00
|
|
|
incrementProfileCounter(CondOp);
|
2015-01-29 03:50:09 +08:00
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
EmitBranchOnBoolExpr(CondOp->getLHS(), TrueBlock, FalseBlock,
|
|
|
|
LHSScaledTrueCount);
|
|
|
|
}
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.end(*this);
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.begin(*this);
|
|
|
|
EmitBlock(RHSBlock);
|
2014-01-07 06:27:43 +08:00
|
|
|
EmitBranchOnBoolExpr(CondOp->getRHS(), TrueBlock, FalseBlock,
|
|
|
|
TrueCount - LHSScaledTrueCount);
|
2012-02-14 11:54:45 +08:00
|
|
|
cond.end(*this);
|
2011-01-26 12:00:11 +08:00
|
|
|
|
2012-02-14 11:54:45 +08:00
|
|
|
return;
|
2008-11-12 18:30:32 +08:00
|
|
|
}
|
|
|
|
|
2013-05-08 05:53:22 +08:00
|
|
|
if (const CXXThrowExpr *Throw = dyn_cast<CXXThrowExpr>(Cond)) {
|
|
|
|
// Conditional operator handling can give us a throw expression as a
|
|
|
|
// condition for a case like:
|
|
|
|
// br(c ? throw x : y, t, f) -> br(c, br(throw x, t, f), br(y, t, f)
|
|
|
|
// Fold this to:
|
|
|
|
// br(c, throw x, br(y, t, f))
|
|
|
|
EmitCXXThrowExpr(Throw, /*KeepInsertionPoint*/false);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-03 04:01:30 +08:00
|
|
|
// If the branch has a condition wrapped by __builtin_unpredictable,
|
|
|
|
// create metadata that specifies that the branch is unpredictable.
|
|
|
|
// Don't bother if not optimizing because that metadata would not be used.
|
|
|
|
llvm::MDNode *Unpredictable = nullptr;
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-07 06:27:43 +08:00
|
|
|
// Create branch weights based on the number of times we get here and the
|
|
|
|
// number of times the condition should be true.
|
2015-04-24 07:06:47 +08:00
|
|
|
uint64_t CurrentCount = std::max(getCurrentProfileCount(), TrueCount);
|
2015-05-02 13:00:55 +08:00
|
|
|
llvm::MDNode *Weights =
|
|
|
|
createProfileWeights(TrueCount, CurrentCount - TrueCount);
|
2014-01-07 06:27:43 +08:00
|
|
|
|
2008-11-12 16:04:58 +08:00
|
|
|
// Emit the code with the fully general case.
|
2015-01-31 09:10:11 +08:00
|
|
|
llvm::Value *CondV;
|
|
|
|
{
|
|
|
|
ApplyDebugLocation DL(*this, Cond);
|
|
|
|
CondV = EvaluateExprAsBool(Cond);
|
|
|
|
}
|
2015-09-03 04:01:30 +08:00
|
|
|
Builder.CreateCondBr(CondV, TrueBlock, FalseBlock, Weights, Unpredictable);
|
2008-11-12 16:04:58 +08:00
|
|
|
}
|
|
|
|
|
2008-08-16 08:56:44 +08:00
|
|
|
/// ErrorUnsupported - Print out an error that codegen doesn't support the
|
2007-12-02 09:43:38 +08:00
|
|
|
/// specified stmt yet.
|
2013-08-20 05:02:26 +08:00
|
|
|
void CodeGenFunction::ErrorUnsupported(const Stmt *S, const char *Type) {
|
|
|
|
CGM.ErrorUnsupported(S, Type);
|
2007-12-02 09:43:38 +08:00
|
|
|
}
|
|
|
|
|
2011-02-02 05:35:06 +08:00
|
|
|
/// emitNonZeroVLAInit - Emit the "zero" initialization of a
|
|
|
|
/// variable-length array whose elements have a non-zero bit-pattern.
|
|
|
|
///
|
2012-06-16 06:10:14 +08:00
|
|
|
/// \param baseType the inner-most element type of the array
|
2011-02-02 05:35:06 +08:00
|
|
|
/// \param src - a char* pointing to the bit-pattern for a single
|
|
|
|
/// base element of the array
|
|
|
|
/// \param sizeInChars - the total size of the VLA, in chars
|
|
|
|
static void emitNonZeroVLAInit(CodeGenFunction &CGF, QualType baseType,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address dest, Address src,
|
2011-02-02 05:35:06 +08:00
|
|
|
llvm::Value *sizeInChars) {
|
|
|
|
CGBuilderTy &Builder = CGF.Builder;
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CharUnits baseSize = CGF.getContext().getTypeSizeInChars(baseType);
|
2011-02-02 05:35:06 +08:00
|
|
|
llvm::Value *baseSizeInChars
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
= llvm::ConstantInt::get(CGF.IntPtrTy, baseSize.getQuantity());
|
2011-02-02 05:35:06 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address begin =
|
|
|
|
Builder.CreateElementBitCast(dest, CGF.Int8Ty, "vla.begin");
|
|
|
|
llvm::Value *end =
|
|
|
|
Builder.CreateInBoundsGEP(begin.getPointer(), sizeInChars, "vla.end");
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
llvm::BasicBlock *originBB = CGF.Builder.GetInsertBlock();
|
|
|
|
llvm::BasicBlock *loopBB = CGF.createBasicBlock("vla-init.loop");
|
|
|
|
llvm::BasicBlock *contBB = CGF.createBasicBlock("vla-init.cont");
|
|
|
|
|
|
|
|
// Make a loop over the VLA. C99 guarantees that the VLA element
|
|
|
|
// count must be nonzero.
|
|
|
|
CGF.EmitBlock(loopBB);
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::PHINode *cur = Builder.CreatePHI(begin.getType(), 2, "vla.cur");
|
|
|
|
cur->addIncoming(begin.getPointer(), originBB);
|
|
|
|
|
|
|
|
CharUnits curAlign =
|
|
|
|
dest.getAlignment().alignmentOfArrayElement(baseSize);
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
// memcpy the individual element bit-pattern.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemCpy(Address(cur, curAlign), src, baseSizeInChars,
|
2011-02-02 05:35:06 +08:00
|
|
|
/*volatile*/ false);
|
|
|
|
|
|
|
|
// Go to the next element.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *next =
|
|
|
|
Builder.CreateInBoundsGEP(CGF.Int8Ty, cur, baseSizeInChars, "vla.next");
|
2011-02-02 05:35:06 +08:00
|
|
|
|
|
|
|
// Leave if that's the end of the VLA.
|
|
|
|
llvm::Value *done = Builder.CreateICmpEQ(next, end, "vla-init.isdone");
|
|
|
|
Builder.CreateCondBr(done, contBB, loopBB);
|
|
|
|
cur->addIncoming(next, loopBB);
|
|
|
|
|
|
|
|
CGF.EmitBlock(contBB);
|
2012-12-04 08:29:55 +08:00
|
|
|
}
|
2011-02-02 05:35:06 +08:00
|
|
|
|
2010-05-23 01:35:42 +08:00
|
|
|
void
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CodeGenFunction::EmitNullInitialization(Address DestPtr, QualType Ty) {
|
2010-05-03 09:20:20 +08:00
|
|
|
// Ignore empty classes in C++.
|
2012-11-02 06:30:59 +08:00
|
|
|
if (getLangOpts().CPlusPlus) {
|
2010-05-03 09:20:20 +08:00
|
|
|
if (const RecordType *RT = Ty->getAs<RecordType>()) {
|
|
|
|
if (cast<CXXRecordDecl>(RT->getDecl())->isEmpty())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2010-08-07 16:21:30 +08:00
|
|
|
|
|
|
|
// Cast the dest ptr to the appropriate i8 pointer type.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
if (DestPtr.getElementType() != Int8Ty)
|
|
|
|
DestPtr = Builder.CreateElementBitCast(DestPtr, Int8Ty);
|
2008-08-31 03:51:14 +08:00
|
|
|
|
|
|
|
// Get size and alignment info for this aggregate.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CharUnits size = getContext().getTypeSizeInChars(Ty);
|
2008-08-31 03:51:14 +08:00
|
|
|
|
2011-01-14 18:37:58 +08:00
|
|
|
llvm::Value *SizeVal;
|
2011-02-02 05:35:06 +08:00
|
|
|
const VariableArrayType *vla;
|
2010-08-07 16:21:30 +08:00
|
|
|
|
2011-01-14 18:37:58 +08:00
|
|
|
// Don't bother emitting a zero-byte memset.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
if (size.isZero()) {
|
2011-01-14 18:37:58 +08:00
|
|
|
// But note that getTypeInfo returns 0 for a VLA.
|
|
|
|
if (const VariableArrayType *vlaType =
|
|
|
|
dyn_cast_or_null<VariableArrayType>(
|
|
|
|
getContext().getAsArrayType(Ty))) {
|
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();
|
|
|
|
NullVariable->setAlignment(NullAlign.getQuantity());
|
|
|
|
Address SrcPtr(Builder.CreateBitCast(NullVariable, Builder.getInt8PtrTy()),
|
|
|
|
NullAlign);
|
2010-08-07 16:21:30 +08:00
|
|
|
|
2011-02-02 05:35:06 +08:00
|
|
|
if (vla) return emitNonZeroVLAInit(*this, Ty, DestPtr, SrcPtr, SizeVal);
|
|
|
|
|
2010-08-07 16:21:30 +08:00
|
|
|
// Get and call the appropriate llvm.memcpy overload.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemCpy(DestPtr, SrcPtr, SizeVal, false);
|
2009-04-22 01:59:23 +08:00
|
|
|
return;
|
2012-12-04 08:29:55 +08:00
|
|
|
}
|
|
|
|
|
2010-08-07 16:21:30 +08:00
|
|
|
// Otherwise, just memset the whole thing to zero. This is legal
|
|
|
|
// because in LLVM, all default initializers (other than the ones we just
|
|
|
|
// handled above) are guaranteed to have a bit pattern of all zeros.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Builder.CreateMemSet(DestPtr, Builder.getInt8(0), SizeVal, false);
|
2008-08-31 03:51:14 +08:00
|
|
|
}
|
|
|
|
|
2011-02-17 15:39:24 +08:00
|
|
|
llvm::BlockAddress *CodeGenFunction::GetAddrOfLabel(const LabelDecl *L) {
|
2009-10-29 07:59:40 +08:00
|
|
|
// Make sure that there is a block for the indirect goto.
|
2014-05-21 13:09:00 +08:00
|
|
|
if (!IndirectBranch)
|
2009-10-29 07:59:40 +08:00
|
|
|
GetIndirectGotoBlock();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2010-07-24 05:56:41 +08:00
|
|
|
llvm::BasicBlock *BB = getJumpDestForLabel(L).getBlock();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// Make sure the indirect branch includes all of the address-taken blocks.
|
|
|
|
IndirectBranch->addDestination(BB);
|
|
|
|
return llvm::BlockAddress::get(CurFn, BB);
|
2009-10-13 14:55:33 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-10-13 14:55:33 +08:00
|
|
|
llvm::BasicBlock *CodeGenFunction::GetIndirectGotoBlock() {
|
2009-10-29 07:59:40 +08:00
|
|
|
// If we already made the indirect branch for indirect goto, return its block.
|
|
|
|
if (IndirectBranch) return IndirectBranch->getParent();
|
2012-12-04 08:29:55 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
CGBuilderTy TmpBuilder(*this, createBasicBlock("indirectgoto"));
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-13 14:55:33 +08:00
|
|
|
// Create the PHI node that indirect gotos will add entries to.
|
2011-03-30 19:28:58 +08:00
|
|
|
llvm::Value *DestVal = TmpBuilder.CreatePHI(Int8PtrTy, 0,
|
|
|
|
"indirect.goto.dest");
|
2012-12-04 08:29:55 +08:00
|
|
|
|
2009-10-29 07:59:40 +08:00
|
|
|
// Create the indirect branch instruction.
|
|
|
|
IndirectBranch = TmpBuilder.CreateIndirectBr(DestVal);
|
|
|
|
return IndirectBranch->getParent();
|
2008-08-05 00:51:22 +08:00
|
|
|
}
|
2008-11-04 13:30:00 +08:00
|
|
|
|
2011-07-09 09:37:26 +08:00
|
|
|
/// Computes the length of an array in elements, as well as the base
|
|
|
|
/// element type and a properly-typed first element pointer.
|
|
|
|
llvm::Value *CodeGenFunction::emitArrayLength(const ArrayType *origArrayType,
|
|
|
|
QualType &baseType,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address &addr) {
|
2011-07-09 09:37:26 +08:00
|
|
|
const ArrayType *arrayType = origArrayType;
|
|
|
|
|
|
|
|
// If it's a VLA, we have to load the stored size. Note that
|
|
|
|
// this is the size of the VLA in bytes, not its size in elements.
|
2014-05-21 13:09:00 +08:00
|
|
|
llvm::Value *numVLAElements = nullptr;
|
2011-07-09 09:37:26 +08:00
|
|
|
if (isa<VariableArrayType>(arrayType)) {
|
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)
|
2011-06-25 05:55:10 +08:00
|
|
|
#include "clang/AST/TypeNodes.def"
|
2012-01-07 18:52:36 +08:00
|
|
|
llvm_unreachable("unexpected dependent type!");
|
2011-06-25 05:55:10 +08:00
|
|
|
|
|
|
|
// These types are never variably-modified.
|
|
|
|
case Type::Builtin:
|
|
|
|
case Type::Complex:
|
|
|
|
case Type::Vector:
|
|
|
|
case Type::ExtVector:
|
|
|
|
case Type::Record:
|
|
|
|
case Type::Enum:
|
2012-01-11 16:19:46 +08:00
|
|
|
case Type::Elaborated:
|
|
|
|
case Type::TemplateSpecialization:
|
2016-09-14 01:25:08 +08:00
|
|
|
case Type::ObjCTypeParam:
|
2011-06-25 05:55:10 +08:00
|
|
|
case Type::ObjCObject:
|
|
|
|
case Type::ObjCInterface:
|
|
|
|
case Type::ObjCObjectPointer:
|
|
|
|
llvm_unreachable("type class is never variably-modified!");
|
|
|
|
|
2013-12-05 09:23:43 +08:00
|
|
|
case Type::Adjusted:
|
|
|
|
type = cast<AdjustedType>(ty)->getAdjustedType();
|
|
|
|
break;
|
|
|
|
|
2013-06-25 01:51:48 +08:00
|
|
|
case Type::Decayed:
|
|
|
|
type = cast<DecayedType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
2011-06-25 05:55:10 +08:00
|
|
|
case Type::Pointer:
|
|
|
|
type = cast<PointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::BlockPointer:
|
|
|
|
type = cast<BlockPointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::LValueReference:
|
|
|
|
case Type::RValueReference:
|
|
|
|
type = cast<ReferenceType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::MemberPointer:
|
|
|
|
type = cast<MemberPointerType>(ty)->getPointeeType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::ConstantArray:
|
|
|
|
case Type::IncompleteArray:
|
|
|
|
// Losing element qualification here is fine.
|
|
|
|
type = cast<ArrayType>(ty)->getElementType();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::VariableArray: {
|
|
|
|
// Losing element qualification here is fine.
|
|
|
|
const VariableArrayType *vat = cast<VariableArrayType>(ty);
|
|
|
|
|
|
|
|
// Unknown size indication requires no size computation.
|
|
|
|
// Otherwise, evaluate and record it.
|
|
|
|
if (const Expr *size = vat->getSizeExpr()) {
|
|
|
|
// It's possible that we might have emitted this already,
|
|
|
|
// e.g. with a typedef and a pointer to it.
|
|
|
|
llvm::Value *&entry = VLASizeMap[size];
|
|
|
|
if (!entry) {
|
2012-10-10 09:11:12 +08:00
|
|
|
llvm::Value *Size = EmitScalarExpr(size);
|
|
|
|
|
|
|
|
// C11 6.7.6.2p5:
|
|
|
|
// If the size is an expression that is not an integer constant
|
|
|
|
// expression [...] each time it is evaluated it shall have a value
|
|
|
|
// greater than zero.
|
2014-11-08 06:29:38 +08:00
|
|
|
if (SanOpts.has(SanitizerKind::VLABound) &&
|
2012-11-06 06:21:05 +08:00
|
|
|
size->getType()->isSignedIntegerType()) {
|
2014-07-18 02:46:27 +08:00
|
|
|
SanitizerScope SanScope(this);
|
2012-10-10 09:11:12 +08:00
|
|
|
llvm::Value *Zero = llvm::Constant::getNullValue(Size->getType());
|
|
|
|
llvm::Constant *StaticArgs[] = {
|
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:
|
2013-07-14 05:08:08 +08:00
|
|
|
case Type::PackExpansion:
|
2012-01-11 16:19:46 +08:00
|
|
|
// Keep walking after single level desugaring.
|
|
|
|
type = type.getSingleStepDesugaredType(getContext());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Type::Typedef:
|
|
|
|
case Type::Decltype:
|
|
|
|
case Type::Auto:
|
2017-01-27 04:40:47 +08:00
|
|
|
case Type::DeducedTemplateSpecialization:
|
2012-01-11 16:19:46 +08:00
|
|
|
// Stop walking: nothing to do.
|
|
|
|
return;
|
|
|
|
|
|
|
|
case Type::TypeOfExpr:
|
|
|
|
// Stop walking: emit typeof expression.
|
|
|
|
EmitIgnoredExpr(cast<TypeOfExprType>(ty)->getUnderlyingExpr());
|
|
|
|
return;
|
|
|
|
|
2011-10-07 07:00:33 +08:00
|
|
|
case Type::Atomic:
|
|
|
|
type = cast<AtomicType>(ty)->getValueType();
|
|
|
|
break;
|
2016-01-09 20:53:17 +08:00
|
|
|
|
|
|
|
case Type::Pipe:
|
|
|
|
type = cast<PipeType>(ty)->getElementType();
|
|
|
|
break;
|
2011-06-25 05:55:10 +08:00
|
|
|
}
|
|
|
|
} while (type->isVariablyModifiedType());
|
2008-12-12 15:19:02 +08:00
|
|
|
}
|
2009-01-21 01:46:04 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address CodeGenFunction::EmitVAListRef(const Expr* E) {
|
2010-10-30 06:47:07 +08:00
|
|
|
if (getContext().getBuiltinVaListType()->isArrayType())
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return EmitPointerWithAlignment(E);
|
2009-01-21 01:46:04 +08:00
|
|
|
return EmitLValue(E).getAddress();
|
|
|
|
}
|
2009-02-08 06:53:43 +08:00
|
|
|
|
2015-09-18 04:55:33 +08:00
|
|
|
Address CodeGenFunction::EmitMSVAListRef(const Expr *E) {
|
|
|
|
return EmitLValue(E).getAddress();
|
|
|
|
}
|
|
|
|
|
2013-08-30 16:53:09 +08:00
|
|
|
void CodeGenFunction::EmitDeclRefExprDbgValue(const DeclRefExpr *E,
|
2016-09-13 09:13:19 +08:00
|
|
|
const APValue &Init) {
|
|
|
|
assert(!Init.isUninit() && "Invalid DeclRefExpr initializer!");
|
2013-08-30 16:53:09 +08:00
|
|
|
if (CGDebugInfo *Dbg = getDebugInfo())
|
2016-02-02 19:06:51 +08:00
|
|
|
if (CGM.getCodeGenOpts().getDebugInfo() >= codegenoptions::LimitedDebugInfo)
|
2013-08-30 16:53:09 +08:00
|
|
|
Dbg->EmitGlobalVariable(E->getDecl(), Init);
|
2010-08-10 15:24:25 +08:00
|
|
|
}
|
2011-02-17 18:25:35 +08:00
|
|
|
|
|
|
|
CodeGenFunction::PeepholeProtection
|
|
|
|
CodeGenFunction::protectFromPeepholes(RValue rvalue) {
|
|
|
|
// At the moment, the only aggressive peephole we do in IR gen
|
|
|
|
// is trunc(zext) folding, but if we add more, we can easily
|
|
|
|
// extend this protection.
|
|
|
|
|
|
|
|
if (!rvalue.isScalar()) return PeepholeProtection();
|
|
|
|
llvm::Value *value = rvalue.getScalarVal();
|
|
|
|
if (!isa<llvm::ZExtInst>(value)) return PeepholeProtection();
|
|
|
|
|
|
|
|
// Just make an extra bitcast.
|
|
|
|
assert(HaveInsertPoint());
|
|
|
|
llvm::Instruction *inst = new llvm::BitCastInst(value, value->getType(), "",
|
|
|
|
Builder.GetInsertBlock());
|
|
|
|
|
|
|
|
PeepholeProtection protection;
|
|
|
|
protection.Inst = inst;
|
|
|
|
return protection;
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGenFunction::unprotectFromPeepholes(PeepholeProtection protection) {
|
|
|
|
if (!protection.Inst) return;
|
|
|
|
|
|
|
|
// In theory, we could try to duplicate the peepholes now, but whatever.
|
|
|
|
protection.Inst->eraseFromParent();
|
|
|
|
}
|
2011-09-10 06:41:49 +08:00
|
|
|
|
|
|
|
llvm::Value *CodeGenFunction::EmitAnnotationCall(llvm::Value *AnnotationFn,
|
|
|
|
llvm::Value *AnnotatedVal,
|
2013-01-13 03:30:44 +08:00
|
|
|
StringRef AnnotationStr,
|
2011-09-10 06:41:49 +08:00
|
|
|
SourceLocation Location) {
|
|
|
|
llvm::Value *Args[4] = {
|
|
|
|
AnnotatedVal,
|
|
|
|
Builder.CreateBitCast(CGM.EmitAnnotationString(AnnotationStr), Int8PtrTy),
|
|
|
|
Builder.CreateBitCast(CGM.EmitAnnotationUnit(Location), Int8PtrTy),
|
|
|
|
CGM.EmitAnnotationLineNo(Location)
|
|
|
|
};
|
|
|
|
return Builder.CreateCall(AnnotationFn, Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGenFunction::EmitVarAnnotations(const VarDecl *D, llvm::Value *V) {
|
|
|
|
assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
|
|
|
|
// FIXME We create a new bitcast for every annotation because that's what
|
|
|
|
// llvm-gcc was doing.
|
2014-03-11 01:08:28 +08:00
|
|
|
for (const auto *I : D->specific_attrs<AnnotateAttr>())
|
2011-09-10 06:41:49 +08:00
|
|
|
EmitAnnotationCall(CGM.getIntrinsic(llvm::Intrinsic::var_annotation),
|
|
|
|
Builder.CreateBitCast(V, CGM.Int8PtrTy, V->getName()),
|
2014-03-11 01:08:28 +08:00
|
|
|
I->getAnnotation(), D->getLocation());
|
2011-09-10 06:41:49 +08:00
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address CodeGenFunction::EmitFieldAnnotations(const FieldDecl *D,
|
|
|
|
Address Addr) {
|
2011-09-10 06:41:49 +08:00
|
|
|
assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *V = Addr.getPointer();
|
2011-09-10 06:41:49 +08:00
|
|
|
llvm::Type *VTy = V->getType();
|
|
|
|
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::ptr_annotation,
|
|
|
|
CGM.Int8PtrTy);
|
|
|
|
|
2014-03-11 01:08:28 +08:00
|
|
|
for (const auto *I : D->specific_attrs<AnnotateAttr>()) {
|
2011-09-10 06:41:49 +08:00
|
|
|
// FIXME Always emit the cast inst so we can differentiate between
|
|
|
|
// annotation on the first field of a struct and annotation on the struct
|
|
|
|
// itself.
|
|
|
|
if (VTy != CGM.Int8PtrTy)
|
|
|
|
V = Builder.Insert(new llvm::BitCastInst(V, CGM.Int8PtrTy));
|
2014-03-11 01:08:28 +08:00
|
|
|
V = EmitAnnotationCall(F, V, I->getAnnotation(), D->getLocation());
|
2011-09-10 06:41:49 +08:00
|
|
|
V = Builder.CreateBitCast(V, VTy);
|
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return Address(V, Addr.getAlignment());
|
2011-09-10 06:41:49 +08:00
|
|
|
}
|
2013-05-10 03:17:11 +08:00
|
|
|
|
2015-10-20 21:23:58 +08:00
|
|
|
CodeGenFunction::CGCapturedStmtInfo::~CGCapturedStmtInfo() { }
|
2014-05-22 16:54:05 +08:00
|
|
|
|
2014-07-18 02:46:27 +08:00
|
|
|
CodeGenFunction::SanitizerScope::SanitizerScope(CodeGenFunction *CGF)
|
|
|
|
: CGF(CGF) {
|
|
|
|
assert(!CGF->IsSanitizerScope);
|
|
|
|
CGF->IsSanitizerScope = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeGenFunction::SanitizerScope::~SanitizerScope() {
|
|
|
|
CGF->IsSanitizerScope = false;
|
|
|
|
}
|
|
|
|
|
2014-05-22 16:54:05 +08:00
|
|
|
void CodeGenFunction::InsertHelper(llvm::Instruction *I,
|
|
|
|
const llvm::Twine &Name,
|
|
|
|
llvm::BasicBlock *BB,
|
|
|
|
llvm::BasicBlock::iterator InsertPt) const {
|
|
|
|
LoopStack.InsertHelper(I);
|
2014-08-26 10:29:59 +08:00
|
|
|
if (IsSanitizerScope)
|
|
|
|
CGM.getSanitizerMetadata()->disableSanitizerForInstruction(I);
|
2014-05-22 16:54:05 +08:00
|
|
|
}
|
|
|
|
|
2016-03-14 05:05:23 +08:00
|
|
|
void CGBuilderInserter::InsertHelper(
|
2014-05-22 16:54:05 +08:00
|
|
|
llvm::Instruction *I, const llvm::Twine &Name, llvm::BasicBlock *BB,
|
|
|
|
llvm::BasicBlock::iterator InsertPt) const {
|
2016-03-14 05:05:23 +08:00
|
|
|
llvm::IRBuilderDefaultInserter::InsertHelper(I, Name, BB, InsertPt);
|
2014-05-22 16:54:05 +08:00
|
|
|
if (CGF)
|
|
|
|
CGF->InsertHelper(I, Name, BB, InsertPt);
|
|
|
|
}
|
|
|
|
|
2015-11-12 09:09:58 +08:00
|
|
|
static bool hasRequiredFeatures(const SmallVectorImpl<StringRef> &ReqFeatures,
|
2015-11-14 10:38:37 +08:00
|
|
|
CodeGenModule &CGM, const FunctionDecl *FD,
|
|
|
|
std::string &FirstMissing) {
|
2015-11-12 09:09:58 +08:00
|
|
|
// If there aren't any required features listed then go ahead and return.
|
|
|
|
if (ReqFeatures.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Now build up the set of caller features and verify that all the required
|
|
|
|
// features are there.
|
|
|
|
llvm::StringMap<bool> CallerFeatureMap;
|
2018-11-13 23:48:08 +08:00
|
|
|
CGM.getFunctionFeatureMap(CallerFeatureMap, GlobalDecl().getWithDecl(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) {
|
|
|
|
// Early exit if this is an indirect call.
|
|
|
|
if (!TargetDecl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Get the current enclosing function if it exists. If it doesn't
|
|
|
|
// we can't check the target features anyhow.
|
|
|
|
const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(CurFuncDecl);
|
|
|
|
if (!FD)
|
|
|
|
return;
|
|
|
|
|
2015-11-12 08:44:12 +08:00
|
|
|
// Grab the required features for the call. For a builtin this is listed in
|
|
|
|
// the td file with the default cpu, for an always_inline function this is any
|
|
|
|
// listed cpu and any listed features.
|
2015-11-12 08:44:07 +08:00
|
|
|
unsigned BuiltinID = TargetDecl->getBuiltinID();
|
2015-11-14 10:38:37 +08:00
|
|
|
std::string MissingFeature;
|
2015-11-12 08:44:12 +08:00
|
|
|
if (BuiltinID) {
|
|
|
|
SmallVector<StringRef, 1> ReqFeatures;
|
|
|
|
const char *FeatureList =
|
|
|
|
CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
|
|
|
|
// Return if the builtin doesn't have any required features.
|
|
|
|
if (!FeatureList || StringRef(FeatureList) == "")
|
|
|
|
return;
|
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))
|
2018-08-10 05:08:08 +08:00
|
|
|
CGM.getDiags().Report(E->getBeginLoc(), diag::err_builtin_needs_feature)
|
2015-11-12 08:44:12 +08:00
|
|
|
<< TargetDecl->getDeclName()
|
|
|
|
<< CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
|
|
|
|
|
2018-07-20 22:13:28 +08:00
|
|
|
} else if (TargetDecl->hasAttr<TargetAttr>() ||
|
|
|
|
TargetDecl->hasAttr<CPUSpecificAttr>()) {
|
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>();
|
|
|
|
TargetAttr::ParsedTargetAttr ParsedAttr = CGM.filterFunctionTargetAttrs(TD);
|
|
|
|
|
2015-11-12 08:44:12 +08:00
|
|
|
SmallVector<StringRef, 1> ReqFeatures;
|
|
|
|
llvm::StringMap<bool> CalleeFeatureMap;
|
|
|
|
CGM.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))
|
2018-08-10 05:08:08 +08:00
|
|
|
CGM.getDiags().Report(E->getBeginLoc(), 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) {
|
2018-07-20 22:13:28 +08:00
|
|
|
assert((getContext().getTargetInfo().getTriple().getArch() ==
|
|
|
|
llvm::Triple::x86 ||
|
|
|
|
getContext().getTargetInfo().getTriple().getArch() ==
|
|
|
|
llvm::Triple::x86_64) &&
|
|
|
|
"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();
|
|
|
|
}
|
|
|
|
|
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();
|
|
|
|
}
|