summaryrefslogtreecommitdiff
path: root/lib/Transforms/Scalar/CMakeLists.txt
Commit message (Collapse)AuthorAge
* Move GlobalMerge from Transform to CodeGen.Jiangning Liu2014-06-13
| | | | | | | | | | | This patch is to move GlobalMerge pass from Transform/Scalar to CodeGen, because GlobalMerge depends on TargetMachine. In the mean time, the macro INITIALIZE_TM_PASS is also moved to CodeGen/Passes.h. With this fix we can avoid making libScalarOpts depend on libCodeGen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210951 91177308-0d34-0410-b5e6-96231b3b80d8
* Add LoadCombine pass.Michael J. Spencer2014-05-29
| | | | | | | | This pass is disabled by default. Use -combine-loads to enable in -O[1-3] Differential revision: http://reviews.llvm.org/D3580 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209791 91177308-0d34-0410-b5e6-96231b3b80d8
* Update and sort CMakeLists.Benjamin Kramer2014-05-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207785 91177308-0d34-0410-b5e6-96231b3b80d8
* [CodeGenPrepare] Move CodeGenPrepare into lib/CodeGen.Quentin Colombet2014-02-22
| | | | | | | | | | | | | 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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201912 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Revert "Add Constant Hoisting Pass" (r200034)"Juergen Ributzka2014-01-25
| | | | | | | This reverts commit r200058 and adds the using directive for ARMTargetTransformInfo to silence two g++ overload warnings. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200062 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Add Constant Hoisting Pass" (r200034)Hans Wennborg2014-01-25
| | | | | | | | | | | | | | | This commit caused -Woverloaded-virtual warnings. The two new TargetTransformInfo::getIntImmCost functions were only added to the superclass, and to the X86 subclass. The other targets were not updated, and the warning highlighted this by pointing out that e.g. ARMTTI::getIntImmCost was hiding the two new getIntImmCost variants. We could pacify the warning by adding "using TargetTransformInfo::getIntImmCost" to the various subclasses, or turning it off, but I suspect that it's wrong to leave the functions unimplemnted in those targets. The default implementations return TCC_Free, which I don't think is right e.g. for ARM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200058 91177308-0d34-0410-b5e6-96231b3b80d8
* Add Constant Hoisting PassJuergen Ributzka2014-01-24
| | | | | | | | Retry commit r200022 with a fix for the build bot errors. Constant expressions have (unlike instructions) module scope use lists and therefore may have users in different functions. The fix is to simply ignore these out-of-function uses. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200034 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Add Constant Hoisting Pass"Juergen Ributzka2014-01-24
| | | | | | This reverts commit r200022 to unbreak the build bots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200024 91177308-0d34-0410-b5e6-96231b3b80d8
* Add Constant Hoisting PassJuergen Ributzka2014-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass identifies expensive constants to hoist and coalesces them to better prepare it for SelectionDAG-based code generation. This works around the limitations of the basic-block-at-a-time approach. First it scans all instructions for integer constants and calculates its cost. If the constant can be folded into the instruction (the cost is TCC_Free) or the cost is just a simple operation (TCC_BASIC), then we don't consider it expensive and leave it alone. This is the default behavior and the default implementation of getIntImmCost will always return TCC_Free. If the cost is more than TCC_BASIC, then the integer constant can't be folded into the instruction and it might be beneficial to hoist the constant. Similar constants are coalesced to reduce register pressure and materialization code. When a constant is hoisted, it is also hidden behind a bitcast to force it to be live-out of the basic block. Otherwise the constant would be just duplicated and each basic block would have its own copy in the SelectionDAG. The SelectionDAG recognizes such constants as opaque and doesn't perform certain transformations on them, which would create a new expensive constant. This optimization is only applied to integer constants in instructions and simple (this means not nested) constant cast experessions. For example: %0 = load i64* inttoptr (i64 big_constant to i64*) Reviewed by Eric git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200022 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a Scalarizer pass.Richard Sandiford2013-11-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195471 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a loop rerolling passHal Finkel2013-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The transformation aims to take loops like this: for (int i = 0; i < 3200; i += 5) { a[i] += alpha * b[i]; a[i + 1] += alpha * b[i + 1]; a[i + 2] += alpha * b[i + 2]; a[i + 3] += alpha * b[i + 3]; a[i + 4] += alpha * b[i + 4]; } and turn them into this: for (int i = 0; i < 3200; ++i) { a[i] += alpha * b[i]; } and loops like this: for (int i = 0; i < 500; ++i) { x[3*i] = foo(0); x[3*i+1] = foo(0); x[3*i+2] = foo(0); } and turn them into this: for (int i = 0; i < 1500; ++i) { x[i] = foo(0); } There are two motivations for this transformation: 1. Code-size reduction (especially relevant, obviously, when compiling for code size). 2. Providing greater choice to the loop vectorizer (and generic unroller) to choose the unrolling factor (and a better ability to vectorize). The loop vectorizer can take vector lengths and register pressure into account when choosing an unrolling factor, for example, and a pre-unrolled loop limits that choice. This is especially problematic if the manual unrolling was optimized for a machine different from the current target. The current implementation is limited to single basic-block loops only. The rerolling recognition should work regardless of how the loop iterations are intermixed within the loop body (subject to dependency and side-effect constraints), but the significant restriction is that the order of the instructions in each iteration must be identical. This seems sufficient to capture all current use cases. This pass is not currently enabled by default at any optimization level. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194939 91177308-0d34-0410-b5e6-96231b3b80d8
* SampleProfileLoader pass. Initial setup.Diego Novillo2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new scalar pass that reads a file with samples generated by 'perf' during runtime. The samples read from the profile are incorporated and emmited as IR metadata reflecting that profile. The profile file is assumed to have been generated by an external profile source. The profile information is converted into IR metadata, which is later used by the analysis routines to estimate block frequencies, edge weights and other related data. External profile information files have no fixed format, each profiler is free to define its own. This includes both the on-disk representation of the profile and the kind of profile information stored in the file. A common kind of profile is based on sampling (e.g., perf), which essentially counts how many times each line of the program has been executed during the run. The SampleProfileLoader pass is organized as a scalar transformation. On startup, it reads the file given in -sample-profile-file to determine what kind of profile it contains. This file is assumed to contain profile information for the whole application. The profile data in the file is read and incorporated into the internal state of the corresponding profiler. To facilitate testing, I've organized the profilers to support two file formats: text and native. The native format is whatever on-disk representation the profiler wants to support, I think this will mostly be bitcode files, but it could be anything the profiler wants to support. To do this, every profiler must implement the SampleProfile::loadNative() function. The text format is mostly meant for debugging. Records are separated by newlines, but each profiler is free to interpret records as it sees fit. Profilers must implement the SampleProfile::loadText() function. Finally, the pass will call SampleProfile::emitAnnotations() for each function in the current translation unit. This function needs to translate the loaded profile into IR metadata, which the analyzer will later be able to use. This patch implements the first steps towards the above design. I've implemented a sample-based flat profiler. The format of the profile is fairly simplistic. Each sampled function contains a list of relative line locations (from the start of the function) together with a count representing how many samples were collected at that line during execution. I generate this profile using perf and a separate converter tool. Currently, I have only implemented a text format for these profiles. I am interested in initial feedback to the whole approach before I send the other parts of the implementation for review. This patch implements: - The SampleProfileLoader pass. - The base ExternalProfile class with the core interface. - A SampleProfile sub-class using the above interface. The profiler generates branch weight metadata on every branch instructions that matches the profiles. - A text loader class to assist the implementation of SampleProfile::loadText(). - Basic unit tests for the pass. Additionally, the patch uses profile information to compute branch weights based on instruction samples. This patch converts instruction samples into branch weights. It does a fairly simplistic conversion: Given a multi-way branch instruction, it calculates the weight of each branch based on the maximum sample count gathered from each target basic block. Note that this assignment of branch weights is somewhat lossy and can be misleading. If a basic block has more than one incoming branch, all the incoming branches will get the same weight. In reality, it may be that only one of them is the most heavily taken branch. I will adjust this assignment in subsequent patches. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194566 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the long, long defunct IR block placement pass.Chandler Carruth2013-09-14
| | | | | | | | | | | | | | | | | This pass was based on the previous (essentially unused) profiling infrastructure and the assumption that by ordering the basic blocks at the IR level in a particular way, the correct layout would happen in the end. This sometimes worked, and mostly didn't. It also was a really naive implementation of the classical paper that dates from when branch predictors were primarily directional and when loop structure wasn't commonly available. It also didn't factor into the equation non-fallthrough branches and other machine level details. Anyways, for all of these reasons and more, I wrote MachineBlockPlacement, which completely supercedes this pass. It both uses modern profile information infrastructure, and actually works. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190748 91177308-0d34-0410-b5e6-96231b3b80d8
* Turn MipsOptimizeMathLibCalls into a target-independent scalar transformRichard Sandiford2013-08-23
| | | | | | | | | | | ...so that it can be used for z too. Most of the code is the same. The only real change is to use TargetTransformInfo to test when a sqrt instruction is available. The pass is opt-in because at the moment it only handles sqrt. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189097 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor FlattenCFG out from SimplifyCFGTom Stellard2013-08-06
| | | | | | Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the simplify-libcalls pass (finally)Meador Inge2013-06-20
| | | | | | | | | | | This commit completely removes what is left of the simplify-libcalls pass. All of the functionality has now been migrated to the instcombine and functionattrs passes. The following C API functions are now NOPs: 1. LLVMAddSimplifyLibCallsPass 2. LLVMPassManagerBuilderSetDisableSimplifyLibCalls git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184459 91177308-0d34-0410-b5e6-96231b3b80d8
* Move StructurizeCFG out of R600 to generic Transforms.Matt Arsenault2013-06-19
| | | | | | Register it with PassManager git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184343 91177308-0d34-0410-b5e6-96231b3b80d8
* Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation ↵Michael Gottesman2013-01-28
| | | | | | for refactoring the ARC Optimizer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173647 91177308-0d34-0410-b5e6-96231b3b80d8
* Introduce a new SROA implementation.Chandler Carruth2012-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is essentially a ground up re-think of the SROA pass in LLVM. It was initially inspired by a few problems with the existing pass: - It is subject to the bane of my existence in optimizations: arbitrary thresholds. - It is overly conservative about which constructs can be split and promoted. - The vector value replacement aspect is separated from the splitting logic, missing many opportunities where splitting and vector value formation can work together. - The splitting is entirely based around the underlying type of the alloca, despite this type often having little to do with the reality of how that memory is used. This is especially prevelant with unions and base classes where we tail-pack derived members. - When splitting fails (often due to the thresholds), the vector value replacement (again because it is separate) can kick in for preposterous cases where we simply should have split the value. This results in forming i1024 and i2048 integer "bit vectors" that tremendously slow down subsequnet IR optimizations (due to large APInts) and impede the backend's lowering. The new design takes an approach that fundamentally is not susceptible to many of these problems. It is the result of a discusison between myself and Duncan Sands over IRC about how to premptively avoid these types of problems and how to do SROA in a more principled way. Since then, it has evolved and grown, but this remains an important aspect: it fixes real world problems with the SROA process today. First, the transform of SROA actually has little to do with replacement. It has more to do with splitting. The goal is to take an aggregate alloca and form a composition of scalar allocas which can replace it and will be most suitable to the eventual replacement by scalar SSA values. The actual replacement is performed by mem2reg (and in the future SSAUpdater). The splitting is divided into four phases. The first phase is an analysis of the uses of the alloca. This phase recursively walks uses, building up a dense datastructure representing the ranges of the alloca's memory actually used and checking for uses which inhibit any aspects of the transform such as the escape of a pointer. Once we have a mapping of the ranges of the alloca used by individual operations, we compute a partitioning of the used ranges. Some uses are inherently splittable (such as memcpy and memset), while scalar uses are not splittable. The goal is to build a partitioning that has the minimum number of splits while placing each unsplittable use in its own partition. Overlapping unsplittable uses belong to the same partition. This is the target split of the aggregate alloca, and it maximizes the number of scalar accesses which become accesses to their own alloca and candidates for promotion. Third, we re-walk the uses of the alloca and assign each specific memory access to all the partitions touched so that we have dense use-lists for each partition. Finally, we build a new, smaller alloca for each partition and rewrite each use of that partition to use the new alloca. During this phase the pass will also work very hard to transform uses of an alloca into a form suitable for promotion, including forming vector operations, speculating loads throguh PHI nodes and selects, etc. After splitting is complete, each newly refined alloca that is a candidate for promotion to a scalar SSA value is run through mem2reg. There are lots of reasonably detailed comments in the source code about the design and algorithms, and I'm going to be trying to improve them in subsequent commits to ensure this is well documented, as the new pass is in many ways more complex than the old one. Some of this is still a WIP, but the current state is reasonbly stable. It has passed bootstrap, the nightly test suite, and Duncan has run it successfully through the ACATS and DragonEgg test suites. That said, it remains behind a default-off flag until the last few pieces are in place, and full testing can be done. Specific areas I'm looking at next: - Improved comments and some code cleanup from reviews. - SSAUpdater and enabling this pass inside the CGSCC pass manager. - Some datastructure tuning and compile-time measurements. - More aggressive FCA splitting and vector formation. Many thanks to Duncan Sands for the thorough final review, as well as Benjamin Kramer for lots of review during the process of writing this pass, and Daniel Berlin for reviewing the data structures and algorithms and general theory of the pass. Also, several other people on IRC, over lunch tables, etc for lots of feedback and advice. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163883 91177308-0d34-0410-b5e6-96231b3b80d8
* move the bounds checking pass to the instrumentation folder, where it ↵Nuno Lopes2012-07-20
| | | | | | | | belongs. I dunno why in the world I dropped it in the Scalar folder in the first place. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160587 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/lib: [CMake] Add explicit dependency to intrinsics_gen.NAKAMURA Takumi2012-06-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159112 91177308-0d34-0410-b5e6-96231b3b80d8
* hopefully fix the CMake build. sorry for breakageNuno Lopes2012-05-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157264 91177308-0d34-0410-b5e6-96231b3b80d8
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145420 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix CMake build.Michael J. Spencer2011-10-17
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142204 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the old tail duplication pass. It is not used and is unable to updateRafael Espindola2011-08-30
| | | | | | | ssa, so it has to be run really early in the pipeline. Any replacement should probably use the SSAUpdater. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138841 91177308-0d34-0410-b5e6-96231b3b80d8
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
* The ARC language-specific optimizer. Credit to Dan Gohman.John McCall2011-06-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133108 91177308-0d34-0410-b5e6-96231b3b80d8
* Unbreak CMake build.Ted Kremenek2011-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126715 91177308-0d34-0410-b5e6-96231b3b80d8
* update cmakeChris Lattner2011-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126694 91177308-0d34-0410-b5e6-96231b3b80d8
* CMake: Add missing source file.Michael J. Spencer2011-01-03
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122724 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a new loop-instsimplify pass, with the intention of replacing the instanceCameron Zwarich2011-01-03
| | | | | | | | of instcombine that is currently in the middle of the loop pass pipeline. This commit only checks in the pass; it will hopefully be enabled by default later. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122719 91177308-0d34-0410-b5e6-96231b3b80d8
* Start of a pass for recognizing memset and memcpy idioms.Chris Lattner2010-12-26
| | | | | | | No functionality yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122562 91177308-0d34-0410-b5e6-96231b3b80d8
* Update CMake.Daniel Dunbar2010-10-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116034 91177308-0d34-0410-b5e6-96231b3b80d8
* Removed a bunch of unnecessary target_link_libraries.Oscar Fuentes2010-09-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114999 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally."Michael J. Spencer2010-09-13
| | | | | | | | | | This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113819 91177308-0d34-0410-b5e6-96231b3b80d8
* CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally.Michael J. Spencer2010-09-10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113632 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename file to something more descriptive.Owen Anderson2010-08-31
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112590 91177308-0d34-0410-b5e6-96231b3b80d8
* remove the ABCD and SSI passes. They don't have any clients thatChris Lattner2010-08-28
| | | | | | | | I'm aware of, aren't maintained, and LVI will be replacing their value. nlewycky approved this on irc. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112355 91177308-0d34-0410-b5e6-96231b3b80d8
* Update CMake build. Add newline at end of file.Benjamin Kramer2010-08-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112332 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an atomic lowering passPeter Collingbourne2010-08-03
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110113 91177308-0d34-0410-b5e6-96231b3b80d8
* Update CMake build.Ted Kremenek2010-05-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103266 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove SCCVN from the CMake build system.Owen Anderson2010-04-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101125 91177308-0d34-0410-b5e6-96231b3b80d8
* Pull these back out, they're a little too aggressive and timeEric Christopher2010-02-09
| | | | | | | consuming for a simple optimization. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95671 91177308-0d34-0410-b5e6-96231b3b80d8
* Add file in here too.Eric Christopher2010-02-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95641 91177308-0d34-0410-b5e6-96231b3b80d8
* move instcombine to its own library, it's past time.Chris Lattner2010-01-04
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92459 91177308-0d34-0410-b5e6-96231b3b80d8
* remove the now dead condprop pass, PR3906.Chris Lattner2009-11-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86810 91177308-0d34-0410-b5e6-96231b3b80d8
* Update CMakeLists for recent renames.Dan Gohman2009-10-31
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85660 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove CodeGenLICM. It's largely obsoleted by MachineLICM's new abilityDan Gohman2009-10-31
| | | | | | | to unfold loop-invariant loads. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85657 91177308-0d34-0410-b5e6-96231b3b80d8
* Update CMake file.Benjamin Kramer2009-10-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85389 91177308-0d34-0410-b5e6-96231b3b80d8
* VS build fix, patch by Marius Wachtler.Mike Stump2009-10-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85197 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 23:03:10 +0000