llvm-6502/lib/CMakeLists.txt

# `Support' and `TableGen' libraries are added on the top-level CMakeLists.txt

add_subdirectory(IR)
add_subdirectory(IRReader)
add_subdirectory(CodeGen)
add_subdirectory(Bitcode)
add_subdirectory(Transforms)
add_subdirectory(Linker)
add_subdirectory(Analysis)
add_subdirectory(LTO)
add_subdirectory(MC)
add_subdirectory(Object)
add_subdirectory(Option)
add_subdirectory(DebugInfo)
add_subdirectory(ExecutionEngine)
add_subdirectory(Target)
add_subdirectory(AsmParser)
add_subdirectory(LineEditor)
add_subdirectory(ProfileData)
add_subdirectory(Fuzzer)
add_subdirectory(Passes)
Move TableGen's parser and entry point into a library This is the first step towards splitting LLVM and Clang's tblgen executables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140951 91177308-0d34-0410-b5e6-96231b3b80d8 2011-10-01 16:41:13 +00:00			# `Support' and `TableGen' libraries are added on the top-level CMakeLists.txt
Move library stuff out of the toplevel CMakeLists.txt file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125968 91177308-0d34-0410-b5e6-96231b3b80d8 2011-02-18 22:06:14 +00:00
Rename VMCore directory to IR. Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8 2013-01-02 09:10:48 +00:00			`add_subdirectory(IR)`
Split out the IRReader header and the utility functions it provides into its own library. These functions are bridging between the bitcode reader and the ll parser which are in different libraries. Previously we didn't have any good library to do this, and instead played fast and loose with a "header only" set of interfaces in the Support library. This really doesn't work well as evidenced by the recent attempt to add timing logic to the these routines. As part of this, make them normal functions rather than weird inline functions, and sink the implementation into the library. Also clean up the header to be nice and minimal. This requires updating lots of build system dependencies to specify that the IRReader library is needed, and several source files to not implicitly rely upon the header file to transitively include all manner of other headers. If you are using IRReader.h, this commit will break you (the header moved) and you'll need to also update your library usage to include 'irreader'. I will commit the corresponding change to Clang momentarily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177971 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-26 02:25:37 +00:00			`add_subdirectory(IRReader)`
Move library stuff out of the toplevel CMakeLists.txt file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125968 91177308-0d34-0410-b5e6-96231b3b80d8 2011-02-18 22:06:14 +00:00			`add_subdirectory(CodeGen)`
			`add_subdirectory(Bitcode)`
			`add_subdirectory(Transforms)`
			`add_subdirectory(Linker)`
			`add_subdirectory(Analysis)`
Move LTO support library to a component, allowing it to be tested more reliably across platforms. Patch by Tom Roeder! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191343 91177308-0d34-0410-b5e6-96231b3b80d8 2013-09-24 23:52:22 +00:00			`add_subdirectory(LTO)`
Move library stuff out of the toplevel CMakeLists.txt file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125968 91177308-0d34-0410-b5e6-96231b3b80d8 2011-02-18 22:06:14 +00:00			`add_subdirectory(MC)`
			`add_subdirectory(Object)`
Copy clang/Driver/<Option parsing stuff> to llvm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169344 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-05 00:29:32 +00:00			`add_subdirectory(Option)`
Sketch out a DWARF parser. This introduces a new library to LLVM: libDebugInfo. It will provide debug information parsing to LLVM. Much of the design and some of the code is taken from the LLDB project. It also contains an llvm-dwarfdump tool that can dump the abbrevs and DIEs from an object file. It can be used to write tests for DWARF input and output easily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139627 91177308-0d34-0410-b5e6-96231b3b80d8 2011-09-13 19:42:23 +00:00			`add_subdirectory(DebugInfo)`
Move library stuff out of the toplevel CMakeLists.txt file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125968 91177308-0d34-0410-b5e6-96231b3b80d8 2011-02-18 22:06:14 +00:00			`add_subdirectory(ExecutionEngine)`
			`add_subdirectory(Target)`
			`add_subdirectory(AsmParser)`
Introduce line editor library. This library will be used by clang-query. I can imagine LLDB becoming another client of this library, so I think LLVM is a sensible place for it to live. It wraps libedit, and adds tab completion support. The code is loosely based on the line editor bits in LLDB, with a few improvements: - Polymorphism for retrieving the list of tab completions, based on the concept pattern from the new pass manager. - Tab completion doesn't corrupt terminal output if the input covers multiple lines. Unfortunately this can only be done in a truly horrible way, as far as I can tell. But since the alternative is to implement our own line editor (which I don't think LLVM should be in the business of doing, at least for now) I think it may be acceptable. - Includes a fallback for the case where the user doesn't have libedit installed. Note that this uses C stdio, mainly because libedit also uses C stdio. Differential Revision: http://llvm-reviews.chandlerc.com/D2200 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200595 91177308-0d34-0410-b5e6-96231b3b80d8 2014-01-31 23:46:14 +00:00			`add_subdirectory(LineEditor)`
ProfileData: Introduce the InstrProfReader interface and a text reader This introduces the ProfileData library and updates llvm-profdata to use this library for reading profiles. InstrProfReader is an abstract base class that will be subclassed for both the raw instrprof data from compiler-rt and the efficient instrprof format that will be used for PGO. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204482 91177308-0d34-0410-b5e6-96231b3b80d8 2014-03-21 17:24:48 +00:00			`add_subdirectory(ProfileData)`
Reverting r227452, which adds back the fuzzer library. Now excluding the fuzzer library based on LLVM_USE_SANITIZE_COVERAGE being set or unset. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227464 91177308-0d34-0410-b5e6-96231b3b80d8 2015-01-29 16:58:29 +00:00			`add_subdirectory(Fuzzer)`
[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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231556 91177308-0d34-0410-b5e6-96231b3b80d8 2015-03-07 09:02:36 +00:00			`add_subdirectory(Passes)`