| cd81d94322a39503e4a3e87b6ee03d4fcb3465fb |
|
21-Jul-2014 |
Stephen Hines <srhines@google.com> |
Update LLVM for rebase to r212749.
Includes a cherry-pick of:
r212948 - fixes a small issue with atomic calls
Change-Id: Ib97bd980b59f18142a69506400911a6009d9df18
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| dce4a407a24b04eebc6a376f8e62b41aaa7b071f |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update LLVM for 3.5 rebase (r209712).
Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 36b56886974eae4f9c5ebc96befd3e7bfe5de338 |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Update to LLVM 3.5a.
Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| bebe48dbfe00078329341945bfb11f778ace6d12 |
|
17-Nov-2013 |
Hal Finkel <hfinkel@anl.gov> |
Add a loop rerolling pass
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 563b29f8db68275407ffcd2a9a5f0ba77ee5e899 |
|
13-Nov-2013 |
Diego Novillo <dnovillo@google.com> |
SampleProfileLoader pass. Initial setup.
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 3748de6e2d7620794ff93b896d85aff6cc0ea9d2 |
|
14-Sep-2013 |
Chandler Carruth <chandlerc@gmail.com> |
Remove the long, long defunct IR block placement pass.
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| a8a7099c1849fcbb4a68642a292fd0250aa46505 |
|
23-Aug-2013 |
Richard Sandiford <rsandifo@linux.vnet.ibm.com> |
Turn MipsOptimizeMathLibCalls into a target-independent scalar transform
...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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 01d7203ef8316fdd71c3cec59f8e68fb869e0dbf |
|
06-Aug-2013 |
Tom Stellard <thomas.stellard@amd.com> |
Factor FlattenCFG out from SimplifyCFG
Patch by: Mei Ye
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 57e6b2d1f3de0bf459e96f7038e692d624f7e580 |
|
27-Jul-2013 |
Tom Stellard <thomas.stellard@amd.com> |
SimplifyCFG: Use parallel-and and parallel-or mode to consolidate branch conditions
Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches. The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.
Patch by: Mei Ye
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| be87bce32bc9af9bc5918a6e08806b61e3088165 |
|
20-Jun-2013 |
Meador Inge <meadori@codesourcery.com> |
Remove the simplify-libcalls pass (finally)
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| ad966ea7a81a538425d5319f6d8568e460639e54 |
|
19-Jun-2013 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
Move StructurizeCFG out of R600 to generic Transforms.
Register it with PassManager
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184343 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 40be1e85665d10f5444186f0e7106e368dd735b8 |
|
01-May-2013 |
Filip Pizlo <fpizlo@apple.com> |
This patch breaks up Wrap.h so that it does not have to include all of
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 3e39731e88f2d4f597cebc74388fd6650ca4f604 |
|
23-Apr-2013 |
Eric Christopher <echristo@gmail.com> |
Move C++ code out of the C headers and into either C++ headers
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 24c4898973a074713201fb9351d302b9f7733e92 |
|
28-Jan-2013 |
Michael Gottesman <mgottesman@apple.com> |
Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173647 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 0b8c9a80f20772c3793201ab5b251d3520b9cea3 |
|
02-Jan-2013 |
Chandler Carruth <chandlerc@gmail.com> |
Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| d04a8d4b33ff316ca4cf961e06c9e312eff8e64f |
|
03-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Use the new script to sort the includes of every file under lib.
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 3574eca1b02600bac4e625297f4ecf745f4c4f32 |
|
08-Oct-2012 |
Micah Villmow <villmow@gmail.com> |
Move TargetData to DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165402 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 713aa9431d84805c5b7ddce57159d14ee94cd548 |
|
14-Sep-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Introduce a new SROA implementation.
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| a94d6e87c4c49f2e81b01d66d8bfb591277f8f96 |
|
24-Jul-2012 |
Nadav Rotem <nadav.rotem@intel.com> |
Clean whitespaces.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160668 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 9b4df49d39ad9cb634ecd2e6547b58ee07436120 |
|
22-Jul-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Move the initialization of the bounds checking pass. The pass itself
moved earlier. This fixes some layering issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160611 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 5c525b59d5e0036a778d278eeff4832edfd41357 |
|
22-May-2012 |
Nuno Lopes <nunoplopes@sapo.pt> |
add a new pass to instrument loads and stores for run-time bounds checking
move EmitGEPOffset from InstCombine to Transforms/Utils/Local.h
(a draft of this) patch reviewed by Andrew, thanks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157261 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 2f6263c96a6ed234b8d314cc35c8e2fcc3e81ccc |
|
17-Jan-2012 |
Dan Gohman <gohman@apple.com> |
Add a new ObjC ARC optimization pass to eliminate unneeded
autorelease push+pop pairs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148330 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| f940a1a869b4fe6f857e7fd8aeb97e7b7e9b390e |
|
31-Aug-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove the old tail duplication pass. It is not used and is unable to update
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 0335a14ae771ce1793fb5401acfeb2fb59fc1c6f |
|
25-Jul-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add LLVMAddLowerExpectIntrinsicPass to the C API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135966 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 9da9934e27dfb48de77b80a3e20ed2d869b52024 |
|
06-Jul-2011 |
Jakub Staszak <jstaszak@apple.com> |
Introduce "expect" intrinsic instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134516 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 9fbd318d36e618fb08fb53bb48b7c848e617a8a7 |
|
16-Jun-2011 |
John McCall <rjmccall@apple.com> |
The ARC language-specific optimizer. Credit to Dan Gohman.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133108 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 0d9874b48d747298dcea7e4e6385b511c04a7842 |
|
13-Apr-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add the alias analysis to the C api.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129447 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 45e1a53efd40a594fa8bb59aee75bb0984770d29 |
|
07-Apr-2011 |
Rafael Espindola <rafael.espindola@gmail.com> |
Expose more passes to the C API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129087 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 00141694fa9fd846a051e335c3ec6ba335aca602 |
|
28-Feb-2011 |
Dan Gohman <gohman@apple.com> |
Delete the GEPSplitter experiment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126671 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 1551abdea6206870df86f730a289a74ef506d259 |
|
28-Feb-2011 |
Dan Gohman <gohman@apple.com> |
Delete the SimplifyHalfPowrLibCalls pass, which was unused, and
only existed as the result of a misunderstanding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126669 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| b1686c32fc694636cbf15a59b23b2a741b65ecf4 |
|
18-Jan-2011 |
Cameron Zwarich <zwarich@apple.com> |
Remove outdated references to dominance frontiers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123724 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| b352d6eb49927a7c707cbd9046cfc525b0c3f2d7 |
|
14-Jan-2011 |
Chris Lattner <sabre@nondot.org> |
split SROA into two passes: one that uses DomFrontiers (-scalarrepl)
and one that uses SSAUpdater (-scalarrepl-ssa)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123436 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 832f61117d69019376c4aabedd4de3831279e288 |
|
03-Jan-2011 |
Cameron Zwarich <zwarich@apple.com> |
Add a new loop-instsimplify pass, with the intention of replacing the instance
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
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 12be936cc912b1ff4d1c73c7f2c805a3462da1ab |
|
02-Jan-2011 |
Chris Lattner <sabre@nondot.org> |
sketch out a new early cse pass. No functionality yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122713 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| b0db161f5b85c4a31046d2271d9e270991b53a15 |
|
26-Dec-2010 |
Chris Lattner <sabre@nondot.org> |
Start of a pass for recognizing memset and memcpy idioms.
No functionality yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122562 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| d82e9e7d939bb4b4f4773e9853c061e14188f705 |
|
08-Oct-2010 |
Devang Patel <dpatel@apple.com> |
Remove LoopIndexSplit pass. It is neither maintained nor used by anyone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116004 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 1a3d23362168ae6d8e07efd547a92cc36738a789 |
|
07-Oct-2010 |
Owen Anderson <resistor@mac.com> |
Next step on the getting-rid-of-static-ctors train: begin adding per-library
initialization functions that initialize the set of passes implemented in
that library. Add C bindings for these functions as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115927 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 75d5fe9213073df311a909924d96a4af7532b001 |
|
12-Mar-2010 |
Nate Begeman <natebegeman@mac.com> |
Whoops this already existed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98297 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 47a53a6e4ca2e49284c800e9b9e0172e7df7217c |
|
12-Mar-2010 |
Nate Begeman <natebegeman@mac.com> |
Add a handful of additional useful pass manager things to the C API
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98296 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| f8fb7c26ee251e71be8a5372dc4936f3042c7553 |
|
11-Nov-2009 |
Chris Lattner <sabre@nondot.org> |
remove the now dead condprop pass, PR3906.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86810 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 57c03831ccaabd619d1d7eb164375e7e3027031d |
|
06-Mar-2009 |
Chris Lattner <sabre@nondot.org> |
add a bunch more passes to the C bindings (PR3734), patch by
Lennart Augustsson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66272 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 69cf031ee33fc564c3888694cb1cd8ab5dae9fd2 |
|
20-Mar-2008 |
Gordon Henriksen <gordonhenriksen@mac.com> |
C and Objective Caml bindings for mem2reg and reg2mem.
Patch by Erick Tryzelaar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|
| 41ba1546eb46030e9994ee14f8052a1981ae2c54 |
|
16-Mar-2008 |
Gordon Henriksen <gordonhenriksen@mac.com> |
C and Objective Caml bindings for several scalar transforms.
Patch originally by Erick Tryzelaar, but has been modified somewhat.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48419 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/Scalar/Scalar.cpp
|