History log of /llvm-project/llvm/lib/Transforms/Scalar/LoopPredication.cpp (Results 76 – 100 of 106)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12345