2008-09-22 09:08:49 +08:00
|
|
|
add_llvm_library(LLVMScalarOpts
|
|
|
|
ADCE.cpp
|
2014-09-08 04:05:11 +08:00
|
|
|
AlignmentFromAssumptions.cpp
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
llvm-svn: 229462
2015-02-17 09:36:59 +08:00
|
|
|
BDCE.cpp
|
2014-01-25 10:02:55 +08:00
|
|
|
ConstantHoisting.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
ConstantProp.cpp
|
2010-08-31 15:41:39 +08:00
|
|
|
CorrelatedValuePropagation.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
DCE.cpp
|
|
|
|
DeadStoreElimination.cpp
|
2011-01-03 10:13:05 +08:00
|
|
|
EarlyCSE.cpp
|
2014-05-02 02:59:11 +08:00
|
|
|
FlattenCFGPass.cpp
|
2015-03-27 18:36:57 +08:00
|
|
|
Float2Int.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
GVN.cpp
|
2015-01-16 09:03:22 +08:00
|
|
|
InductiveRangeCheckElimination.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
IndVarSimplify.cpp
|
|
|
|
JumpThreading.cpp
|
|
|
|
LICM.cpp
|
2014-05-29 09:55:07 +08:00
|
|
|
LoadCombine.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
LoopDeletion.cpp
|
2010-12-27 03:32:44 +08:00
|
|
|
LoopIdiomRecognize.cpp
|
2011-01-03 08:25:16 +08:00
|
|
|
LoopInstSimplify.cpp
|
2015-03-06 18:11:25 +08:00
|
|
|
LoopInterchange.cpp
|
2014-05-02 02:59:11 +08:00
|
|
|
LoopRerollPass.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
LoopRotation.cpp
|
|
|
|
LoopStrengthReduce.cpp
|
2009-10-31 22:38:25 +08:00
|
|
|
LoopUnrollPass.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
LoopUnswitch.cpp
|
2010-08-04 00:19:16 +08:00
|
|
|
LowerAtomic.cpp
|
2015-01-24 18:18:47 +08:00
|
|
|
LowerExpectIntrinsic.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
MemCpyOptimizer.cpp
|
2014-07-19 03:13:09 +08:00
|
|
|
MergedLoadStoreMotion.cpp
|
2015-04-14 12:59:22 +08:00
|
|
|
NaryReassociate.cpp
|
2013-08-23 18:27:02 +08:00
|
|
|
PartiallyInlineLibCalls.cpp
|
Add a pass for inserting safepoints into (nearly) arbitrary IR
This pass is responsible for figuring out where to place call safepoints and safepoint polls. It doesn't actually make the relocations explicit; that's the job of the RewriteStatepointsForGC pass (http://reviews.llvm.org/D6975).
Note that this code is not yet finalized. Its moving in tree for incremental development, but further cleanup is needed and will happen over the next few days. It is not yet part of the standard pass order.
Planned changes in the near future:
- I plan on restructuring the statepoint rewrite to use the functions add to the IRBuilder a while back.
- In the current pass, the function "gc.safepoint_poll" is treated specially but is not an intrinsic. I plan to make identifying the poll function a property of the GCStrategy at some point in the near future.
- As follow on patches, I will be separating a collection of test cases we have out of tree and submitting them upstream.
- It's not explicit in the code, but these two patches are introducing a new state for a statepoint which looks a lot like a patchpoint. There's no a transient form which doesn't yet have the relocations explicitly represented, but does prevent reordering of memory operations. Once this is in, I need to update actually make this explicit by reserving the 'unused' argument of the statepoint as a flag, updating the docs, and making the code explicitly check for such a thing. This wasn't really planned, but once I split the two passes - which was done for other reasons - the intermediate state fell out. Just reminds us once again that we need to merge statepoints and patchpoints at some point in the not that distant future.
Future directions planned:
- Identifying more cases where a backedge safepoint isn't required to ensure timely execution of a safepoint poll.
- Tweaking the insertion process to generate easier to optimize IR. (For example, investigating making SplitBackedge) the default.
- Adding opt-in flags for a GCStrategy to use this pass. Once done, add this pass to the actual pass ordering.
Differential Revision: http://reviews.llvm.org/D6981
llvm-svn: 228090
2015-02-04 08:37:33 +08:00
|
|
|
PlaceSafepoints.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Reassociate.cpp
|
|
|
|
Reg2Mem.cpp
|
Add a pass for constructing gc.statepoint sequences w/explicit relocations
This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.relocates inserted yet, and insert them. This can be used either immediately after IR generation to perform 'early safepoint insertion' or late in the pass order to perform 'late insertion'.
This patch is setting the stage for work to continue in tree. In particular, there are known naming and style violations in the current patch. I'll try to get those resolved over the next week or so. As I touch each area to make style changes, I need to make sure we have adequate testing in place. As part of the cleanup, I will be cleaning up a collection of test cases we have out of tree and submitting them upstream. The tests included in this change are very basic and mostly to provide examples of usage.
The pass has several main subproblems it needs to address:
- First, it has identify any live pointers. In the current code, the use of address spaces to distinguish pointers to GC managed objects is hard coded, but this will become parametrizable in the near future. Note that the current change doesn't actually contain a useful liveness analysis. It was seperated into a followup change as the code wasn't ready to be shared. Instead, the current implementation just considers any dominating def of appropriate pointer type to be live.
- Second, it has to identify base pointers for each live pointer. This is a fairly straight forward data flow algorithm.
- Third, the information in the previous steps is used to actually introduce rewrites. Rather than trying to do this by hand, we simply re-purpose the code behind Mem2Reg to do this for us.
llvm-svn: 229945
2015-02-20 09:06:44 +08:00
|
|
|
RewriteStatepointsForGC.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
SCCP.cpp
|
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.
llvm-svn: 163883
2012-09-14 17:22:59 +08:00
|
|
|
SROA.cpp
|
2014-05-02 02:59:11 +08:00
|
|
|
SampleProfile.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
Scalar.cpp
|
|
|
|
ScalarReplAggregates.cpp
|
2014-05-02 02:59:11 +08:00
|
|
|
Scalarizer.cpp
|
|
|
|
SeparateConstOffsetFromGEP.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
SimplifyCFGPass.cpp
|
2010-05-08 01:13:20 +08:00
|
|
|
Sink.cpp
|
Add straight-line strength reduction to LLVM
Summary:
Straight-line strength reduction (SLSR) is implemented in GCC but not yet in
LLVM. It has proven to effectively simplify statements derived from an unrolled
loop, and can potentially benefit many other cases too. For example,
LLVM unrolls
#pragma unroll
foo (int i = 0; i < 3; ++i) {
sum += foo((b + i) * s);
}
into
sum += foo(b * s);
sum += foo((b + 1) * s);
sum += foo((b + 2) * s);
However, no optimizations yet reduce the internal redundancy of the three
expressions:
b * s
(b + 1) * s
(b + 2) * s
With SLSR, LLVM can optimize these three expressions into:
t1 = b * s
t2 = t1 + s
t3 = t2 + s
This commit is only an initial step towards implementing a series of such
optimizations. I will implement more (see TODO in the file commentary) in the
near future. This optimization is enabled for the NVPTX backend for now.
However, I am more than happy to push it to the standard optimization pipeline
after more thorough performance tests.
Test Plan: test/StraightLineStrengthReduce/slsr.ll
Reviewers: eliben, HaoLiu, meheff, hfinkel, jholewinski, atrick
Reviewed By: jholewinski, atrick
Subscribers: karthikthecool, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D7310
llvm-svn: 228016
2015-02-04 03:37:06 +08:00
|
|
|
StraightLineStrengthReduce.cpp
|
2013-06-20 04:18:24 +08:00
|
|
|
StructurizeCFG.cpp
|
2008-09-22 09:08:49 +08:00
|
|
|
TailRecursionElimination.cpp
|
2015-02-11 11:28:02 +08:00
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/Transforms/Scalar
|
2008-09-22 09:08:49 +08:00
|
|
|
)
|
2012-06-24 21:32:01 +08:00
|
|
|
|
|
|
|
add_dependencies(LLVMScalarOpts intrinsics_gen)
|