maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/tools/opt/CMakeLists.txt

42 lines
625 B
CMake
Raw Normal View History

[CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt. llvm-svn: 196908
2013-12-10 19:13:32 +08:00
set(LLVM_LINK_COMPONENTS
${LLVM_TARGETS_TO_BUILD}
Analysis
BitWriter
[CodeGenPrepare] Move CodeGenPrepare into lib/CodeGen. CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen. This is a layer violation which would introduce eventually a dependence on CodeGen in ScalarOpts. Move CodeGenPrepare into libLLVMCodeGen to avoid that. Follow-up of <rdar://problem/15519855> llvm-svn: 201912
2014-02-22 08:07:45 +08:00
CodeGen
[CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt. llvm-svn: 196908
2013-12-10 19:13:32 +08:00
Core
[coroutines] Part 3 of N: Adding Boilerplate for Coroutine Passes This adds boilerplate code for all coroutine passes, the passes are no-ops for now. Also, a small test has been added to verify that passes execute in the expected order or not at all if coroutine support is disabled. Patch by Gor Nishanov! Differential Revision: https://reviews.llvm.org/D22847 llvm-svn: 277033
2016-07-29 05:04:31 +08:00
Coroutines
[CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt. llvm-svn: 196908
2013-12-10 19:13:32 +08:00
IPO
IRReader
InstCombine
Instrumentation
MC
ObjCARCOpts
ScalarOpts
Support
Target
TransformUtils
Vectorize
[PM] Create a separate library for high-level pass management code. This will provide the analogous replacements for the PassManagerBuilder and other code long term. This code is extracted from the opt tool currently, and I plan to extend it as I build up support for using the new pass manager in Clang and other places. Mailing this out for review in part to let folks comment on the terrible names here. A brief word about why I chose the names I did. The library is called "Passes" to try and make it clear that it is a high-level utility and where *all* of the passes come together and are registered in a common library. I didn't want it to be *limited* to a registry though, the registry is just one component. The class is a "PassBuilder" but this name I'm less happy with. It doesn't build passes in any traditional sense and isn't a Builder-style API at all. The class is a PassRegisterer or PassAdder, but neither of those really make a lot of sense. This class is responsible for constructing passes for registry in an analysis manager or for population of a pass pipeline. If anyone has a better name, I would love to hear it. The other candidate I looked at was PassRegistrar, but that doesn't really fit either. There is no register of all the passes in use, and so I think continuing the "registry" analog outside of the registry of pass *names* and *types* is a mistake. The objects themselves are just objects with the new pass manager. Differential Revision: http://reviews.llvm.org/D8054 llvm-svn: 231556
2015-03-07 17:02:36 +08:00
Passes
[CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt. llvm-svn: 196908
2013-12-10 19:13:32 +08:00
)
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
Port r198087 and r198089 (strip dead code by default) from make to cmake. llvm-svn: 198198
2013-12-30 11:36:05 +08:00
# Support plugins.
set(LLVM_NO_DEAD_STRIP 1)
Initial support for the CMake build system. llvm-svn: 56419
2008-09-22 09:08:49 +08:00
add_llvm_tool(opt
AnalysisWrappers.cpp
Move more self-contained functionality away from tools/opt/opt.cpp BreakpointPrinter moves to its own module. llvm-svn: 201242
2014-02-13 00:48:02 +08:00
BreakpointPrinter.cpp
Initial support for the CMake build system. llvm-svn: 56419
2008-09-22 09:08:49 +08:00
GraphPrinters.cpp
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
NewPMDriver.cpp
Move the *PassPrinter into their own module. These are self-contained in functionality so it makes sense to separate them, as opt.cpp has grown quite big already. Following Eric's suggestions, if this code is ever deemed useful outside of tools/opt, it will make sense to move it to one of the LLVM libraries like IR. llvm-svn: 201116
2014-02-11 07:34:23 +08:00
PassPrinters.cpp
Initial support for the CMake build system. llvm-svn: 56419
2008-09-22 09:08:49 +08:00
PrintSCC.cpp
opt.cpp
[CMake] opt depends on intrinsics_gen AnalysisWrappers.cpp has the following include chain: llvm/Analysis/CallGraph.h llvm/IR/CallSite.h llvm/IR/Attributes.h llvm/IR/Attributes.gen This means opt needs to depend on intrinsics_gen. llvm-svn: 287433
2016-11-19 11:18:50 +08:00
DEPENDS
intrinsics_gen
Initial support for the CMake build system. llvm-svn: 56419
2008-09-22 09:08:49 +08:00
)
CMake: Disable ENABLE_EXPORTS for executables with MSVC The MSVC linker won't produce a .lib file for an executable that doesn't export anything, and LLVM doesn't maintain dllexport annotations or .def files listing all C++ symbols. It also doesn't support exporting all symbols, like binutils ld. CMake 3.2 changed the Ninja generator to list both the .exe and .lib files as outputs of executable build targets. Ninja would always re-link executables with ENABLE_EXPORTS because the .lib output file was not present, and therefore the target was out of date. llvm-svn: 232662
2015-03-19 04:09:13 +08:00
export_executable_symbols(opt)
static link polly into tools llvm-svn: 203886
2014-03-14 12:04:14 +08:00
if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
target_link_libraries(opt Polly)
endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)