summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Make most target symbols hidden by defaultTom Stellard2020-01-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default. A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions. This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked. Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278 Reviewers: chandlerc, beanz, mgorny, rnk, hans Reviewed By: rnk, hans Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D54439
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert CMake: Make most target symbols hidden by defaultTom Stellard2019-06-111-8/+0
| | | | | | | | | | | | | | | This reverts r362990 (git commit 374571301dc8e9bc9fdd1d70f86015de198673bd) This was causing linker warnings on Darwin: ld: warning: direct access in function 'llvm::initializeEvexToVexInstPassPass(llvm::PassRegistry&)' from file '../../lib/libLLVMX86CodeGen.a(X86EvexToVex.cpp.o)' to global weak symbol 'void std::__1::__call_once_proxy<std::__1::tuple<void* (&)(llvm::PassRegistry&), std::__1::reference_wrapper<llvm::PassRegistry>&&> >(void*)' from file '../../lib/libLLVMCore.a(Verifier.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. llvm-svn: 363028
* CMake: Make most target symbols hidden by defaultTom Stellard2019-06-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default. A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions. This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked. Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278 Reviewers: chandlerc, beanz, mgorny, rnk, hans Reviewed By: rnk, hans Subscribers: Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D54439 llvm-svn: 362990
* Revert "TargetMachine: Merge TargetMachine and LLVMTargetMachine"Matthias Braun2017-10-121-0/+2
| | | | | | | | | | Reverting to investigate layering effects of MCJIT not linking libCodeGen but using TargetMachine::getNameWithPrefix() breaking the lldb bots. This reverts commit r315633. llvm-svn: 315637
* TargetMachine: Merge TargetMachine and LLVMTargetMachineMatthias Braun2017-10-121-2/+0
| | | | | | | | | | | | | | | Merge LLVMTargetMachine into TargetMachine. - There is no in-tree target anymore that just implements TargetMachine but not LLVMTargetMachine. - It should still be possible to stub out all the various functions in case a target does not want to use lib/CodeGen - This simplifies the code and avoids methods ending up in the wrong interface. Differential Revision: https://reviews.llvm.org/D38489 llvm-svn: 315633
* [CMake] Fix `is_llvm_target_library` and support out-of-order componentsChris Bieneman2017-02-081-0/+6
| | | | | | | | | | | | Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
* [CMake] Cleanup TableGen include flagsChris Bieneman2016-12-061-0/+2
| | | | | | | | | | It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool. This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories. This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR. llvm-svn: 288770
* TargetSubtargetInfo: Move implementation to lib/CodeGen; NFCMatthias Braun2016-11-221-1/+0
| | | | | | | | | | | | TargetSubtargetInfo is filled with CodeGen specific interfaces nowadays (getInstrInfo(), getFrameLowering(), getSelectionDAGInfo()) most of the tuning flags like enablePostRAScheduler(), getAntiDepBreakMode(), enableRALocalReassignment(), ... also do not seem to be universal enough to make sense outside of CodeGen. Differential Revision: https://reviews.llvm.org/D26948 llvm-svn: 287708
* [Target] remove TargetRecip class; 2nd trySanjay Patel2016-10-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a retry of r284495 which was reverted at r284513 due to use-after-scope bugs caused by faulty usage of StringRef. This version also renames a pair of functions: getRecipEstimateDivEnabled() getRecipEstimateSqrtEnabled() as suggested by Eric Christopher. original commit msg: [Target] remove TargetRecip class; move reciprocal estimate isel functionality to TargetLowering This is a follow-up to https://reviews.llvm.org/D24816 - where we changed reciprocal estimates to be function attributes rather than TargetOptions. This patch is intended to be a structural, but not functional change. By moving all of the TargetRecip functionality into TargetLowering, we can remove all of the reciprocal estimate state, shield the callers from the string format implementation, and simplify/localize the logic needed for a target to enable this. If a function has a "reciprocal-estimates" attribute, those settings may override the target's default reciprocal preferences for whatever operation and data type we're trying to optimize. If there's no attribute string or specific setting for the op/type pair, just use the target default settings. As noted earlier, a better solution would be to move the reciprocal estimate settings to IR instructions and SDNodes rather than function attributes, but that's a multi-step job that requires infrastructure improvements. I intend to work on that, but it's not clear how long it will take to get all the pieces in place. Differential Revision: https://reviews.llvm.org/D25440 llvm-svn: 284746
* revert r284495: [Target] remove TargetRecip classSanjay Patel2016-10-181-0/+1
| | | | | | There's something wrong with the StringRef usage while parsing the attribute string. llvm-svn: 284513
* [Target] remove TargetRecip class; move reciprocal estimate isel ↵Sanjay Patel2016-10-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | functionality to TargetLowering This is a follow-up to D24816 - where we changed reciprocal estimates to be function attributes rather than TargetOptions. This patch is intended to be a structural, but not functional change. By moving all of the TargetRecip functionality into TargetLowering, we can remove all of the reciprocal estimate state, shield the callers from the string format implementation, and simplify/localize the logic needed for a target to enable this. If a function has a "reciprocal-estimates" attribute, those settings may override the target's default reciprocal preferences for whatever operation and data type we're trying to optimize. If there's no attribute string or specific setting for the op/type pair, just use the target default settings. As noted earlier, a better solution would be to move the reciprocal estimate settings to IR instructions and SDNodes rather than function attributes, but that's a multi-step job that requires infrastructure improvements. I intend to work on that, but it's not clear how long it will take to get all the pieces in place. Differential Revision: https://reviews.llvm.org/D25440 llvm-svn: 284495
* make reciprocal estimate code generation more flexible by adding ↵Sanjay Patel2015-06-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | command-line options (3rd try) The first try (r238051) to land this was reverted due to ExecutionEngine build failure; that was hopefully addressed by r238788. The second try (r238842) to land this was reverted due to BUILD_SHARED_LIBS failure; that was hopefully addressed by r238953. This patch adds a TargetRecip class for processing many recip codegen possibilities. The class is intended to handle both command-line options to llc as well as options passed in from a front-end such as clang with the -mrecip option. The x86 backend is updated to use the new functionality. Only -mcpu=btver2 with -ffast-math should see a functional change from this patch. All other x86 CPUs continue to *not* use reciprocal estimates by default with -ffast-math. Differential Revision: http://reviews.llvm.org/D8982 llvm-svn: 239001
* Revert "make reciprocal estimate code generation more flexible by adding ↵Rafael Espindola2015-06-031-1/+0
| | | | | | | | | | command-line options (2nd try)" This reverts commit r238842. It broke -DBUILD_SHARED_LIBS=ON build. llvm-svn: 238900
* make reciprocal estimate code generation more flexible by adding ↵Sanjay Patel2015-06-021-0/+1
| | | | | | | | | | | | | | | | | | | command-line options (2nd try) The first try (r238051) to land this was reverted due to bot failures that were hopefully addressed by r238788. This patch adds a TargetRecip class for processing many recip codegen possibilities. The class is intended to handle both command-line options to llc as well as options passed in from a front-end such as clang with the -mrecip option. The x86 backend is updated to use the new functionality. Only -mcpu=btver2 with -ffast-math should see a functional change from this patch. All other x86 CPUs continue to *not* use reciprocal estimates by default with -ffast-math. Differential Revision: http://reviews.llvm.org/D8982 llvm-svn: 238842
* Revert "make reciprocal estimate code generation more flexible by adding ↵Rafael Espindola2015-05-231-1/+0
| | | | | | | | | | | | command-line options" This reverts commit r238051. It broke some bots: http://lab.llvm.org:8011/builders/llvm-ppc64-linux1/builds/18190 llvm-svn: 238075
* make reciprocal estimate code generation more flexible by adding ↵Sanjay Patel2015-05-221-0/+1
| | | | | | | | | | | | | | | | command-line options This patch adds a class for processing many recip codegen possibilities. The TargetRecip class is intended to handle both command-line options to llc as well as options passed in from a front-end such as clang with the -mrecip option. The x86 backend is updated to use the new functionality. Only -mcpu=btver2 with -ffast-math should see a functional change from this patch. All other CPUs continue to *not* use reciprocal estimates by default with -ffast-math. Differential Revision: http://reviews.llvm.org/D8982 llvm-svn: 238051
* Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner2015-02-111-0/+3
| | | | | | | | | | This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
* [CMake] LLVMTarget requires Intrinsics.gen since r227669 introduced ↵NAKAMURA Takumi2015-02-011-2/+2
| | | | | | llvm/Analysis/TargetTransformInfo.h. llvm-svn: 227699
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+0
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-021-1/+0
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-071-0/+1
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Nuke the old JIT.Rafael Espindola2014-08-071-1/+0
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* [CMake] Move intrinsics_gen to lib/Target out of add_public_tablegen_target.NAKAMURA Takumi2014-02-201-0/+2
| | | | | | add_public_tablegen_target is used somewhere. llvm-svn: 201787
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-071-1/+0
| | | | | | This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
* Revert "Add AllTargetsBindings sublibrary" as it breaks cmake build on ↵Anders Waldenborg2013-10-151-2/+0
| | | | | | (atleast) windows and darwin. llvm-svn: 192697
* Add AllTargetsBindings sublibrary instead of having static inlines in the ↵Anders Waldenborg2013-10-151-0/+2
| | | | | | | | | | | | | llvm-c headers. This new library will be linked in when using the "all-targets" component and contains the LLVMInitializeAll* functions. This means that those functions will exist as real symbols in the shared library, and can therefore can be called from bindings that are using ffi the shared library. llvm-svn: 192690
* Revert "llvm-c: Make target initializer functions external functions in lib."Rui Ueyama2013-10-091-1/+0
| | | | | | | | This reverts commit r192316. The original change introduced circular dependencies between libTarget and backends. That would broke a build unless link everything into one big binary. llvm-svn: 192329
* llvm-c: Make target initializer functions external functions in lib.Anders Waldenborg2013-10-091-0/+1
| | | | | | | | | | | | | Making them proper functions defined in the (shared)lib instead of static inlines defined in the header files makes it possible to actually distribute a binary compiled against the shared library without having to worry about getting undefined symbol errors when calling e.g LLVMInitializeAllTargetInfos because the shared library on the other system was compiled with different targets. Differential Revision: http://llvm-reviews.chandlerc.com/D1714 llvm-svn: 192316
* Switch TargetTransformInfo from an immutable analysis pass that requiresChandler Carruth2013-01-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a TargetMachine to construct (and thus isn't always available), to an analysis group that supports layered implementations much like AliasAnalysis does. This is a pretty massive change, with a few parts that I was unable to easily separate (sorry), so I'll walk through it. The first step of this conversion was to make TargetTransformInfo an analysis group, and to sink the nonce implementations in ScalarTargetTransformInfo and VectorTargetTranformInfo into a NoTargetTransformInfo pass. This allows other passes to add a hard requirement on TTI, and assume they will always get at least on implementation. The TargetTransformInfo analysis group leverages the delegation chaining trick that AliasAnalysis uses, where the base class for the analysis group delegates to the previous analysis *pass*, allowing all but tho NoFoo analysis passes to only implement the parts of the interfaces they support. It also introduces a new trick where each pass in the group retains a pointer to the top-most pass that has been initialized. This allows passes to implement one API in terms of another API and benefit when some other pass above them in the stack has more precise results for the second API. The second step of this conversion is to create a pass that implements the TargetTransformInfo analysis using the target-independent abstractions in the code generator. This replaces the ScalarTargetTransformImpl and VectorTargetTransformImpl classes in lib/Target with a single pass in lib/CodeGen called BasicTargetTransformInfo. This class actually provides most of the TTI functionality, basing it upon the TargetLowering abstraction and other information in the target independent code generator. The third step of the conversion adds support to all TargetMachines to register custom analysis passes. This allows building those passes with access to TargetLowering or other target-specific classes, and it also allows each target to customize the set of analysis passes desired in the pass manager. The baseline LLVMTargetMachine implements this interface to add the BasicTTI pass to the pass manager, and all of the tools that want to support target-aware TTI passes call this routine on whatever target machine they end up with to add the appropriate passes. The fourth step of the conversion created target-specific TTI analysis passes for the X86 and ARM backends. These passes contain the custom logic that was previously in their extensions of the ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces. I separated them into their own file, as now all of the interface bits are private and they just expose a function to create the pass itself. Then I extended these target machines to set up a custom set of analysis passes, first adding BasicTTI as a fallback, and then adding their customized TTI implementations. The fourth step required logic that was shared between the target independent layer and the specific targets to move to a different interface, as they no longer derive from each other. As a consequence, a helper functions were added to TargetLowering representing the common logic needed both in the target implementation and the codegen implementation of the TTI pass. While technically this is the only change that could have been committed separately, it would have been a nightmare to extract. The final step of the conversion was just to delete all the old boilerplate. This got rid of the ScalarTargetTransformInfo and VectorTargetTransformInfo classes, all of the support in all of the targets for producing instances of them, and all of the support in the tools for manually constructing a pass based around them. Now that TTI is a relatively normal analysis group, two things become straightforward. First, we can sink it into lib/Analysis which is a more natural layer for it to live. Second, clients of this interface can depend on it *always* being available which will simplify their code and behavior. These (and other) simplifications will follow in subsequent commits, this one is clearly big enough. Finally, I'm very aware that much of the comments and documentation needs to be updated. As soon as I had this working, and plausibly well commented, I wanted to get it committed and in front of the build bots. I'll be doing a few passes over documentation later if it sticks. Commits to update DragonEgg and Clang will be made presently. llvm-svn: 171681
* Move Target{Instr,Register}Info.cpp into lib/CodeGen.Jakob Stoklund Olesen2012-11-281-2/+0
| | | | | | | | | | | | | | | | The Target library is not allowed to depend on the large CodeGen library, but the TRI and TII classes provide abstract interfaces that require both caller and callee to link to CodeGen. The implementation files for these classes provide default implementations of some of the hooks. These methods may need to reference CodeGen, so they belong in that library. We already have a number of methods implemented in the TargetInstrInfoImpl sub-class because of that. I will merge that class into the parent next. llvm-svn: 168758
* Remove TargetELFWriterInfo.Rafael Espindola2012-10-281-1/+0
| | | | | | All the credit goes to Jan Voung for noticing it was dead! llvm-svn: 166902
* Reapply the TargerTransformInfo changes, minus the changes to LSR and ↵Nadav Rotem2012-10-181-0/+1
| | | | | | Lowerinvoke. llvm-svn: 166248
* Temporarily revert the TargetTransform changes.Bob Wilson2012-10-181-1/+0
| | | | | | | | | | | The TargetTransform changes are breaking LTO bootstraps of clang. I am working with Nadav to figure out the problem, but I am reverting it for now to get our buildbots working. This reverts svn commits: 165665 165669 165670 165786 165787 165997 and I have also reverted clang svn 165741 llvm-svn: 166168
* Add a new interface to allow IR-level passes to access codegen-specific ↵Nadav Rotem2012-10-101-0/+1
| | | | | | information. llvm-svn: 165665
* Implement TargetData with the DataLayout class, this will allow LLVM ↵Micah Villmow2012-10-051-1/+0
| | | | | | projects to transition to DataLayout without loosing functionality. llvm-svn: 165318
* Add a C binding to the Target and TargetMachine classes to allow for emittingDuncan Sands2012-04-111-0/+1
| | | | | | | binary and assembly. Patch by Carlo Kok. Emitting was inspired by but not based on the D llvm bindings. llvm-svn: 154493
* Fix up the CMake build for the new files added in r146960, they'reChandler Carruth2011-12-201-0/+1
| | | | | | likely to stay either way that discussion ends up resolving itself. llvm-svn: 146966
* Move parts of lib/Target that use CodeGen into lib/CodeGen.Nick Lewycky2011-12-151-2/+0
| | | | llvm-svn: 146702
* Refactor the implementation of the TargetOptions out of TargetMachine, takingNick Lewycky2011-12-101-0/+1
| | | | | | the only parts of TM that depends on CodeGen headers with it. llvm-svn: 146334
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-6/+0
| | | | llvm-svn: 145420
* build/cmake: Coalesce the configuration time header include fragment generationDaniel Dunbar2011-11-041-36/+1
| | | | | | for target definitions. llvm-svn: 143731
* Move TargetRegistry and TargetSelect from Target to Support where they belong.Evan Cheng2011-08-241-1/+0
| | | | | | These are strictly utilities for registering targets and components. llvm-svn: 138450
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Move TargetAsmParser.h TargetAsmBackend.h and TargetAsmLexer.h to MC where ↵Evan Cheng2011-07-231-1/+0
| | | | | | they belong. llvm-svn: 135833
* Move TargetRegistry.cpp from lib/Support to lib/Target where it belongs.Chandler Carruth2011-07-221-0/+1
| | | | | | | | | | | | | | The header file was already properly located. The previous need for it in Support had to do with the version string printing which was fixed in r135757. Also update build dependencies where libraries that needed the functionality of the Target library (in the form of the TargetRegistry) were picking it up via Support. This is pretty pervasive, essentially every TargetInfo library (ARMInfo, etc) uses TargetRegistry, making it depend on Target. All of these were previously just sneaking by. llvm-svn: 135760
* Fix cmake again :)Benjamin Kramer2011-07-201-1/+0
| | | | llvm-svn: 135613
* Revert accidental commit.Evan Cheng2011-07-091-6/+0
| | | | llvm-svn: 134800
* Change createAsmParser to take a MCSubtargetInfo instead of triple,Evan Cheng2011-07-091-0/+6
| | | | | | | | | CPU, and feature string. Parsing some asm directives can change subtarget state (e.g. .code 16) and it must be reflected in other modules (e.g. MCCodeEmitter). That is, the MCSubtargetInfo instance must be shared. llvm-svn: 134795
* Rename TargetSubtarget to TargetSubtargetInfo for consistency.Evan Cheng2011-07-011-1/+1
| | | | llvm-svn: 134259
OpenPOWER on IntegriCloud