[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(LLVMipo
|
[PM] Port the always inliner to the new pass manager in a much more
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
llvm-svn: 278896
2016-08-17 10:56:20 +08:00
|
|
|
AlwaysInliner.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ArgumentPromotion.cpp
|
[Attributor] Pass infrastructure and fixpoint framework
NOTE: Note that no attributes are derived yet. This patch will not go in
alone but only with others that derive attributes. The framework is
split for review purposes.
This commit introduces the Attributor pass infrastructure and fixpoint
iteration framework. Further patches will introduce abstract attributes
into this framework.
In a nutshell, the Attributor will update instances of abstract
arguments until a fixpoint, or a "timeout", is reached. Communication
between the Attributor and the abstract attributes that are derived is
restricted to the AbstractState and AbstractAttribute interfaces.
Please see the file comment in Attributor.h for detailed information
including design decisions and typical use case. Also consider the class
documentation for Attributor, AbstractState, and AbstractAttribute.
Reviewers: chandlerc, homerdin, hfinkel, fedor.sergeev, sanjoy, spatel, nlopes, nicholas, reames
Subscribers: mehdi_amini, mgorny, hiraditya, bollu, steven_wu, dexonsmith, dang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59918
llvm-svn: 362578
2019-06-05 11:02:24 +08:00
|
|
|
Attributor.cpp
|
2020-04-09 06:24:24 +08:00
|
|
|
AttributorAttributes.cpp
|
Introduce a BarrierNoop pass, a hack designed to allow *some* control
over the implicitly-formed-and-nesting CGSCC pass manager and function
pass managers, especially when using them on the opt commandline or
using extension points in the module builder. The '-barrier' opt flag
(or the pass itself) will create a no-op module pass in the pipeline,
resetting the pass manager stack, and allowing the creation of a new
pipeline of function passes or CGSCC passes to be created that is
independent from any previous pipelines.
For example, this can be used to test running two CGSCC passes in
independent CGSCC pass managers as opposed to in the same CGSCC pass
manager. It also allows us to introduce a further hack into the
PassManagerBuilder to separate the O0 pipeline extension passes from the
always-inliner's CGSCC pass manager, which they likely do not want to
participate in... At the very least none of the Sanitizer passes want
this behavior.
This fixes a bug with ASan at O0 currently, and I'll commit the ASan
test which covers this pass. I'm happy to add a test case that this pass
exists and works, but not sure how much time folks would like me to
spend adding test cases for the details of its behavior of partition
pass managers.... The whole thing is just vile, and mostly intended to
unblock ASan, so I'm hoping to rip this all out in a brave new pass
manager world.
llvm-svn: 166172
2012-10-18 16:05:46 +08:00
|
|
|
BarrierNoopPass.cpp
|
2018-01-24 05:51:34 +08:00
|
|
|
BlockExtractor.cpp
|
2017-10-25 21:40:08 +08:00
|
|
|
CalledValuePropagation.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ConstantMerge.cpp
|
2015-12-16 07:00:08 +08:00
|
|
|
CrossDSOCFI.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
DeadArgumentElimination.cpp
|
2015-07-07 00:22:42 +08:00
|
|
|
ElimAvailExtern.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ExtractGV.cpp
|
2015-12-27 16:13:45 +08:00
|
|
|
ForceFunctionAttrs.cpp
|
2009-07-22 01:43:20 +08:00
|
|
|
FunctionAttrs.cpp
|
2015-11-24 14:07:49 +08:00
|
|
|
FunctionImport.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
GlobalDCE.cpp
|
|
|
|
GlobalOpt.cpp
|
2016-11-17 07:40:26 +08:00
|
|
|
GlobalSplit.cpp
|
2018-09-07 23:03:49 +08:00
|
|
|
HotColdSplitting.cpp
|
2009-07-22 01:43:20 +08:00
|
|
|
IPConstantPropagation.cpp
|
|
|
|
IPO.cpp
|
2015-12-27 16:41:34 +08:00
|
|
|
InferFunctionAttrs.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
InlineSimple.cpp
|
2009-07-22 01:43:20 +08:00
|
|
|
Inliner.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Internalize.cpp
|
|
|
|
LoopExtractor.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
|
|
|
LowerTypeTests.cpp
|
2008-11-02 14:01:39 +08:00
|
|
|
MergeFunctions.cpp
|
2019-11-07 13:20:06 +08:00
|
|
|
OpenMPOpt.cpp
|
2009-06-14 21:39:56 +08:00
|
|
|
PartialInlining.cpp
|
2011-08-03 05:50:27 +08:00
|
|
|
PassManagerBuilder.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
PruneEH.cpp
|
2015-08-25 23:25:11 +08:00
|
|
|
SampleProfile.cpp
|
2018-03-23 05:41:29 +08:00
|
|
|
SCCP.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
StripDeadPrototypes.cpp
|
|
|
|
StripSymbols.cpp
|
2018-01-10 03:39:35 +08:00
|
|
|
SyntheticCountsPropagation.cpp
|
2016-12-16 08:26:30 +08:00
|
|
|
ThinLTOBitcodeWriter.cpp
|
2016-02-10 06:50:34 +08:00
|
|
|
WholeProgramDevirt.cpp
|
2015-02-11 11:28:02 +08:00
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms/IPO
|
2012-06-24 21:32:01 +08:00
|
|
|
|
2016-11-17 12:36:50 +08:00
|
|
|
DEPENDS
|
|
|
|
intrinsics_gen
|
|
|
|
)
|