| Age | Commit message (Collapse) | Author |
|---|
|
FCAs. This is essential in order to promote allocas that are used in
struct returns by frontends like Clang. The FCA load would block the
rest of the pass from firing, resulting is significant regressions with
the bullet benchmark in the nightly test suite.
Thanks to Duncan for repeated discussions about how best to do this, and
to both him and Benjamin for review.
This appears to have blocked many places where the pass tries to fire,
and so I'm expect somewhat different results with this fix added.
As with the last big patch, I'm including a change to enable the SROA by
default *temporarily*. Ben is going to remove this as soon as the LNT
bots pick up the patch. I'm just trying to get a round of LNT numbers
from the stable machines in the lab.
NOTE: Four clang tests are expected to fail in the brief window where
this is enabled. Sorry for the noise!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164117 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM_DELETED_FUNCTION.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164090 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and a conditional branch; also when removing dead cases from a switch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Hanlde the case when we split the default edge if the default target has "icmp"
and unconditinal branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
destination in SimplifyCondBranchToCondBranch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164054 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arch specific way to mimic the native calling convention.
The goal is to make this good enough for ppapi interfaces.
Review URL: https://chromiumcodereview.appspot.com/10912128
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MSVC8 won't compile lower_bound if one is missing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164035 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The cases where no initialization happens should still be checked for logic flaws.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164032 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
partition use lists a bit. No functionality changed.
These visitors are actually visiting a tuple of a Use and an offset into
the alloca. However, we use the InstVisitor to handle the dispatch over
the users, and so the Use and Offset are stored in class member
variables and set just before each call to visit(). This is fairly
awkward and makes the functions a bit harder to read, but its the only
real option we have until InstVisitor can be rewritten to use variadic
templates.
However, this pattern shouldn't be followed on the helper member
functions where there is no interface constraint from the visitor. We
already were passing the instruction as a normal parameter rather than
use the Use to get at it, start passing the offset as well. This will
become more important in subsequent patches as the offset will in some
cases change while visiting a single instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164003 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
What we have so far:
- Some clang test failures (these were known already)
- Perf results are mixed, some big regressions
http://llvm.org/perf/db_default/v4/nts/3844
http://llvm.org/perf/db_default/v4/nts/3845
bullet suffers a lot. matmul is interesting: slower scalar code, faster with -vectorize.
- Some dragonegg selfhost bots crash in SROA during selfhost now
http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-self-host-checks/builds/1632
http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.5-self-host/builds/1891
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163968 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
new one, and add support for running the new pass in that mode and in
that slot of the pass manager. With this the new pass can completely
replace the old one within the pipeline.
The strategy for enabling or disabling the SSAUpdater logic is to do it
by making the requirement of the domtree analysis optional. By default,
it is required and we get the standard mem2reg approach. This is usually
the desired strategy when run in stand-alone situations. Within the
CGSCC pass manager, we disable requiring of the domtree analysis and
consequentially trigger fallback to the SSAUpdater promotion.
In theory this would allow the pass to re-use a domtree if one happened
to be available even when run in a mode that doesn't require it. In
practice, it lets us have a single pass rather than two which was
simpler for me to wrap my head around.
There is a hidden flag to force the use of the SSAUpdater code path for
the purpose of testing. The primary testing strategy is just to run the
existing tests through that path. One notable difference is that it has
custom code to handle lifetime markers, and one of the tests has been
enhanced to exercise that code.
This has survived a bootstrap and the test suite without serious
correctness issues, however my run of the test suite produced *very*
alarming performance numbers. I don't entirely understand or trust them
though, so more investigation is on-going.
To aid my understanding of the performance impact of the new SROA now
that it runs throughout the optimization pipeline, I'm enabling it by
default in this commit, and will disable it again once the LNT bots have
picked up one iteration with it. I want to get those bots (which are
much more stable) to evaluate the impact of the change before I jump to
any conclusions.
NOTE: Several Clang tests will fail because they run -O3 and check the
result's order of output. They'll go back to passing once I disable it
again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
destination.
Updated previous implementation to fix a case not covered:
// PBI: br i1 %x, TrueDest, BB
// BI: br i1 %y, TrueDest, FalseDest
The other case was handled correctly.
// PBI: br i1 %x, BB, FalseDest
// BI: br i1 %y, TrueDest, FalseDest
Also tried to use 64-bit arithmetic instead of APInt with scale to simplify the
computation. Let me know if you have other opinions about this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163954 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
case to a conditional branch and when removing dead cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163942 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163940 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lit config.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163928 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163926 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the default target of the first switch is not the basic block the second switch
is in (PredDefault != BB).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
with the rest of the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The NDEBUG hack is ugly, but I see no better solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163900 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointless checks in here, bad asserts, and just confusing code. I've
also added a bit more to the comment to clarify what this function is
really trying to do as it was not obvious to Duncan when studying it.
Thanks to Duncan for helping me dig through the issue.
No real functionality changed here in practical cases, and certainly no
test case. This is just cleanup spotted by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163897 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
explicit check before recursing. A simplification requested by Duncan
during review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inspection by Duncan during review. My suspicion is that we would still
have returned 0 anyways in this case, but doing it sooner is better.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163895 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deeply suspicious and likely to go away eventually. Also fix a bogus
comment about one of the checks in the vector GEP analysis. Based on
review from Duncan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Originally I had anticipated needing to thread this through more bits of
the SROA pass itself, but that ended up not happening. In the end, this
is a much simpler way to manange the variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
forget from Duncan's review as a FIXME.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163892 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unexpectedly in the future. More fixes from his code review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
being busy testing this...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163890 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163888 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the injected class name of a dependent base class here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
loads and stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
account.
This is common when storing to global variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which requires TargetData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163790 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This function writes out the current values of the counters and then resets
them. This can be used similarly to the __gcov_flush function to sync the
counters when need be. For instance, in a situation where the application
doesn't exit.
<rdar://problem/12185886>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to the default target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)"
No functional change. Update r163344.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a pair of switch/branch where both depend on the value of the same variable and
the default case of the first switch/branch goes to the second switch/branch.
Code clean up and fixed a few issues:
1> handling the case where some cases of the 2nd switch are invalidated
2> correctly calculate the weight for the 2nd switch when it is a conditional eq
Testing case is modified from Alastair's original patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163635 91177308-0d34-0410-b5e6-96231b3b80d8
|
