#
4f80c93a |
| 15-Nov-2016 |
Pablo Barrio <pablo.barrio@arm.com> |
Revert "[JumpThreading] Unfold selects that depend on the same condition"
This reverts commit ac54d0066c478a09c7cd28d15d0f9ff8af984afc.
llvm-svn: 286976
|
#
5f782bb0 |
| 15-Nov-2016 |
Pablo Barrio <pablo.barrio@arm.com> |
Revert "[JumpThreading] Prevent non-deterministic use lists"
This reverts commit f2c2f5354070469dac253373c66527ca971ddc66.
llvm-svn: 286975
|
#
7ce2c5ec |
| 14-Nov-2016 |
Pablo Barrio <pablo.barrio@arm.com> |
[JumpThreading] Prevent non-deterministic use lists
Summary: Unfolding selects was previously done with the help of a vector of pointers that was then sorted to be able to remove duplicates. As this
[JumpThreading] Prevent non-deterministic use lists
Summary: Unfolding selects was previously done with the help of a vector of pointers that was then sorted to be able to remove duplicates. As this sorting depends on the memory addresses, it was non-deterministic. A SetVector is used now so that duplicates are removed without the need of sorting first.
Reviewers: mgrang, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26450
llvm-svn: 286807
show more ...
|
#
9f452541 |
| 08-Nov-2016 |
Pablo Barrio <pablo.barrio@arm.com> |
[JumpThreading] Unfold selects that depend on the same condition
Summary: These are good candidates for jump threading. This enables later opts (such as InstCombine) to combine instructions from the
[JumpThreading] Unfold selects that depend on the same condition
Summary: These are good candidates for jump threading. This enables later opts (such as InstCombine) to combine instructions from the selects with instructions out of the selects. SimplifyCFG will fold the select again if unfolding wasn't worth it.
Patch by James Molloy and Pablo Barrio.
Reviewers: rengolin, haicheng, sebpop
Subscribers: jojo, jmolloy, llvm-commits
Differential Revision: https://reviews.llvm.org/D26391
llvm-svn: 286236
show more ...
|
#
b38d3411 |
| 24-Oct-2016 |
Nico Weber <nicolasweber@gmx.de> |
Revert 284971.
It seems to break selfhost on some bots, see e.g. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/21 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multista
Revert 284971.
It seems to break selfhost on some bots, see e.g. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/21 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/20 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/22
llvm-svn: 284979
show more ...
|
#
f9e0d0b7 |
| 24-Oct-2016 |
Pablo Barrio <pablo.barrio@arm.com> |
[JumpThreading] Unfold selects that depend on the same condition
Summary: These are good candidates for jump threading. This enables later opts (such as InstCombine) to combine instructions from the
[JumpThreading] Unfold selects that depend on the same condition
Summary: These are good candidates for jump threading. This enables later opts (such as InstCombine) to combine instructions from the selects with instructions out of the selects. SimplifyCFG will fold the select again if unfolding wasn't worth it.
Patch by James Molloy and Pablo Barrio.
Reviewers: reames, bkramer, mcrosier, gberry, haicheng, jmolloy, sebpop
Subscribers: jojo, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D25477
llvm-svn: 284971
show more ...
|
#
b4d2678c |
| 03-Oct-2016 |
Hans Wennborg <hans@hanshq.net> |
Jump threading: avoid trying to split edge into landingpad block (PR27840)
Splitting the edge is nontrivial because of the landing pad, and we would currently assert trying to do it.
Differential R
Jump threading: avoid trying to split edge into landingpad block (PR27840)
Splitting the edge is nontrivial because of the landing pad, and we would currently assert trying to do it.
Differential Revision: https://reviews.llvm.org/D24680
llvm-svn: 283129
show more ...
|
#
c520822d |
| 06-Sep-2016 |
Adam Nemet <anemet@apple.com> |
[JumpThreading] Only write back branch-weight MDs for blocks that originally had PGO info
Currently the pass updates branch weights in the IR if the function has any PGO info (entry frequency is set
[JumpThreading] Only write back branch-weight MDs for blocks that originally had PGO info
Currently the pass updates branch weights in the IR if the function has any PGO info (entry frequency is set). However we could still have regions of the CFG that does not have branch weights collected (e.g. a cold region). In this case we'd use static estimates. Since static estimates for branches are determined independently, they are inconsistent. Updating them can "randomly" inflate block frequencies.
I've run into this in a completely cold loop of h264ref from SPEC. -Rpass-with-hotness showed the loop to be completely cold during inlining (before JT) but completely hot during vectorization (after JT).
The new testcase demonstrate the problem. We check array elements against 1, 2 and 3 in a loop. The check against 3 is the loop-exiting check. The block names should be self-explanatory.
In this example, jump threading incorrectly updates the weight of the loop-exiting branch to 0, drastically inflating the frequency of the loop (in the range of billions).
There is no run-time profile info for edges inside the loop, so branch probabilities are estimated. These are the resulting branch and block frequencies for the loop body:
check_1 (16) (8) / | eq_1 | (8) \ | check_2 (16) (8) / | eq_2 | (8) \ | check_3 (16) (1) / | (loop exit) | (15) | (back edge)
First we thread eq_1 -> check_2 to check_3. Frequencies are updated to remove the frequency of eq_1 from check_2 and then from the false edge leaving check_2. Changed frequencies are highlighted with * *:
check_1 (16) (8) / | eq_1~ | (8) / | / check_2 (*8*) / (8) / | \ eq_2 | (*0*) \ \ | ` --- check_3 (16) (1) / | (loop exit) | (15) | (back edge)
Next we thread eq_1 -> check_3 and eq_2 -> check_3 to check_1 as new back edges. Frequencies are updated to remove the frequency of eq_1 and eq_3 from check_3 and then the false edge leaving check_3 (changed frequencies are highlighted with * *):
check_1 (16) (8) / | eq_1~ | (8) / | / check_2 (*8*) / (8) / | /-- eq_2~ | (*0*) (back edge) | check_3 (*0*) (*0*) / | (loop exit) | (*0*) | (back edge)
As a result, the loop exit edge ends up with 0 frequency which in turn makes the loop header to have maximum frequency.
There are a few potential problems here:
1. The profile data seems odd. There is a single profile sample of the loop being entered. On the other hand, there are no weights inside the loop.
2. Based on static estimation we shouldn't set edges to "extreme" values, i.e. extremely likely or unlikely.
3. We shouldn't create profile metadata that is calculated from static estimation. I am not sure what policy is but it seems to make sense to treat profile metadata as something that is known to originate from profiling. Estimated probabilities should only be reflected in BPI/BFI.
Any one of these would probably fix the immediate problem. I went for 3 because I think it's a good policy to have and added a FIXME about 2.
Differential Revision: https://reviews.llvm.org/D24118
llvm-svn: 280713
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2 |
|
#
0d955d0b |
| 11-Aug-2016 |
David Majnemer <david.majnemer@gmail.com> |
Use the range variant of find instead of unpacking begin/end
If the result of the find is only used to compare against end(), just use is_contained instead.
No functionality change is intended.
ll
Use the range variant of find instead of unpacking begin/end
If the result of the find is only used to compare against end(), just use is_contained instead.
No functionality change is intended.
llvm-svn: 278433
show more ...
|
#
36e0d01e |
| 09-Aug-2016 |
Sean Silva <chisophugis@gmail.com> |
Consistently use FunctionAnalysisManager
Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching e
Consistently use FunctionAnalysisManager
Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly.
Thanks to David for the suggestion.
llvm-svn: 278077
show more ...
|
#
02419a98 |
| 08-Aug-2016 |
Eli Friedman <eli.friedman@gmail.com> |
[JumpThreading] Fix handling of aliasing metadata.
Summary: The correctness fix here is that when we CSE a load with another load, we need to combine the metadata on the two loads. This matches the
[JumpThreading] Fix handling of aliasing metadata.
Summary: The correctness fix here is that when we CSE a load with another load, we need to combine the metadata on the two loads. This matches the behavior of other passes, like instcombine and GVN.
There's also a minor optimization improvement here: for load PRE, the aliasing metadata on the inserted load should be the same as the metadata on the original load. Not sure why the old code was throwing it away.
Issue found by inspection.
Differential Revision: http://reviews.llvm.org/D21460
llvm-svn: 277977
show more ...
|
Revision tags: llvmorg-3.9.0-rc1 |
|
#
522a9118 |
| 22-Jul-2016 |
David Majnemer <david.majnemer@gmail.com> |
Don't remove side effecting instructions due to ConstantFoldInstruction
Just because we can constant fold the result of an instruction does not imply that we can delete the instruction. It may have
Don't remove side effecting instructions due to ConstantFoldInstruction
Just because we can constant fold the result of an instruction does not imply that we can delete the instruction. It may have side effects.
This fixes PR28655.
llvm-svn: 276389
show more ...
|
#
13623ad0 |
| 14-Jul-2016 |
Sanjoy Das <sanjoy@playingwithpointers.com> |
[JumpThreading] PRE unordered loads
Summary: Extend JumpThreading's PRE to unordered atomic loads.
Reviewers: hfinkel, reames
Subscribers: mcrosier, llvm-commits
Differential Revision: http://rev
[JumpThreading] PRE unordered loads
Summary: Extend JumpThreading's PRE to unordered atomic loads.
Reviewers: hfinkel, reames
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D22326
llvm-svn: 275456
show more ...
|
#
931df67a |
| 13-Jul-2016 |
Sanjoy Das <sanjoy@playingwithpointers.com> |
[JumpThreading] Delete commented out debug code; NFC
llvm-svn: 275346
|
#
f50d4b6c |
| 06-Jul-2016 |
Sean Silva <chisophugis@gmail.com> |
Work around PR28400 a bit harder.
We were still crashing in the "no change" case because LVI was not getting invalidated.
See the thread "Should analyses be able to hold AssertingVH to IR? (related
Work around PR28400 a bit harder.
We were still crashing in the "no change" case because LVI was not getting invalidated.
See the thread "Should analyses be able to hold AssertingVH to IR? (related to PR28400)" for more discussion.
llvm-svn: 274656
show more ...
|
#
fa6db901 |
| 03-Jul-2016 |
Sean Silva <chisophugis@gmail.com> |
PR28400: Partly undo r274440 to bring test-suite back to life with the new PM
PR28400 seems to be not an isolated issue, but a general problem related to caching analyses. We will need to discuss on
PR28400: Partly undo r274440 to bring test-suite back to life with the new PM
PR28400 seems to be not an isolated issue, but a general problem related to caching analyses. We will need to discuss on llvm-dev.
A test case is in the PR.
llvm-svn: 274457
show more ...
|
#
f2db01c6 |
| 02-Jul-2016 |
Sean Silva <chisophugis@gmail.com> |
[PM] Fix a small typo from when I ported JumpThreading
llvm-svn: 274440
|
#
b8da3a2b |
| 25-Jun-2016 |
David Majnemer <david.majnemer@gmail.com> |
Reinstate r273711
r273711 was reverted by r273743. The inliner needs to know about any call sites in the inlined function. These were obscured if we replaced a call to undef with an undef but kept
Reinstate r273711
r273711 was reverted by r273743. The inliner needs to know about any call sites in the inlined function. These were obscured if we replaced a call to undef with an undef but kept the call around.
This fixes PR28298.
llvm-svn: 273753
show more ...
|
#
ae2ef4cc |
| 24-Jun-2016 |
Nico Weber <nicolasweber@gmx.de> |
Revert r273711, it caused PR28298.
llvm-svn: 273743
|
#
3b3e954e |
| 24-Jun-2016 |
David Majnemer <david.majnemer@gmail.com> |
SimplifyInstruction does not imply DCE
We cannot remove an instruction with no uses just because SimplifyInstruction succeeds. It may have side effects.
llvm-svn: 273711
|
#
87f0d0e1 |
| 16-Jun-2016 |
Igor Laevsky <igmyrj@gmail.com> |
Revert r272891 "[JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfo"
It was causing failures in Profile-i386 and Profile-x86_64 tests.
llvm-svn: 272912
|
#
c9179fd2 |
| 16-Jun-2016 |
Igor Laevsky <igmyrj@gmail.com> |
[JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfo
We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise we will get danglin
[JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfo
We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise we will get dangling pointer inside BranchProbabilityInfo cache.
Differential Revision: http://reviews.llvm.org/D20957
llvm-svn: 272891
show more ...
|
#
46590d55 |
| 14-Jun-2016 |
Sean Silva <chisophugis@gmail.com> |
Bring back "[PM] Port JumpThreading to the new PM" with a fix
This reverts commit r272603 and adds a fix.
Big thanks to Davide for pointing me at r216244 which gives some insight into how to fix th
Bring back "[PM] Port JumpThreading to the new PM" with a fix
This reverts commit r272603 and adds a fix.
Big thanks to Davide for pointing me at r216244 which gives some insight into how to fix this VS2013 issue. VS2013 can't synthesize a move constructor. So the fix here is to add one explicitly to the JumpThreadingPass class.
llvm-svn: 272607
show more ...
|
#
7d5a57cb |
| 14-Jun-2016 |
Sean Silva <chisophugis@gmail.com> |
Revert "[PM] Port JumpThreading to the new PM"
This reverts commit r272597.
Will investigate issue with VS2013 compilation and then recommit.
llvm-svn: 272603
|
#
f81328d0 |
| 13-Jun-2016 |
Sean Silva <chisophugis@gmail.com> |
[PM] Port JumpThreading to the new PM
This follows the approach in r263208 (for GVN) pretty closely: - move the bulk of the body of the function to the new PM class. - expose a runImpl method on the
[PM] Port JumpThreading to the new PM
This follows the approach in r263208 (for GVN) pretty closely: - move the bulk of the body of the function to the new PM class. - expose a runImpl method on the new-PM class that takes the IRUnitT and pointers/references to any analyses and use that to implement the old-PM class. - use a private namespace in the header for stuff that used to be file scope
llvm-svn: 272597
show more ...
|