| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
We already have HoistThenElseCodeToIf, this patch implements
SinkThenElseCodeToEnd. When END block has only two predecessors and each
predecessor terminates with unconditional branches, we compare instructions in
IF and ELSE blocks backwards and check whether we can sink the common
instructions down.
rdar://12191395
llvm-svn: 164325
|
|
|
|
| |
llvm-svn: 164238
|
|
|
|
| |
llvm-svn: 164235
|
|
|
|
| |
llvm-svn: 164232
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
two variables where the first variable is returned and the second
ignored.
I don't think this occurs in practice (other passes should have cleaned
up the unused phi node), but it should still be handled correctly.
Also make the logic for determining if we should return early less
sketchy.
llvm-svn: 164225
|
|
|
|
|
|
| |
without parens.
llvm-svn: 164216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up from r163302, which added a transformation to
SimplifyCFG that turns some switches into loads from lookup tables.
It was pointed out that some targets, such as GPUs and deeply embedded
targets, might not find this appropriate, but SimplifyCFG doesn't have
enough information about the target to decide this.
This patch adds the reverse transformation to CodeGenPrep: it turns
loads from lookup tables back into switches for targets where we do not
build jump tables (assuming these are also the targets where lookup
tables are inappropriate).
Hopefully we will eventually get to have target information in
SimplifyCFG, and then this CodeGenPrep transformation can be removed.
llvm-svn: 164206
|
|
|
|
|
|
|
|
|
|
|
| |
from the dragonegg build bots when we turned on the full version of the
pass. Included a much reduced test case for this pesky bug, despite
bugpoint's uncooperative behavior.
Also, I audited all the similar code I could find and didn't spot any
other cases where this mistake cropped up.
llvm-svn: 164178
|
|
|
|
|
|
| |
Implementation derived from compiler-rt's implementation of signed and unsigned integer division.
llvm-svn: 164173
|
|
|
|
| |
llvm-svn: 164147
|
|
|
|
|
|
|
|
|
|
|
|
| |
working on FCA splitting. Instead of refusing to form a common type when
there are uses of a subsection of the alloca as well as a use of the
entire alloca, just skip the subsection uses and continue looking for
a whole-alloca use with a type that we can use.
This produces slightly prettier IR I think, and also fixes the other
failure in the test.
llvm-svn: 164146
|
|
|
|
| |
llvm-svn: 164142
|
|
|
|
|
|
| |
virtual-dtor warnings that come with it.
llvm-svn: 164140
|
|
|
|
|
|
|
|
| |
splitting aggregates into a real class.
No intended functionality change.
llvm-svn: 164135
|
|
|
|
|
|
| |
...I don't know why this could appease msvc...baad.
llvm-svn: 164130
|
|
|
|
|
|
| |
builders green again.
llvm-svn: 164124
|
|
|
|
|
|
| |
a fix to getCommonType in the previous patch.
llvm-svn: 164120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 164119
|
|
|
|
| |
llvm-svn: 164117
|
|
|
|
|
|
| |
LLVM_DELETED_FUNCTION.
llvm-svn: 164090
|
|
|
|
|
|
| |
and a conditional branch; also when removing dead cases from a switch.
llvm-svn: 164084
|
|
|
|
|
|
|
| |
Hanlde the case when we split the default edge if the default target has "icmp"
and unconditinal branch.
llvm-svn: 164076
|
|
|
|
| |
llvm-svn: 164068
|
|
|
|
|
|
| |
destination in SimplifyCondBranchToCondBranch.
llvm-svn: 164054
|
|
|
|
| |
llvm-svn: 164040
|
|
|
|
|
|
| |
MSVC8 won't compile lower_bound if one is missing.
llvm-svn: 164035
|
|
|
|
|
|
| |
The cases where no initialization happens should still be checked for logic flaws.
llvm-svn: 164032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164003
|
|
|
|
| |
llvm-svn: 163974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 163968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163954
|
|
|
|
| |
llvm-svn: 163945
|
|
|
|
|
|
| |
case to a conditional branch and when removing dead cases.
llvm-svn: 163942
|
|
|
|
| |
llvm-svn: 163940
|
|
|
|
|
|
| |
lit config.
llvm-svn: 163928
|
|
|
|
| |
llvm-svn: 163926
|
|
|
|
|
|
|
| |
the default target of the first switch is not the basic block the second switch
is in (PredDefault != BB).
llvm-svn: 163916
|
|
|
|
|
|
|
|
|
|
| |
* 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.
llvm-svn: 163902
|
|
|
|
|
|
| |
The NDEBUG hack is ugly, but I see no better solution.
llvm-svn: 163900
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163897
|
|
|
|
|
|
|
| |
explicit check before recursing. A simplification requested by Duncan
during review.
llvm-svn: 163896
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163895
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163894
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 163893
|
|
|
|
|
|
| |
forget from Duncan's review as a FIXME.
llvm-svn: 163892
|
|
|
|
|
|
| |
unexpectedly in the future. More fixes from his code review.
llvm-svn: 163891
|
|
|
|
|
|
| |
being busy testing this...
llvm-svn: 163890
|
|
|
|
| |
llvm-svn: 163889
|
|
|
|
| |
llvm-svn: 163888
|