#
b55637b5 |
| 29-Mar-2019 |
Philip Reames <listmail@philipreames.com> |
[LoopPredication] Remove stale TODO
llvm-svn: 357331
|
#
3d4e1082 |
| 29-Mar-2019 |
Philip Reames <listmail@philipreames.com> |
[LoopPredication] Use the builder's insertion point everywhere [NFC]
llvm-svn: 357330
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
feb475f4 |
| 22-Jan-2019 |
Max Kazantsev <max.kazantsev@azul.com> |
[LoopPredication] Support guards expressed as branches by widenable condition
This patch adds support of guards expressed as branches by widenable conditions in Loop Predication.
Differential Revis
[LoopPredication] Support guards expressed as branches by widenable condition
This patch adds support of guards expressed as branches by widenable conditions in Loop Predication.
Differential Revision: https://reviews.llvm.org/D56081 Reviewed By: reames
llvm-svn: 351805
show more ...
|
#
ca450878 |
| 22-Jan-2019 |
Max Kazantsev <max.kazantsev@azul.com> |
[NFC] Factor out some reusable logic
llvm-svn: 351794
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
28298e96 |
| 26-Dec-2018 |
Max Kazantsev <max.kazantsev@azul.com> |
[NFC] Use utility function for guards detection
llvm-svn: 350064
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
c297e84b |
| 17-Oct-2018 |
Fedor Sergeev <fedor.sergeev@azul.com> |
[LoopPredication] add some simple stats
Just adding some useful statistics to LoopPredication pass which was lacking any of these.
llvm-svn: 344681
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
#
f78650a8 |
| 30-Jul-2018 |
Fangrui Song <maskray@google.com> |
Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338293
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
#
d34e60ca |
| 14-May-2018 |
Nicola Zaghen <nicola.zaghen@imgtec.com> |
Rename DEBUG macro to LLVM_DEBUG. The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/
Rename DEBUG macro to LLVM_DEBUG. The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it.
In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one.
Differential Revision: https://reviews.llvm.org/D43624
llvm-svn: 332240
show more ...
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2 |
|
#
9b1176b0 |
| 22-Mar-2018 |
Anna Thomas <anna@azul.com> |
[LoopPredication] Add profitability check based on BPI
Summary: LoopPredication is not profitable when the loop is known to always exit through some block other than the latch block. A coarse graine
[LoopPredication] Add profitability check based on BPI
Summary: LoopPredication is not profitable when the loop is known to always exit through some block other than the latch block. A coarse grained latch check can cause loop predication to predicate the loop, and unconditionally deoptimize.
However, without predicating the loop, the guard may never fail within the loop during the dynamic execution because the non-latch loop termination condition exits the loop before the latch condition causes the loop to exit. We teach LP about this using BranchProfileInfo pass.
Reviewers: apilipenko, skatkov, mkazantsev, reames
Reviewed by: skatkov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44667
llvm-svn: 328210
show more ...
|
Revision tags: llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3 |
|
#
3cb4c34a |
| 09-Feb-2018 |
Serguei Katkov <serguei.katkov@azul.com> |
Rename and move utility function getLatchPredicateForGuard. NFC.
Rename getLatchPredicateForGuard to more common name getFlippedStrictnessPredicate and move it to ICmpInst class.
llvm-svn: 324717
|
#
c8016e7a |
| 08-Feb-2018 |
Serguei Katkov <serguei.katkov@azul.com> |
[Loop Predication] Teach LP about reverse loops with uge and sge latch conditions
Add support of uge and sge latch condition to Loop Prediction for reverse loops.
Reviewers: apilipenko, mkazantsev,
[Loop Predication] Teach LP about reverse loops with uge and sge latch conditions
Add support of uge and sge latch condition to Loop Prediction for reverse loops.
Reviewers: apilipenko, mkazantsev, sanjoy, anna Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42837
llvm-svn: 324589
show more ...
|
Revision tags: llvmorg-6.0.0-rc2 |
|
#
ebc9031b |
| 07-Feb-2018 |
Serguei Katkov <serguei.katkov@azul.com> |
[LoopPrediction] Introduce utility function getLatchPredicateForGuard. NFC.
Factor out getting the predicate for latch condition in a guard to utility function getLatchPredicateForGuard.
llvm-svn:
[LoopPrediction] Introduce utility function getLatchPredicateForGuard. NFC.
Factor out getting the predicate for latch condition in a guard to utility function getLatchPredicateForGuard.
llvm-svn: 324450
show more ...
|
#
0909ca13 |
| 26-Jan-2018 |
Hiroshi Inoue <inouehrs@jp.ibm.com> |
[NFC] fix trivial typos in comments and documents
"in in" -> "in", "on on" -> "on" etc.
llvm-svn: 323508
|
Revision tags: llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3 |
|
#
7b360434 |
| 04-Dec-2017 |
Anna Thomas <anna@azul.com> |
[Loop Predication] Teach LP about reverse loops
Summary: Currently, we only support predication for forward loops with step of 1. This patch enables loop predication for reverse or countdownLoops,
[Loop Predication] Teach LP about reverse loops
Summary: Currently, we only support predication for forward loops with step of 1. This patch enables loop predication for reverse or countdownLoops, which satisfy the following conditions: 1. The step of the IV is -1. 2. The loop has a singe latch as B(X) = X <pred> latchLimit with pred as s> or u> 3. The IV of the guard is the decrement IV of the latch condition (Guard is: G(X) = X-1 u< guardLimit).
This patch was downstream for a while and is the last series of patches that's from our LP implementation downstream.
Reviewers: apilipenko, mkazantsev, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40353
llvm-svn: 319659
show more ...
|
Revision tags: llvmorg-5.0.1-rc2 |
|
#
68797214 |
| 03-Nov-2017 |
Anna Thomas <anna@azul.com> |
[LoopPredication] NFC: Refactored code to separate out functions being reused
Summary: Refactored the code to separate out common functions that are being reused. This is to reduce the changes for c
[LoopPredication] NFC: Refactored code to separate out functions being reused
Summary: Refactored the code to separate out common functions that are being reused. This is to reduce the changes for changes coming up wrt loop predication with reverse loops.
This refactoring is what we have in our downstream code.
llvm-svn: 317324
show more ...
|
#
1d02b13e |
| 02-Nov-2017 |
Anna Thomas <anna@azul.com> |
[LoopPredication] Enable predication when latchCheckIV is wider than rangeCheck
Summary: This patch allows us to predicate range checks that have a type narrower than the latch check type. We levera
[LoopPredication] Enable predication when latchCheckIV is wider than rangeCheck
Summary: This patch allows us to predicate range checks that have a type narrower than the latch check type. We leverage SCEV analysis to identify a truncate for the latchLimit and latchStart. There is also safety checks in place which requires the start and limit to be known at compile time. We require this to make sure that the SCEV truncate expr for the IV corresponding to the latch does not cause us to lose information about the IV range. Added tests show the loop predication over range checks that are of various types and are narrower than the latch type. This enhancement has been in our downstream tree for a while.
Reviewers: apilipenko, sanjoy, mkazantsev
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39500
llvm-svn: 317269
show more ...
|
Revision tags: llvmorg-5.0.1-rc1 |
|
#
8aadc643 |
| 27-Oct-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] Handle the case when the guard and the latch IV have different offsets
This is a follow up change for D37569.
Currently the transformation is limited to the case when: * The loop
[LoopPredication] Handle the case when the guard and the latch IV have different offsets
This is a follow up change for D37569.
Currently the transformation is limited to the case when: * The loop has a single latch with the condition of the form: ++i <pred> latchLimit, where <pred> is u<, u<=, s<, or s<=. * The step of the IV used in the latch condition is 1. * The IV of the latch condition is the same as the post increment IV of the guard condition. * The guard condition is of the form i u< guardLimit.
This patch enables the transform in the case when the latch is
latchStart + i <pred> latchLimit, where <pred> is u<, u<=, s<, or s<=.
And the guard is
guardStart + i u< guardLimit
Reviewed By: anna
Differential Revision: https://reviews.llvm.org/D39097
llvm-svn: 316768
show more ...
|
#
ead69ee4 |
| 12-Oct-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] Check whether the loop is already guarded by the first iteration check condition
llvm-svn: 315623
|
#
b4527e1c |
| 12-Oct-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] Support ule, sle latch predicates
This is a follow up for the loop predication change 313981 to support ule, sle latch predicates.
Reviewed By: mkazantsev
Differential Revision:
[LoopPredication] Support ule, sle latch predicates
This is a follow up for the loop predication change 313981 to support ule, sle latch predicates.
Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D38177
llvm-svn: 315616
show more ...
|
#
889dc1e3 |
| 22-Sep-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
Rework loop predication pass
We've found a serious issue with the current implementation of loop predication. The current implementation relies on SCEV and this turned out to be problematic. To fix
Rework loop predication pass
We've found a serious issue with the current implementation of loop predication. The current implementation relies on SCEV and this turned out to be problematic. To fix the problem we had to rework the pass substantially. We have had the reworked implementation in our downstream tree for a while. This is the initial patch of the series of changes to upstream the new implementation.
For now the transformation is limited to the following case: * The loop has a single latch with either ult or slt icmp condition. * The step of the IV used in the latch condition is 1. * The IV of the latch condition is the same as the post increment IV of the guard condition. * The guard condition is ult.
See the review or the LoopPredication.cpp header for the details about the problem and the new implementation.
Reviewed By: sanjoy, mkazantsev
Differential Revision: https://reviews.llvm.org/D37569
llvm-svn: 313981
show more ...
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
#
6bda14b3 |
| 06-Jun-2017 |
Chandler Carruth <chandlerc@gmail.com> |
Sort the remaining #include lines in include/... and lib/....
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
Sort the remaining #include lines in include/... and lib/....
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).
llvm-svn: 304787
show more ...
|
Revision tags: llvmorg-4.0.1-rc2 |
|
#
edee2515 |
| 22-May-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] NFC. Add extra debug output in case we fail to parse the range check
llvm-svn: 303544
|
#
c488dfab |
| 22-May-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] NFC. Move a nested struct declaration before the fields, clang-format a bit
This will simplify the diff for an upcoming review.
llvm-svn: 303543
|
#
a6c27804 |
| 19-May-2017 |
Artur Pilipenko <apilipenko@azulsystems.com> |
[LoopPredication] NFC. Extract LoopICmp struct and parseLoopICmp helper
llvm-svn: 303427
|