[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(LLVMCore
|
AbstractCallSite -- A unified interface for (in)direct and callback calls
An abstract call site is a wrapper that allows to treat direct,
indirect, and callback calls the same. If an abstract call site
represents a direct or indirect call site it behaves like a stripped
down version of a normal call site object. The abstract call site can
also represent a callback call, thus the fact that the initially
called function (=broker) may invoke a third one (=callback callee).
In this case, the abstract call side hides the middle man, hence the
broker function. The result is a representation of the callback call,
inside the broker, but in the context of the original instruction that
invoked the broker.
Again, there are up to three functions involved when we talk about
callback call sites. The caller (1), which invokes the broker
function. The broker function (2), that may or may not invoke the
callback callee. And finally the callback callee (3), which is the
target of the callback call.
The abstract call site will handle the mapping from parameters to
arguments depending on the semantic of the broker function. However,
it is important to note that the mapping is often partial. Thus, some
arguments of the call/invoke instruction are mapped to parameters of
the callee while others are not. At the same time, arguments of the
callback callee might be unknown, thus "null" if queried.
This patch introduces also !callback metadata which describe how a
callback broker maps from parameters to arguments. This metadata is
directly created by clang for known broker functions, provided through
source code attributes by the user, or later deduced by analyses.
For motivation and additional information please see the corresponding
talk (slides/video)
https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20
as well as the LCPC paper
http://compilers.cs.uni-saarland.de/people/doerfert/par_opt_lcpc18.pdf
Differential Revision: https://reviews.llvm.org/D54498
llvm-svn: 351627
2019-01-19 13:19:06 +08:00
|
|
|
AbstractCallSite.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
AsmWriter.cpp
|
2008-09-24 09:58:12 +08:00
|
|
|
Attributes.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
AutoUpgrade.cpp
|
|
|
|
BasicBlock.cpp
|
Introduce CfgTraits abstraction
The CfgTraits abstraction simplfies writing algorithms that are
generic over the type of CFG, and enables writing such algorithms
as regular non-template code that operates on opaque references
to CFG blocks and values.
Implementations of CfgTraits provide operations on the concrete
CFG types, e.g. `IrCfgTraits::BlockRef` is `BasicBlock *`.
CfgInterface is an abstract base class which provides operations
on opaque types CfgBlockRef and CfgValueRef. Those opaque types
encapsulate a `void *`, but the meaning depends on the concrete
CFG type. For example, MachineCfgTraits -- for use with MachineIR
in SSA form -- encodes a Register inside CfgValueRef. Converting
between concrete references and opaque/generic ones is done by
CfgTraits::{fromGeneric,toGeneric}. Convenience methods
CfgTraits::{un}wrap{Iterator,Range} are available as well.
Writing algorithms in terms of CfgInterface adds some overhead
(virtual method calls, plus in same cases it removes the
opportunity to inline iterators), but can be much more convenient
since generic algorithms can be written as non-templates.
This patch adds implementations of CfgTraits for all CFGs on
which dominator trees are calculated, so that the dominator
tree can be ported to this machinery. Only IrCfgTraits (LLVM IR)
and MachineCfgTraits (Machine IR in SSA form) are complete, the
other implementations are limited to the absolute minimum
required to make the upcoming dominator tree changes work.
v5:
- fix MachineCfgTraits::blockdef_iterator and allow it to iterate over
the instructions in a bundle
- use MachineBasicBlock::printName
v6:
- implement predecessors/successors for all CfgTraits implementations
- fix error in unwrapRange
- rename toGeneric/fromGeneric into wrapRef/unwrapRef to have naming
that is consistent with {wrap,unwrap}{Iterator,Range}
- use getVRegDef instead of getUniqueVRegDef
v7:
- std::forward fix in wrapping_iterator
- fix typos
v8:
- cleanup operators on CfgOpaqueType
- address other review comments
Change-Id: Ia75f4f268fded33fca11218a7d578c9aec1f3f4d
Differential Revision: https://reviews.llvm.org/D83088
2020-10-20 19:50:52 +08:00
|
|
|
CFG.cpp
|
2014-06-28 02:19:56 +08:00
|
|
|
Comdat.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ConstantFold.cpp
|
2014-03-04 20:24:34 +08:00
|
|
|
ConstantRange.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Constants.cpp
|
|
|
|
Core.cpp
|
2013-11-09 20:26:54 +08:00
|
|
|
DIBuilder.cpp
|
2012-10-05 06:08:14 +08:00
|
|
|
DataLayout.cpp
|
2012-06-28 08:18:12 +08:00
|
|
|
DebugInfo.cpp
|
2015-02-03 02:53:21 +08:00
|
|
|
DebugInfoMetadata.cpp
|
2011-10-05 02:22:24 +08:00
|
|
|
DebugLoc.cpp
|
2017-09-16 04:10:09 +08:00
|
|
|
DiagnosticHandler.cpp
|
2014-04-12 22:26:59 +08:00
|
|
|
DiagnosticInfo.cpp
|
|
|
|
DiagnosticPrinter.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Dominators.cpp
|
2019-08-29 20:29:11 +08:00
|
|
|
FPEnv.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Function.cpp
|
2010-01-28 04:44:12 +08:00
|
|
|
GVMaterializer.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Globals.cpp
|
2010-01-28 04:44:12 +08:00
|
|
|
IRBuilder.cpp
|
2014-01-09 10:39:45 +08:00
|
|
|
IRPrintingPasses.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
InlineAsm.cpp
|
|
|
|
Instruction.cpp
|
|
|
|
Instructions.cpp
|
|
|
|
IntrinsicInst.cpp
|
2009-06-30 08:48:55 +08:00
|
|
|
LLVMContext.cpp
|
2010-03-22 05:17:34 +08:00
|
|
|
LLVMContextImpl.cpp
|
2019-10-29 05:53:31 +08:00
|
|
|
LLVMRemarkStreamer.cpp
|
2013-11-09 20:26:54 +08:00
|
|
|
LegacyPassManager.cpp
|
2014-04-12 22:26:59 +08:00
|
|
|
MDBuilder.cpp
|
2014-01-08 05:19:40 +08:00
|
|
|
Mangler.cpp
|
2009-07-29 05:49:47 +08:00
|
|
|
Metadata.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Module.cpp
|
2016-03-15 08:04:37 +08:00
|
|
|
ModuleSummaryIndex.cpp
|
2015-05-08 08:42:26 +08:00
|
|
|
Operator.cpp
|
2016-04-23 06:06:11 +08:00
|
|
|
OptBisect.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Pass.cpp
|
2018-09-21 01:08:45 +08:00
|
|
|
PassInstrumentation.cpp
|
2013-11-13 09:12:08 +08:00
|
|
|
PassManager.cpp
|
2010-07-21 02:39:06 +08:00
|
|
|
PassRegistry.cpp
|
2018-08-29 05:06:51 +08:00
|
|
|
PassTimingInfo.cpp
|
2017-07-05 09:16:29 +08:00
|
|
|
SafepointIRVerifier.cpp
|
2016-05-20 05:07:12 +08:00
|
|
|
ProfileSummary.cpp
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-03 02:50:36 +08:00
|
|
|
Statepoint.cpp
|
2020-08-27 23:31:54 +08:00
|
|
|
StructuralHash.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Type.cpp
|
2012-08-03 08:30:35 +08:00
|
|
|
TypeFinder.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Use.cpp
|
2011-01-16 16:10:57 +08:00
|
|
|
User.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Value.cpp
|
|
|
|
ValueSymbolTable.cpp
|
|
|
|
Verifier.cpp
|
2015-02-11 11:28:02 +08:00
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/IR
|
2012-06-24 11:48:29 +08:00
|
|
|
|
2019-08-16 02:06:30 +08:00
|
|
|
LINK_LIBS ${LLVM_PTHREAD_LIB}
|
|
|
|
|
2016-11-17 12:36:50 +08:00
|
|
|
DEPENDS
|
|
|
|
intrinsics_gen
|
|
|
|
)
|