Summary:
This patch teaches `DT.applyUpdates` to take the fast when applying zero or just one update and makes it not run the internal batch updater machinery.
With this patch, it should no longer make sense to have a special check in user's code that checks the update sequence size before applying them, e.g.
```
if (!MyUpdates.empty())
DT.applyUpdates(MyUpdates);
```
or
```
if (MyUpdates.size() == 1)
if (...)
DT.insertEdge(...)
else
DT.deleteEdge(...)
```
Reviewers: dberlin, brzycki, davide, grosser, sanjoy
Reviewed By: dberlin, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38541
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314917 91177308-0d34-0410-b5e6-96231b3b80d8
This patch makes DT::eraseNode mark DFSInfo as invalid.
Not marking it as invalid leads to DFS numbers getting corrupted
and failing VerifyDFSNumbers check.
This patch also makes children iterator const (NFC).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314847 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch teaches the DominatorTree verifier to check DFS In/Out numbers which are used to answer dominance queries.
DFS number verification is done in O(nlogn), so it shouldn't add much overhead on top of the O(n^3) sibling property verification.
This check should detect errors like the one spotted in PR34466 and related bug reports.
The patch also cleans up the DFS calculation a bit, as all constructed trees should have a single root now.
I see 2 new test failures when running check-all after this change:
```
Failing Tests (2):
Polly :: Isl/CodeGen/OpenMP/reference-argument-from-non-affine-region.ll
Polly :: Isl/CodeGen/OpenMP/two-parallel-loops-reference-outer-indvar.ll
```
which seem to happen just after `Create LLVM-IR from SCoPs` -- I XFAILed them in r314800.
Reviewers: dberlin, grosser, davide, zhendongsu, bollu
Reviewed By: dberlin
Subscribers: nandini12396, bollu, Meinersbur, brzycki, llvm-commits
Differential Revision: https://reviews.llvm.org/D38331
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314801 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch introduces a way of informing the (Post)DominatorTree about multiple CFG updates that happened since the last tree update. This makes performing tree updates much easier, as it internally takes care of applying the updates in lockstep with the (virtual) updates to the CFG, which is done by reverse-applying future CFG updates.
The batch updater is able to remove redundant updates that cancel each other out. In the future, it should be also possible to reorder updates to reduce the amount of work needed to perform the updates.
Reviewers: dberlin, sanjoy, grosser, davide, brzycki
Reviewed By: brzycki
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36167
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311015 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch teaches PostDominatorTree about infinite loops. It is built on top of D29705 by @dberlin which includes a very detailed motivation for this change.
What's new is that the patch also teaches the incremental updater how to deal with reverse-unreachable regions and how to properly maintain and verify tree roots. Before that, the incremental algorithm sometimes ended up preserving reverse-unreachable regions after updates that wouldn't appear in the tree if it was constructed from scratch on the same CFG.
This patch makes the following assumptions:
- A sequence of updates should produce the same tree as a recalculating it.
- Any sequence of the same updates should lead to the same tree.
- Siblings and roots are unordered.
The last two properties are essential to efficiently perform batch updates in the future.
When it comes to the first one, we can decide later that the consistency between freshly built tree and an updated one doesn't matter match, as there are many correct ways to pick roots in infinite loops, and to relax this assumption. That should enable us to recalculate postdominators less frequently.
This patch is pretty conservative when it comes to incremental updates on reverse-unreachable regions and ends up recalculating the whole tree in many cases. It should be possible to improve the performance in many cases, if we decide that it's important enough.
That being said, my experiments showed that reverse-unreachable are very rare in the IR emitted by clang when bootstrapping clang. Here are the statistics I collected by analyzing IR between passes and after each removePredecessor call:
```
# functions: 52283
# samples: 337609
# reverse unreachable BBs: 216022
# BBs: 247840796
Percent reverse-unreachable: 0.08716159869015269 %
Max(PercRevUnreachable) in a function: 87.58620689655172 %
# > 25 % samples: 471 ( 0.1395104988314885 % samples )
... in 145 ( 0.27733680163724345 % functions )
```
Most of the reverse-unreachable regions come from invalid IR where it wouldn't be possible to construct a PostDomTree anyway.
I would like to commit this patch in the next week in order to be able to complete the work that depends on it before the end of my internship, so please don't wait long to voice your concerns :).
Reviewers: dberlin, sanjoy, grosser, brzycki, davide, chandlerc, hfinkel
Reviewed By: dberlin
Subscribers: nhaehnle, javed.absar, kparzysz, uabelho, jlebar, hiraditya, llvm-commits, dberlin, david2050
Differential Revision: https://reviews.llvm.org/D35851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310940 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch makes LoopDeletion use the incremental DominatorTree API.
We modify LoopDeletion to perform the deletion in 5 steps:
1. Create a new dummy edge from the preheader to the exit, by adding a conditional branch.
2. Inform the DomTree about the new edge.
3. Remove the conditional branch and replace it with an unconditional edge to the exit. This removes the edge to the loop header, making it unreachable.
4. Inform the DomTree about the deleted edge.
5. Remove the unreachable block from the function.
Creating the dummy conditional branch is necessary to perform incremental DomTree update.
We should consider using the batch updater when it's ready.
Reviewers: dberlin, davide, grosser, sanjoy
Reviewed By: dberlin, grosser
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D35391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309850 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We can use the template parameter `IsPostDom` to pick an appropriate SmallVector size to store DomTree roots for dominators and postdominators. Before, the code would always allocate memory with `std::vector`.
Reviewers: dberlin, davide, sanjoy, grosser
Reviewed By: grosser
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35636
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309148 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch moves root-finding logic from DominatorTreeBase to GenericDomTreeConstruction.h.
It makes the behavior simpler and more consistent by always adding a virtual root to PostDominatorTrees.
Reviewers: dberlin, davide, grosser, sanjoy
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35597
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309146 91177308-0d34-0410-b5e6-96231b3b80d8
Some platforms have problems with emmiting constructors when class
templates get explicitly instantiated.
This patch fixes the bug reported in D35315 by replacing `= default`
with an empty constructor body.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308140 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch implements incremental edge deletions.
It also makes DominatorTreeBase store a pointer to the parent function. The parent function is needed to perform full rebuilts during some deletions, but it is also used to verify that inserted and deleted edges come from the same function.
Reviewers: dberlin, davide, grosser, sanjoy, brzycki
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308062 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch introduces incremental edge insertions based on the Depth Based Search algorithm.
Insertions should work for both dominators and postdominators.
Reviewers: dberlin, grosser, davide, sanjoy, brzycki
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35341
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308054 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
DominatorTreeBase used to have IsPostDominators (bool) member to indicate if the tree is a dominator or a postdominator tree. This made it possible to switch between the two 'modes' at runtime, but it isn't used in practice anywhere.
This patch makes IsPostDominator a template argument. This way, it is easier to switch between different algorithms at compile-time based on this argument and design external utilities around it. It also makes it impossible to incidentally assign a postdominator tree to a dominator tree (and vice versa), and to further simplify template code in GenericDominatorTreeConstruction.
Reviewers: dberlin, sanjoy, davide, grosser
Reviewed By: dberlin
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D35315
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308040 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: DominatorTreeBase and related classes used overcomplicated template machinery. This patch simplifies them and gets rid of DominatorTreeBaseTraits and DominatorTreeBaseByTraits, which weren't actually used outside the DomTree construction.
Reviewers: dberlin, sanjoy, davide, grosser
Reviewed By: dberlin, davide, grosser
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35285
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307953 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch improves verification by making `verifyReachablility` look for CFG not found in the DomTree.
It also makes the verification work with postdominators by handling virtual root.
Reviewers: dberlin, davide, grosser, sanjoy
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35279
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307936 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r306907 and reapplies the patches in the title.
The patches used to make one of the
CodeGen/ARM/2011-02-07-AntidepClobber.ll test to fail because of a
missing null check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306919 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r306894.
Revert "[Dominators] Add NearestCommonDominator verification"
This reverts commit r306893.
Revert "[Dominators] Keep tree level in DomTreeNode and use it to find NCD and answer dominance queries"
This reverts commit r306892.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306907 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds another verification function for checking correctness of findNearestCommonDominator.
For every edge from U to V in the input graph, `NCD(U, V) == IDom(V) or V` -- the new function checks this condition.
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34575
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306893 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch makes DomTreeNodes keep their level (depth) in the DomTree. By having this information always available, it is possible to speedup and simplify findNearestCommonDominator and certain dominance queries.
In the future, level information will be also needed to perform incremental updates.
My testing doesn't show any noticeable performance differences after applying this patch. There may be some improvements when other passes are thought to use the level information.
Reviewers: dberlin, sanjoy, chandlerc, grosser
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306892 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch makes DominatorTreeBase more readable by putting most important members on top of the class.
Before, the class looked like that: private -> protected (including data members) -> public -> protected.
The patch changes it to: protected (data members only) -> public -> protected -> public.
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34527
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306714 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
DominatorBase class was only used by DominatorTreeBase. It didn't provide any useful abstractions, nor simplified anything, so I see no point keeping it.
This commit removes the DominatorBase class and moves its content into DominatorTreeBase.
This is the first patch in a series that tries to make all DomTrees have a single virtual root, which will allow to further simplify code (especially when it comes to incremental updates).
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306713 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds an additional level of verification - it checks parent and sibling properties of a tree. By definition, every tree with these two properties is a dominator tree.
It is possible to run those check by running llvm with `-verify-dom-info=1`.
Bootstrapping clang and building the llvm test suite with this option enabled doesn't yield any errors.
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34482
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306711 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Helper functions (DFSPass, ReverseDFSPass, Eval) need SemiNCAInfo anyway, so it's simpler to have them there as member functions. This also makes them simpler by removing template boilerplate.
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34427
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306579 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This moves SemiNCAInfo from DeminatorTreeBase to GenericDomTreeConstruction. It also put helper functions used during tree constructions in the same file.
The point of this change is to further clean up DominatorTreeBase and make it easier to construct and verify (in future patches).
Reviewers: dberlin, sanjoy, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34420
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306576 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The temporary IDoms map was used only during DomTree calculation. We can move it to SNCAInfo so that it's no longer a DominatorTreeBase member.
Reviewers: sanjoy, dberlin, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34317
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306574 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The InfoRec struct is used only during tree construction, so there is no point having it as a DominatorTreeBase member.
This patch moves it into the Calculate function instead and makes it pass it to its helper functions.
Reviewers: sanjoy, dberlin, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34305
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306572 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Number to node mapping in DominatorTreeBase is used only during calculation, so there is no point keeping is as a member variable. This patch moves this mapping to Calculate function and passes it to helper functions. It also makes the name more descriptive.
Reviewers: sanjoy, dberlin, davide, chandlerc
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34295
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306562 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch cleans up GenericDomTree.h by:
- removing unnecessary <NodeT> in DomTreeNodeBase
- removing unnecessary std::move on bools
- changing type of DFSNumIn/DFSNumOut from int to unsigned (since the members were used as unsigned anyway)
The changes don't affect behavior -- everything works as before.
Reviewers: sanjoy, dberlin, chandlerc
Reviewed By: dberlin
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D34229
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305710 91177308-0d34-0410-b5e6-96231b3b80d8
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304787 91177308-0d34-0410-b5e6-96231b3b80d8
Use constant references rather than `const auto` which will cause the
copy constructor. These particular cases cause issues for the swift
compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301237 91177308-0d34-0410-b5e6-96231b3b80d8
Use children<> and nodes<> in appropriate places to cleanup the code.
Also, as part of the cleanup,
change the signature of DominatorTreeBase's Split.
It is a protected non-virtual member function called only twice,
both from within the class,
and the removed passed argument in both cases is '*this'.
The reason for the existence of that argument seems to be that
back before r43115 Split was a free function,
so an argument to get '*this' was needed - but now that is no longer the
case.
Patch by Yoav Ben-Shalom!
Differential Revision: https://reviews.llvm.org/D32118
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300656 91177308-0d34-0410-b5e6-96231b3b80d8
and also "clang-format GenericDomTreeConstruction.h, since the current
formatting makes it look like their is a bug in the loop indentation, and there
is not"
This reverts commit r296535.
There are still some open design questions which I would like to discuss. I
revert this for Daniel (who gave the OK), as he is on vacation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296812 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently, our post-dom tree tries to ignore and remove the effects of
infinite loops. It fails miserably at this, because it tries to do it
ahead of time, and thus can only detect self-loops, and any other type
of infinite loop, it pretends doesn't exist at all.
This can, in a bunch of cases, lead to wrong answers and a completely
empty post-dom tree.
Wrong answer:
```
declare void foo()
define internal void @f() {
entry:
br i1 undef, label %bb35, label %bb3.i
bb3.i:
call void @foo()
br label %bb3.i
bb35.loopexit3:
br label %bb35
bb35:
ret void
}
```
We get:
```
Inorder PostDominator Tree:
[1] <<exit node>> {0,7}
[2] %bb35 {1,6}
[3] %bb35.loopexit3 {2,3}
[3] %entry {4,5}
```
This is a trivial modification of the testcase for PR 6047
Note that we pretend bb3.i doesn't exist.
We also pretend that bb35 post-dominates entry.
While it's true that it does not exit in a theoretical sense, it's not
really helpful to try to ignore the effect and pretend that bb35
post-dominates entry. Worse, we pretend the infinite loop does
nothing (it's usually considered a side-effect), and doesn't even
exist, even when it calls a function. Sadly, this makes it impossible
to use when you are trying to move code safely. All compilers also
create virtual or real single exit nodes (including us), and connect
infinite loops there (which this patch does). In fact, others have
worked around our behavior here, to the point of building their own
post-dom trees:
https://zneak.github.io/fcd/2016/02/17/structuring.html and pointing
out the region infrastructure is near-useless for them with postdom in
this state :(
Completely empty post-dom tree:
```
define void @spam() #0 {
bb:
br label %bb1
bb1: ; preds = %bb1, %bb
br label %bb1
bb2: ; No predecessors!
ret void
}
```
Printing analysis 'Post-Dominator Tree Construction' for function 'foo':
=============================--------------------------------
Inorder PostDominator Tree:
[1] <<exit node>> {0,1}
:(
(note that even if you ignore the effects of infinite loops, bb2
should be present as an exit node that post-dominates nothing).
This patch changes post-dom to properly handle infinite loops and does
root finding during calculation to prevent empty tress in such cases.
We match gcc's (and the canonical theoretical) behavior for infinite
loops (find the backedge, connect it to the exit block).
Testcases coming as soon as i finish running this on a ton of random graphs :)
Reviewers: chandlerc, davide
Subscribers: bryant, llvm-commits
Differential Revision: https://reviews.llvm.org/D29705
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296535 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Convert all obvious node_begin/node_end and child_begin/child_end
pairs to range based for.
Sending for review in case someone has a good idea how to make
graph_children able to be inferred. It looks like it would require
changing GraphTraits to be two argument or something. I presume
inference does not happen because it would have to check every
GraphTraits in the world to see if the noderef types matched.
Note: This change was 3-staged with clang as well, which uses
Dominators/etc from LLVM.
Reviewers: chandlerc, tstellarAMD, dblaikie, rsmith
Subscribers: arsenm, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D29767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294620 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GenericDomTreeConstruction had its own written DFS walk.
It is basically identical to the DFS walk df_* is doing in the iterators.
the one difference is that df_iterator uses an internal visited set.
The GenericDomTreeConstruction one reused a field in an existing densemap lookup.
Time-wise, this way is actually more cache-friendly (the previous way has a random store
into a successor's info, the new way does that store at the same time and in the same place
as other stores to the same info)
It costs some very small amount of memory to do this, and one we pay in some other part of
dom tree construction *anyway*, so we aren't really increasing dom tree constructions's
peak memory usage.
It could still be changed to use the old field with a little work on df_ext_* if we care
(and if someone find performance regressions)
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: Eugene.Zelenko, llvm-commits
Differential Revision: https://reviews.llvm.org/D8932
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294339 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases StructurizeCfg updates root node, but dominator info
remains unchanges, it causes crash when expensive checks are enabled.
To cope with this problem a new method was added to DominatorTreeBase
that allows adding new root nodes, it is called in StructurizeCfg to
put dominator tree in sync.
This change fixes PR27488.
Differential Revision: https://reviews.llvm.org/D28114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291530 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Looking at the implementation, GenericDomTree has more specific
requirements on NodeRef, e.g. NodeRefObject->getParent() should compile,
and NodeRef should be a pointer. We can remove the pointer requirement,
but it seems to have little gain, given the limited use cases.
Also changed GraphTraits<Inverse<Inverse<T>> to be more accurate.
Reviewers: dblaikie, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278961 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278433 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268050 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r249783, fully reinstating r249782. I've fixed the
bug in clang: it was a non-const iterator that dereferenced to const
(but had an implicit conversion to non-const).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249850 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently the iterators in `clang::CFGBlock` have an auto-conversion to
`CFGBlock *`, but the dereference operator gives `const CFGBlock &`.
Until I have a moment to fix that, revert the GenericDomTree chagnes
from r249782.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249783 91177308-0d34-0410-b5e6-96231b3b80d8
Stop converting implicitly between iterators and pointers/references in
lib/IR. For convenience, I've added a `getIterator()` accessor to
`ilist_node` so that callers don't need to know how to spell the
iterator class (i.e., they can use `X.getIterator()` instead of
`Function::iterator(X)`).
I'll eventually disallow these implicit conversions entirely, but
there's a lot of code, so it doesn't make sense to do it all in one
patch. One library or so at a time.
Why? To root out cases of `getNextNode()` and `getPrevNode()` being
used in iterator logic. The design of `ilist` makes that invalid when
the current node could be at the back of the list, but it happens to
"work" right now because of a bug where those functions never return
`nullptr` if you're using a half-node sentinel. Before I can fix the
function, I have to remove uses of it that rely on it misbehaving.
(Maybe the function should just be deleted anyway? But I don't want
deleting it -- potentially a huge project -- to block fixing
ilist/iplist.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249782 91177308-0d34-0410-b5e6-96231b3b80d8
Note: I'm am not trying to describe what "should be"; I'm only describing what is true today.
This came out of my recent question to llvm-dev titled: When can the dominator tree not contain a node for a basic block?
Differential Revision: http://reviews.llvm.org/D13078
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248417 91177308-0d34-0410-b5e6-96231b3b80d8
