2020-07-14 05:12:32 +08:00
|
|
|
if (DEFINED LLVM_HAVE_TF_AOT OR DEFINED LLVM_HAVE_TF_API)
|
|
|
|
if (DEFINED LLVM_HAVE_TF_AOT)
|
2021-02-12 14:17:59 +08:00
|
|
|
set(LLVM_INLINER_MODEL_PATH "models/inliner"
|
|
|
|
CACHE STRING
|
|
|
|
"ML-driven inliner policy location (path to saved model)")
|
2020-07-14 05:12:32 +08:00
|
|
|
include(TensorFlowCompile)
|
2021-02-12 14:17:59 +08:00
|
|
|
tfcompile(${LLVM_INLINER_MODEL_PATH} serve action InlinerSizeModel llvm::InlinerSizeModel)
|
2020-07-21 23:44:47 +08:00
|
|
|
list(APPEND GeneratedMLSources
|
2020-07-14 05:12:32 +08:00
|
|
|
$<TARGET_OBJECTS:tf_xla_runtime_objects>
|
|
|
|
${GENERATED_OBJS}
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
|
|
|
if (DEFINED LLVM_HAVE_TF_API)
|
|
|
|
LIST(APPEND MLLinkDeps ${tensorflow_c_api})
|
|
|
|
endif()
|
2020-06-10 05:50:50 +08:00
|
|
|
endif()
|
|
|
|
|
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:
1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.
With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.
2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.
I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:
- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON
Reviewers: beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 13:39:58 +08:00
|
|
|
add_llvm_component_library(LLVMAnalysis
|
2008-09-22 09:08:49 +08:00
|
|
|
AliasAnalysis.cpp
|
|
|
|
AliasAnalysisEvaluator.cpp
|
2016-07-06 08:47:21 +08:00
|
|
|
AliasAnalysisSummary.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
AliasSetTracker.cpp
|
|
|
|
Analysis.cpp
|
2020-04-02 19:41:24 +08:00
|
|
|
AssumeBundleQueries.cpp
|
2016-12-19 16:22:17 +08:00
|
|
|
AssumptionCache.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
BasicAliasAnalysis.cpp
|
2011-07-26 03:25:40 +08:00
|
|
|
BlockFrequencyInfo.cpp
|
2014-04-22 01:57:07 +08:00
|
|
|
BlockFrequencyInfoImpl.cpp
|
2011-06-04 09:16:30 +08:00
|
|
|
BranchProbabilityInfo.cpp
|
2013-07-27 09:25:51 +08:00
|
|
|
CFG.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
CFGPrinter.cpp
|
2016-07-06 08:26:41 +08:00
|
|
|
CFLAndersAliasAnalysis.cpp
|
|
|
|
CFLSteensAliasAnalysis.cpp
|
2014-04-21 19:12:00 +08:00
|
|
|
CGSCCPassManager.cpp
|
2015-08-19 01:51:53 +08:00
|
|
|
CallGraph.cpp
|
|
|
|
CallGraphSCCPass.cpp
|
|
|
|
CallPrinter.cpp
|
2009-07-16 05:08:16 +08:00
|
|
|
CaptureTracking.cpp
|
2017-08-15 05:39:51 +08:00
|
|
|
CmpInstAnalysis.cpp
|
2012-11-03 05:48:17 +08:00
|
|
|
CostModel.cpp
|
2012-03-16 13:51:52 +08:00
|
|
|
CodeMetrics.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ConstantFolding.cpp
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-19 01:43:45 +08:00
|
|
|
DDG.cpp
|
2020-12-17 01:34:38 +08:00
|
|
|
DDGPrinter.cpp
|
2020-09-15 17:28:25 +08:00
|
|
|
ConstraintSystem.cpp
|
2013-11-13 06:47:20 +08:00
|
|
|
Delinearization.cpp
|
2015-08-14 19:09:09 +08:00
|
|
|
DemandedBits.cpp
|
dependence analysis
Patch from Preston Briggs <preston.briggs@gmail.com>.
This is an updated version of the dependence-analysis patch, including an MIV
test based on Banerjee's inequalities.
It's a fairly complete implementation of the paper
Practical Dependence Testing
Gina Goff, Ken Kennedy, and Chau-Wen Tseng
PLDI 1991
It cannot yet propagate constraints between coupled RDIV subscripts (discussed
in Section 5.3.2 of the paper).
It's organized as a FunctionPass with a single entry point that supports testing
for dependence between two instructions in a function. If there's no dependence,
it returns null. If there's a dependence, it returns a pointer to a Dependence
which can be queried about details (what kind of dependence, is it loop
independent, direction and distance vector entries, etc). I haven't included
every imaginable feature, but there's a good selection that should be adequate
for supporting many loop transformations. Of course, it can be extended as
necessary.
Included in the patch file are many test cases, commented with C code showing
the loops and array references.
llvm-svn: 165708
2012-10-11 15:32:34 +08:00
|
|
|
DependenceAnalysis.cpp
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-19 01:43:45 +08:00
|
|
|
DependenceGraphBuilder.cpp
|
2020-07-21 23:44:47 +08:00
|
|
|
DevelopmentModeInlineAdvisor.cpp
|
2018-10-18 17:38:44 +08:00
|
|
|
DivergenceAnalysis.cpp
|
2009-10-18 12:10:40 +08:00
|
|
|
DomPrinter.cpp
|
2019-02-06 10:52:52 +08:00
|
|
|
DomTreeUpdater.cpp
|
2011-03-01 08:02:51 +08:00
|
|
|
DominanceFrontier.cpp
|
2015-12-03 07:06:39 +08:00
|
|
|
EHPersonalities.cpp
|
2020-07-23 00:52:53 +08:00
|
|
|
FunctionPropertiesAnalysis.cpp
|
2015-08-19 01:51:53 +08:00
|
|
|
GlobalsModRef.cpp
|
2018-08-30 11:39:16 +08:00
|
|
|
GuardUtils.cpp
|
2020-04-01 02:43:25 +08:00
|
|
|
HeatUtils.cpp
|
[IRSim] Adding IR Instruction Mapper
This introduces the IRInstructionMapper, and the associated wrapper for
instructions, IRInstructionData, that maps IR level Instructions to
unsigned integers.
Mapping is done mainly by using the "isSameOperationAs" comparison
between two instructions. If they return true, the opcode, result type,
and operand types of the instruction are used to hash the instruction
with an unsigned integer. The mapper accepts instruction ranges, and
adds each resulting integer to a list, and each wrapped instruction to
a separate list.
At present, branches, phi nodes are not mapping and exception handling
is illegal. Debug instructions are not considered.
The different mapping schemes are tested in
unittests/Analysis/IRSimilarityIdentifierTest.cpp
Recommit of: b04c1a9d3127730c05e8a22a0e931a12a39528df
Differential Revision: https://reviews.llvm.org/D86968
2020-09-18 01:28:09 +08:00
|
|
|
IRSimilarityIdentifier.cpp
|
2018-09-12 09:59:43 +08:00
|
|
|
IVDescriptors.cpp
|
2009-07-16 05:08:16 +08:00
|
|
|
IVUsers.cpp
|
2021-01-21 04:39:55 +08:00
|
|
|
ImportedFunctionsInliningStatistics.cpp
|
2016-07-13 05:13:44 +08:00
|
|
|
IndirectCallPromotionAnalysis.cpp
|
2015-08-19 01:51:53 +08:00
|
|
|
InlineCost.cpp
|
2020-05-08 11:35:08 +08:00
|
|
|
InlineAdvisor.cpp
|
2020-07-14 05:12:32 +08:00
|
|
|
InlineSizeEstimatorAnalysis.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
InstCount.cpp
|
2018-08-30 12:49:03 +08:00
|
|
|
InstructionPrecedenceTracking.cpp
|
2009-11-10 06:57:59 +08:00
|
|
|
InstructionSimplify.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Interval.cpp
|
|
|
|
IntervalPartition.cpp
|
2016-07-29 07:31:12 +08:00
|
|
|
LazyBranchProbabilityInfo.cpp
|
2016-07-13 13:01:48 +08:00
|
|
|
LazyBlockFrequencyInfo.cpp
|
2014-02-06 12:37:03 +08:00
|
|
|
LazyCallGraph.cpp
|
2009-11-11 08:22:30 +08:00
|
|
|
LazyValueInfo.cpp
|
2018-08-30 22:21:36 +08:00
|
|
|
LegacyDivergenceAnalysis.cpp
|
2020-09-03 12:34:20 +08:00
|
|
|
Lint.cpp
|
2010-05-29 00:19:17 +08:00
|
|
|
Loads.cpp
|
2015-02-02 00:56:15 +08:00
|
|
|
LoopAccessAnalysis.cpp
|
2017-01-11 17:43:56 +08:00
|
|
|
LoopAnalysisManager.cpp
|
Title: Loop Cache Analysis
Summary: Implement a new analysis to estimate the number of cache lines
required by a loop nest.
The analysis is largely based on the following paper:
Compiler Optimizations for Improving Data Locality
By: Steve Carr, Katherine S. McKinley, Chau-Wen Tseng
http://www.cs.utexas.edu/users/mckinley/papers/asplos-1994.pdf
The analysis considers temporal reuse (accesses to the same memory
location) and spatial reuse (accesses to memory locations within a cache
line). For simplicity the analysis considers memory accesses in the
innermost loop in a loop nest, and thus determines the number of cache
lines used when the loop L in loop nest LN is placed in the innermost
position.
The result of the analysis can be used to drive several transformations.
As an example, loop interchange could use it determine which loops in a
perfect loop nest should be interchanged to maximize cache reuse.
Similarly, loop distribution could be enhanced to take into
consideration cache reuse between arrays when distributing a loop to
eliminate vectorization inhibiting dependencies.
The general approach taken to estimate the number of cache lines used by
the memory references in the inner loop of a loop nest is:
Partition memory references that exhibit temporal or spatial reuse into
reference groups.
For each loop L in the a loop nest LN: a. Compute the cost of the
reference group b. Compute the 'cache cost' of the loop nest by summing
up the reference groups costs
For further details of the algorithm please refer to the paper.
Authored By: etiotto
Reviewers: hfinkel, Meinersbur, jdoerfert, kbarton, bmahjour, anemet,
fhahn
Reviewed By: Meinersbur
Subscribers: reames, nemanjai, MaskRay, wuzish, Hahnfeld, xusx595,
venkataramanan.kumar.llvm, greened, dmgreen, steleman, fhahn, xblvaOO,
Whitney, mgorny, hiraditya, mgrang, jsji, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D63459
llvm-svn: 368439
2019-08-09 21:56:29 +08:00
|
|
|
LoopCacheAnalysis.cpp
|
[LoopNest]: Analysis to discover properties of a loop nest.
Summary: This patch adds an analysis pass to collect loop nests and
summarize properties of the nest (e.g the nest depth, whether the nest
is perfect, what's the innermost loop, etc...).
The motivation for this patch was discussed at the latest meeting of the
LLVM loop group (https://ibm.box.com/v/llvm-loop-nest-analysis) where we
discussed
the unimodular loop transformation framework ( “A Loop Transformation
Theory and an Algorithm to Maximize Parallelism”, Michael E. Wolf and
Monica S. Lam, IEEE TPDS, October 1991). The unimodular framework
provides a convenient way to unify legality checking and code generation
for several loop nest transformations (e.g. loop reversal, loop
interchange, loop skewing) and their compositions. Given that the
unimodular framework is applicable to perfect loop nests this is one
property of interest we expose in this analysis. Several other utility
functions are also provided. In the future other properties of interest
can be added in a centralized place.
Authored By: etiotto
Reviewer: Meinersbur, bmahjour, kbarton, Whitney, dmgreen, fhahn,
reames, hfinkel, jdoerfert, ppc-slack
Reviewed By: Meinersbur
Subscribers: bryanpkc, ppc-slack, mgorny, hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D68789
2020-03-04 01:38:19 +08:00
|
|
|
LoopNestAnalysis.cpp
|
2016-02-09 07:03:59 +08:00
|
|
|
LoopUnrollAnalyzer.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
LoopInfo.cpp
|
|
|
|
LoopPass.cpp
|
2020-07-21 23:44:47 +08:00
|
|
|
MLInlineAdvisor.cpp
|
2010-09-17 07:06:18 +08:00
|
|
|
MemDepPrinter.cpp
|
2015-02-06 09:46:42 +08:00
|
|
|
MemDerefPrinter.cpp
|
2009-10-28 04:05:49 +08:00
|
|
|
MemoryBuiltins.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
MemoryDependenceAnalysis.cpp
|
2015-06-04 10:03:15 +08:00
|
|
|
MemoryLocation.cpp
|
2017-04-12 04:06:36 +08:00
|
|
|
MemorySSA.cpp
|
|
|
|
MemorySSAUpdater.cpp
|
2010-05-08 00:22:32 +08:00
|
|
|
ModuleDebugInfoPrinter.cpp
|
2020-04-14 08:27:08 +08:00
|
|
|
ModuleSummaryAnalysis.cpp
|
2018-03-21 01:09:21 +08:00
|
|
|
MustExecute.cpp
|
2015-08-20 16:06:03 +08:00
|
|
|
ObjCARCAliasAnalysis.cpp
|
|
|
|
ObjCARCAnalysisUtils.cpp
|
|
|
|
ObjCARCInstKind.cpp
|
2017-10-10 07:19:02 +08:00
|
|
|
OptimizationRemarkEmitter.cpp
|
2011-03-01 08:02:51 +08:00
|
|
|
PHITransAddr.cpp
|
2018-06-28 22:13:06 +08:00
|
|
|
PhiValues.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
PostDominators.cpp
|
2016-06-04 06:54:26 +08:00
|
|
|
ProfileSummaryInfo.cpp
|
Add a new visitor for walking the uses of a pointer value.
This visitor provides infrastructure for recursively traversing the
use-graph of a pointer-producing instruction like an alloca or a malloc.
It maintains a worklist of uses to visit, so it can handle very deep
recursions. It automatically looks through instructions which simply
translate one pointer to another (bitcasts and GEPs). It tracks the
offset relative to the original pointer as long as that offset remains
constant and exposes it during the visit as an APInt offset. Finally, it
performs conservative escape analysis.
However, currently it has some limitations that should be addressed
going forward:
1) It doesn't handle vectors of pointers.
2) It doesn't provide a cheaper visitor when the constant offset
tracking isn't needed.
3) It doesn't support non-instruction pointer values.
The current functionality is exactly what is required to implement the
SROA pointer-use visitors in terms of this one, rather than in terms of
their own ad-hoc base visitor, which was always very poorly specified.
SROA has been converted to use this, and the code there deleted which
this utility now provides.
Technically speaking, using this new visitor allows SROA to handle a few
more cases than it previously did. It is now more aggressive in ignoring
chains of instructions which look like they would defeat SROA, but in
fact do not because they never result in a read or write of memory.
While this is "neat", it shouldn't be interesting for real programs as
any such chains should have been removed by others passes long before we
get to SROA. As a consequence, I've not added any tests for these
features -- it shouldn't be part of SROA's contract to perform such
heroics.
The goal is to extend the functionality of this visitor going forward,
and re-use it from passes like ASan that can benefit from doing
a detailed walk of the uses of a pointer.
Thanks to Ben Kramer for the code review rounds and lots of help
reviewing and debugging this patch.
llvm-svn: 169728
2012-12-10 16:28:39 +08:00
|
|
|
PtrUseVisitor.cpp
|
2010-07-22 15:46:31 +08:00
|
|
|
RegionInfo.cpp
|
2010-10-20 09:54:44 +08:00
|
|
|
RegionPass.cpp
|
2010-07-22 15:46:31 +08:00
|
|
|
RegionPrinter.cpp
|
2020-07-21 23:44:47 +08:00
|
|
|
ReleaseModeModelRunner.cpp
|
2020-08-16 05:52:10 +08:00
|
|
|
ReplayInlineAdvisor.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ScalarEvolution.cpp
|
2009-08-27 00:33:57 +08:00
|
|
|
ScalarEvolutionAliasAnalysis.cpp
|
2020-06-17 18:09:22 +08:00
|
|
|
ScalarEvolutionDivision.cpp
|
2010-04-08 07:01:37 +08:00
|
|
|
ScalarEvolutionNormalization.cpp
|
2020-06-15 17:26:28 +08:00
|
|
|
StackLifetime.cpp
|
2018-11-27 05:57:47 +08:00
|
|
|
StackSafetyAnalysis.cpp
|
2018-10-18 17:38:44 +08:00
|
|
|
SyncDependenceAnalysis.cpp
|
2018-01-10 03:39:35 +08:00
|
|
|
SyntheticCountsUtils.cpp
|
2020-07-21 23:44:47 +08:00
|
|
|
TFUtils.cpp
|
2015-01-15 10:16:27 +08:00
|
|
|
TargetLibraryInfo.cpp
|
2013-01-07 11:08:10 +08:00
|
|
|
TargetTransformInfo.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Trace.cpp
|
2010-08-03 10:38:20 +08:00
|
|
|
TypeBasedAliasAnalysis.cpp
|
IR: New representation for CFI and virtual call optimization pass metadata.
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
2016-06-25 05:21:32 +08:00
|
|
|
TypeMetadataUtils.cpp
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
ScopedNoAliasAA.cpp
|
2017-09-28 19:09:22 +08:00
|
|
|
ValueLattice.cpp
|
2017-10-14 01:53:44 +08:00
|
|
|
ValueLatticeUtils.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ValueTracking.cpp
|
2015-06-27 02:02:52 +08:00
|
|
|
VectorUtils.cpp
|
2019-09-20 01:47:32 +08:00
|
|
|
VFABIDemangling.cpp
|
2020-07-21 23:44:47 +08:00
|
|
|
${GeneratedMLSources}
|
2015-02-11 11:28:02 +08:00
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Analysis
|
2011-02-19 06:06:14 +08:00
|
|
|
|
2016-11-17 12:36:50 +08:00
|
|
|
DEPENDS
|
|
|
|
intrinsics_gen
|
2020-07-14 05:12:32 +08:00
|
|
|
|
|
|
|
LINK_LIBS
|
|
|
|
${MLLinkDeps}
|
2020-10-10 00:41:21 +08:00
|
|
|
|
|
|
|
LINK_COMPONENTS
|
|
|
|
BinaryFormat
|
|
|
|
Core
|
|
|
|
Object
|
|
|
|
ProfileData
|
|
|
|
Support
|
2016-11-17 12:36:50 +08:00
|
|
|
)
|