[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 05:39:58 +00:00
|
|
|
add_llvm_component_library(LLVMTransformUtils
|
2020-04-02 13:41:24 +02:00
|
|
|
AddDiscriminators.cpp
|
2019-08-22 15:34:35 +05:30
|
|
|
AMDGPUEmitPrintf.cpp
|
2013-12-06 09:00:17 +00:00
|
|
|
ASanStackFrameLayout.cpp
|
2020-04-02 13:41:24 +02:00
|
|
|
AssumeBundleBuilder.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
BasicBlockUtils.cpp
|
|
|
|
BreakCriticalEdges.cpp
|
2010-03-05 22:34:16 +00:00
|
|
|
BuildLibCalls.cpp
|
2012-09-04 18:22:17 +00:00
|
|
|
BypassSlowDivision.cpp
|
2017-12-06 21:22:54 +00:00
|
|
|
CallPromotionUtils.cpp
|
2019-11-29 13:11:24 -06:00
|
|
|
CallGraphUpdater.cpp
|
[ThinLTO] Handle chains of aliases
At -O0, globalopt is not run during the compile step, and we can have a
chain of an alias having an immediate aliasee of another alias. The
summaries are constructed assuming aliases in a canonical form
(flattened chains), and as a result only the base object but no
intermediate aliases were preserved.
Fix by adding a pass that canonicalize aliases, which ensures each
alias is a direct alias of the base object.
Reviewers: pcc, davidxl
Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54507
llvm-svn: 350423
2019-01-04 19:04:54 +00:00
|
|
|
CanonicalizeAliases.cpp
|
Add CanonicalizeFreezeInLoops pass
Summary:
If an induction variable is frozen and used, SCEV yields imprecise result
because it doesn't say anything about frozen variables.
Due to this reason, performance degradation happened after
https://reviews.llvm.org/D76483 is merged, causing
SCEV yield imprecise result and preventing LSR to optimize a loop.
The suggested solution here is to add a pass which canonicalizes frozen variables
inside a loop. To be specific, it pushes freezes out of the loop by freezing
the initial value and step values instead & dropping nsw/nuw flags from instructions used by freeze.
This solution was also mentioned at https://reviews.llvm.org/D70623 .
Reviewers: spatel, efriedma, lebedev.ri, fhahn, jdoerfert
Reviewed By: fhahn
Subscribers: nikic, mgorny, hiraditya, javed.absar, llvm-commits, sanwou01, nlopes
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77523
2020-05-08 05:28:42 +09:00
|
|
|
CanonicalizeFreezeInLoops.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
CloneFunction.cpp
|
|
|
|
CloneModule.cpp
|
|
|
|
CodeExtractor.cpp
|
ext-tsp basic block layout
A new basic block ordering improving existing MachineBlockPlacement.
The algorithm tries to find a layout of nodes (basic blocks) of a given CFG
optimizing jump locality and thus processor I-cache utilization. This is
achieved via increasing the number of fall-through jumps and co-locating
frequently executed nodes together. The name follows the underlying
optimization problem, Extended-TSP, which is a generalization of classical
(maximum) Traveling Salesmen Problem.
The algorithm is a greedy heuristic that works with chains (ordered lists)
of basic blocks. Initially all chains are isolated basic blocks. On every
iteration, we pick a pair of chains whose merging yields the biggest increase
in the ExtTSP value, which models how i-cache "friendly" a specific chain is.
A pair of chains giving the maximum gain is merged into a new chain. The
procedure stops when there is only one chain left, or when merging does not
increase ExtTSP. In the latter case, the remaining chains are sorted by
density in decreasing order.
An important aspect is the way two chains are merged. Unlike earlier
algorithms (e.g., based on the approach of Pettis-Hansen), two
chains, X and Y, are first split into three, X1, X2, and Y. Then we
consider all possible ways of gluing the three chains (e.g., X1YX2, X1X2Y,
X2X1Y, X2YX1, YX1X2, YX2X1) and choose the one producing the largest score.
This improves the quality of the final result (the search space is larger)
while keeping the implementation sufficiently fast.
Differential Revision: https://reviews.llvm.org/D113424
2021-11-08 07:02:33 -08:00
|
|
|
CodeLayout.cpp
|
[CodeMoverUtils] Added an API to check if an instruction can be safely
moved before another instruction.
Summary:Added an API to check if an instruction can be safely moved
before another instruction. In future PRs, we will like to add support
of moving instructions between blocks that are not control flow
equivalent, and add other APIs to enhance usability, e.g. moving basic
blocks, moving list of instructions...
Loop Fusion will be its first user. When there is intervening code in
between two loops, fusion is currently unable to fuse them. Loop Fusion
can use this utility to check if the intervening code can be safely
moved before or after the two loops, and move them, then it can
successfully fuse them.
Reviewer:kbarton,jdoerfert,Meinersbur,bmahjour,etiotto
Reviewed By:bmahjour
Subscribers:mgorny,hiraditya,llvm-commits
Tag:LLVM
Differential Revision:https://reviews.llvm.org/D70049
2019-11-22 21:27:29 +00:00
|
|
|
CodeMoverUtils.cpp
|
2014-11-08 00:00:47 +00:00
|
|
|
CtorUtils.cpp
|
2019-11-06 16:08:01 -08:00
|
|
|
Debugify.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
DemoteRegToStack.cpp
|
2017-11-14 21:09:45 +00:00
|
|
|
EntryExitInstrumenter.cpp
|
2016-11-14 21:41:13 +00:00
|
|
|
EscapeEnumerator.cpp
|
2016-02-03 02:51:00 +00:00
|
|
|
Evaluator.cpp
|
2020-04-15 15:05:51 +05:30
|
|
|
FixIrreducible.cpp
|
2014-11-08 00:00:47 +00:00
|
|
|
FlattenCFG.cpp
|
2016-11-11 21:15:13 +00:00
|
|
|
FunctionComparator.cpp
|
2016-02-10 18:11:31 +00:00
|
|
|
FunctionImportUtils.cpp
|
2013-10-21 17:14:55 +00:00
|
|
|
GlobalStatus.cpp
|
2018-08-29 10:51:59 +00:00
|
|
|
GuardUtils.cpp
|
2021-02-02 16:43:32 -08:00
|
|
|
HelloWorld.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
InlineFunction.cpp
|
2019-11-11 19:42:18 +00:00
|
|
|
InjectTLIMappings.cpp
|
2009-07-21 17:43:20 +00:00
|
|
|
InstructionNamer.cpp
|
2012-09-18 22:02:40 +00:00
|
|
|
IntegerDivision.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
LCSSA.cpp
|
Conditionally eliminate library calls where the result value is not used
Summary:
This pass shrink-wraps a condition to some library calls where the call
result is not used. For example:
sqrt(val);
is transformed to
if (val < 0)
sqrt(val);
Even if the result of library call is not being used, the compiler cannot
safely delete the call because the function can set errno on error
conditions.
Note in many functions, the error condition solely depends on the incoming
parameter. In this optimization, we can generate the condition can lead to
the errno to shrink-wrap the call. Since the chances of hitting the error
condition is low, the runtime call is effectively eliminated.
These partially dead calls are usually results of C++ abstraction penalty
exposed by inlining. This optimization hits 108 times in 19 C/C++ programs
in SPEC2006.
Reviewers: hfinkel, mehdi_amini, davidxl
Subscribers: modocache, mgorny, mehdi_amini, xur, llvm-commits, beanz
Differential Revision: https://reviews.llvm.org/D24414
llvm-svn: 284542
2016-10-18 21:36:27 +00:00
|
|
|
LibCallsShrinkWrap.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
Local.cpp
|
2020-07-31 18:31:58 +00:00
|
|
|
LoopPeel.cpp
|
2018-03-29 08:48:15 +00:00
|
|
|
LoopRotationUtils.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
LoopSimplify.cpp
|
2009-11-03 04:01:53 +00:00
|
|
|
LoopUnroll.cpp
|
2018-07-01 12:47:30 +00:00
|
|
|
LoopUnrollAndJam.cpp
|
2011-12-09 06:19:40 +00:00
|
|
|
LoopUnrollRuntime.cpp
|
2015-04-20 04:38:33 +00:00
|
|
|
LoopUtils.cpp
|
2015-07-10 18:55:13 +00:00
|
|
|
LoopVersioning.cpp
|
2022-03-23 17:37:07 -07:00
|
|
|
LowerGlobalDtors.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
LowerInvoke.cpp
|
2017-02-08 17:49:52 +00:00
|
|
|
LowerMemIntrinsics.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
LowerSwitch.cpp
|
2020-07-20 18:31:04 +01:00
|
|
|
MatrixUtils.cpp
|
2021-05-24 09:49:32 -07:00
|
|
|
MemoryOpRemark.cpp
|
2022-02-01 17:05:37 -08:00
|
|
|
MemoryTaggingSupport.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
Mem2Reg.cpp
|
2018-03-28 17:44:36 +00:00
|
|
|
MetaRenamer.cpp
|
2022-03-19 00:54:23 +00:00
|
|
|
MisExpect.cpp
|
2011-10-31 23:58:51 +00:00
|
|
|
ModuleUtils.cpp
|
2016-09-16 16:56:30 +00:00
|
|
|
NameAnonGlobals.cpp
|
Add PredicateInfo utility and printing pass
Summary:
This patch adds a utility to build extended SSA (see "ABCD: eliminating
array bounds checks on demand"), and an intrinsic to support it. This
is then used to get functionality equivalent to propagateEquality in
GVN, in NewGVN (without having to replace instructions as we go). It
would work similarly in SCCP or other passes. This has been talked
about a few times, so i built a real implementation and tried to
productionize it.
Copies are inserted for operands used in assumes and conditional
branches that are based on comparisons (see below for more)
Every use affected by the predicate is renamed to the appropriate
intrinsic result.
E.g.
%cmp = icmp eq i32 %x, 50
br i1 %cmp, label %true, label %false
true:
ret i32 %x
false:
ret i32 1
will become
%cmp = icmp eq i32, %x, 50
br i1 %cmp, label %true, label %false
true:
; Has predicate info
; branch predicate info { TrueEdge: 1 Comparison: %cmp = icmp eq i32 %x, 50 }
%x.0 = call @llvm.ssa_copy.i32(i32 %x)
ret i32 %x.0
false:
ret i23 1
(you can use -print-predicateinfo to get an annotated-with-predicateinfo dump)
This enables us to easily determine what operations are affected by a
given predicate, and how operations affected by a chain of
predicates.
Reviewers: davide, sanjoy
Subscribers: mgorny, llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D29519
Update for review comments
Fix a bug Nuno noticed where we are giving information about and/or on edges where the info is not useful and easy to use wrong
Update for review comments
llvm-svn: 294351
2017-02-07 21:10:46 +00:00
|
|
|
PredicateInfo.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
PromoteMemoryToRegister.cpp
|
2020-12-29 21:32:13 +00:00
|
|
|
RelLookupTableConverter.cpp
|
2020-05-20 10:08:08 +01:00
|
|
|
ScalarEvolutionExpander.cpp
|
2021-04-12 19:10:15 +01:00
|
|
|
SCCPSolver.cpp
|
2016-10-21 18:43:16 +00:00
|
|
|
StripGCRelocates.cpp
|
2009-10-10 09:04:27 +00:00
|
|
|
SSAUpdater.cpp
|
2018-04-09 23:37:20 +00:00
|
|
|
SSAUpdaterBulk.cpp
|
profi - a flow-based profile inference algorithm: Part I (out of 3)
The benefits of sampling-based PGO crucially depends on the quality of profile
data. This diff implements a flow-based algorithm, called profi, that helps to
overcome the inaccuracies in a profile after it is collected.
Profi is an extended and significantly re-engineered classic MCMF (min-cost
max-flow) approach suggested by Levin, Newman, and Haber [2008, Complementing
missing and inaccurate profiling using a minimum cost circulation algorithm]. It
models profile inference as an optimization problem on a control-flow graph with
the objectives and constraints capturing the desired properties of profile data.
Three important challenges that are being solved by profi:
- "fixing" errors in profiles caused by sampling;
- converting basic block counts to edge frequencies (branch probabilities);
- dealing with "dangling" blocks having no samples in the profile.
The main implementation (and required docs) are in SampleProfileInference.cpp.
The worst-time complexity is quadratic in the number of blocks in a function,
O(|V|^2). However a careful engineering and extensive evaluation shows that
the running time is (slightly) super-linear. In particular, instances with
1000 blocks are solved within 0.1 second.
The algorithm has been extensively tested internally on prod workloads,
significantly improving the quality of generated profile data and providing
speedups in the range from 0% to 5%. For "smaller" benchmarks (SPEC06/17), it
generally improves the performance (with a few outliers) but extra work in
the compiler might be needed to re-tune existing optimization passes relying on
profile counts.
UPD Dec 1st 2021:
- synced the declaration and definition of the option `SampleProfileUseProfi ` to use type `cl::opt<bool`;
- added `inline` for `SampleProfileInference<BT>::findUnlikelyJumps` and `SampleProfileInference<BT>::isExit` to avoid linking problems on windows.
Reviewed By: wenlei, hoy
Differential Revision: https://reviews.llvm.org/D109860
2021-12-01 15:29:35 -08:00
|
|
|
SampleProfileInference.cpp
|
2021-02-17 14:19:36 -08:00
|
|
|
SampleProfileLoaderBaseUtil.cpp
|
2016-01-16 00:31:11 +00:00
|
|
|
SanitizerStats.cpp
|
2009-07-21 17:43:20 +00:00
|
|
|
SimplifyCFG.cpp
|
2011-08-10 03:51:58 +00:00
|
|
|
SimplifyIndVar.cpp
|
2012-10-13 16:45:24 +00:00
|
|
|
SimplifyLibCalls.cpp
|
2019-04-15 16:49:00 +00:00
|
|
|
SizeOpts.cpp
|
2015-08-21 02:48:20 +00:00
|
|
|
SplitModule.cpp
|
2016-10-25 18:44:13 +00:00
|
|
|
StripNonLineTableDebugInfo.cpp
|
2014-11-08 00:00:47 +00:00
|
|
|
SymbolRewriter.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
UnifyFunctionExitNodes.cpp
|
2020-03-28 07:13:35 -04:00
|
|
|
UnifyLoopExits.cpp
|
2010-10-07 17:55:47 +00:00
|
|
|
Utils.cpp
|
2008-09-22 01:08:49 +00:00
|
|
|
ValueMapper.cpp
|
2017-03-10 04:54:10 +00:00
|
|
|
VNCoercion.cpp
|
2015-02-11 03:28:02 +00:00
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms/Utils
|
2012-06-24 13:32:01 +00:00
|
|
|
|
2016-11-17 04:36:50 +00:00
|
|
|
DEPENDS
|
|
|
|
intrinsics_gen
|
2020-10-09 18:41:21 +02:00
|
|
|
|
|
|
|
LINK_COMPONENTS
|
|
|
|
Analysis
|
|
|
|
Core
|
|
|
|
Support
|
2016-11-17 04:36:50 +00:00
|
|
|
)
|