|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3 |
|
| #
f3c5289e |
| 05-Oct-2022 |
Martin Storsjö <[email protected]> |
Revert "Recommit "[SCEV] Look through single value PHIs." (take 3)"
This reverts commit 20d798bd47ec5191de1b2a8a031da06a04e612e1.
This commit caused crashes in some cases, see github issue #58152.
Revert "Recommit "[SCEV] Look through single value PHIs." (take 3)"
This reverts commit 20d798bd47ec5191de1b2a8a031da06a04e612e1.
This commit caused crashes in some cases, see github issue #58152. This is fixed on main, but backporting it requires multiple nontrivial cherrypicks.
Updating llvm/test/Transforms/LoopVectorize/create-induction-resume.ll with update_test_checks.py, so this isn't an exact automatic revert, as that test case was added after the reverted commit.
This fixes #58152 for the release branch.
show more ...
|
|
Revision tags: llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
a053f359 |
| 25-Jul-2022 |
Max Kazantsev <[email protected]> |
[SCEV][NFC][CT] Cheaper handling of guards in isBasicBlockEntryGuardedByCond
Handle guards uniformly with assumes, rather than iterating through all block instructions in attempt to find them.
Diff
[SCEV][NFC][CT] Cheaper handling of guards in isBasicBlockEntryGuardedByCond
Handle guards uniformly with assumes, rather than iterating through all block instructions in attempt to find them.
Differential Revision: https://reviews.llvm.org/D129874 Reviewed By: nikic
show more ...
|
| #
e0ccd190 |
| 20-Jul-2022 |
Max Kazantsev <[email protected]> |
[SCEV][NFC][CT] Do not waste time proving contextual facts for unreached loops and blocks
In fact, in unreached code we can say that every fact is true. So do not waste time trying to do something s
[SCEV][NFC][CT] Do not waste time proving contextual facts for unreached loops and blocks
In fact, in unreached code we can say that every fact is true. So do not waste time trying to do something smarter.
Formally it's not an NFC because it may change query results in unreached code, but they won't have any impact on execution.
Hypothetical CT boost expected but not measured in practice.
Differential Revision: https://reviews.llvm.org/D129878
show more ...
|
| #
601b3a13 |
| 17-Jul-2022 |
Kazu Hirata <[email protected]> |
[Analysis] Qualify auto variables in for loops (NFC)
|
| #
883e83d5 |
| 15-Jul-2022 |
Max Kazantsev <[email protected]> |
[NFC][SCEV] Rename variable to correspond its current meaning
|
| #
2659e1bf |
| 15-Jul-2022 |
Nikita Popov <[email protected]> |
[SCEV] List all binops in getOperandsToCreate()
Explicitly list all binops rather than having a default case. There were two bugs here: 1. U->getOpcode() was used instead of BO->Opcode, which means
[SCEV] List all binops in getOperandsToCreate()
Explicitly list all binops rather than having a default case. There were two bugs here: 1. U->getOpcode() was used instead of BO->Opcode, which means we used the logic for the wrong opcode in some cases. 2. SCEV construction does not support LShr. We should return unknown for it rather than recursing into the operands.
show more ...
|
| #
e7ec1746 |
| 14-Jul-2022 |
Florian Hahn <[email protected]> |
[SCEV] Avoid creating unnecessary SCEVs for SelectInsts.
After 675080a4533b, we always create SCEVs for all operands of a SelectInst. This can cause notable compile-time regressions compared to the
[SCEV] Avoid creating unnecessary SCEVs for SelectInsts.
After 675080a4533b, we always create SCEVs for all operands of a SelectInst. This can cause notable compile-time regressions compared to the recursive algorithm, which only evaluates the operands if the select is in a form we can create a usable expression.
This approach adds additional logic to getOperandsToCreate to only queue operands for selects if we will later be able to construct a usable SCEV.
Unfortunately this introduces a bit of coupling between actual SCEV construction for selects and getOperandsToCreate, but I am not sure if there are better alternatives to address the regression mentioned for 675080a4533b.
This doesn't have any notable compile-time impact on CTMark.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D129731
show more ...
|
| #
3bc09c7d |
| 14-Jul-2022 |
Philip Reames <[email protected]> |
[SCEVExpander] Allow udiv with isKnownNonZero(RHS) + add vscale case
Motivation here is to unblock LSRs ability to use ICmpZero uses - the major effect of which is to enable count down IVs. The test
[SCEVExpander] Allow udiv with isKnownNonZero(RHS) + add vscale case
Motivation here is to unblock LSRs ability to use ICmpZero uses - the major effect of which is to enable count down IVs. The test changes reflect this goal, but the potential impact is much broader since this isn't a change in LSR at all.
SCEVExpander needs(*) to prove that expanding the expression is safe anywhere the SCEV expression is valid. In general, we can't expand any node which might fault (or exhibit UB) unless we can either a) prove it won't fault, or b) guard the faulting case. We'd been allowing non-zero constants here; this change extends it to non-zero values.
vscale is never zero. This is already implemented in ValueTracking, and this change just adds the same logic in SCEV's range computation (which in turn drives isKnownNonZero). We should common up some logic here, but let's do that in separate changes.
(*) As an aside, "needs" is such an interesting word here. First, we don't actually need to guard this at all; we could choose to emit a select for the RHS of ever udiv and remove this code entirely. Secondly, the property being checked here is way too strong. What the client actually needs is to expand the SCEV at some particular point in some particular loop. In the examples, the original urem dominates that loop and yet we completely ignore that information when analyzing legality. I don't plan to actively pursue either direction, just noting it for future reference.
Differential Revision: https://reviews.llvm.org/D129710
show more ...
|
| #
611ffcf4 |
| 14-Jul-2022 |
Kazu Hirata <[email protected]> |
[llvm] Use value instead of getValue (NFC)
|
| #
30e33b4b |
| 13-Jul-2022 |
Max Kazantsev <[email protected]> |
[SCEV][NFC] Make getStrengthenedNoWrapFlagsFromBinOp return optional
|
| #
935570b2 |
| 29-Jun-2022 |
Nikita Popov <[email protected]> |
[ConstExpr] Don't create div/rem expressions
This removes creation of udiv/sdiv/urem/srem constant expressions, in preparation for their removal. I've added a ConstantExpr::isDesirableBinOp() predic
[ConstExpr] Don't create div/rem expressions
This removes creation of udiv/sdiv/urem/srem constant expressions, in preparation for their removal. I've added a ConstantExpr::isDesirableBinOp() predicate to determine whether an expression should be created for a certain operator.
With this patch, div/rem expressions can still be created through explicit IR/bitcode, forbidding them entirely will be the next step.
Differential Revision: https://reviews.llvm.org/D128820
show more ...
|
| #
e4d1d0cc |
| 27-Jun-2022 |
Nikita Popov <[email protected]> |
[SCEV] Fix isImpliedViaMerge() with values from previous iteration (PR56242)
When trying to prove an implied condition on a phi by proving it for all incoming values, we need to be careful about val
[SCEV] Fix isImpliedViaMerge() with values from previous iteration (PR56242)
When trying to prove an implied condition on a phi by proving it for all incoming values, we need to be careful about values coming from a backedge, as these may refer to a previous loop iteration. A variant of this issue was fixed in D101829, but the dominance condition used there isn't quite right: It checks that the value dominates the incoming block, which doesn't exclude backedges (values defined in a loop will usually dominate the loop latch, which is the incoming block of the backedge).
Instead, we should be checking for domination of the phi block. Any values defined inside the loop will not dominate the loop header phi.
Fixes https://github.com/llvm/llvm-project/issues/56242.
Differential Revision: https://reviews.llvm.org/D128640
show more ...
|
| #
2c3784cf |
| 29-Jun-2022 |
Chen Zheng <[email protected]> |
[SCEV] recognize llvm.annotation intrinsic
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D127835
|
| #
c8bd3e78 |
| 01-Jul-2022 |
Nikita Popov <[email protected]> |
[SCEV] Remove unnecessary pointer handling in BuildConstantFromSCEV (NFCI)
Nowadays, we do not allow pointers in multiplies, and adds can only have a single pointer, which is also guaranteed to be l
[SCEV] Remove unnecessary pointer handling in BuildConstantFromSCEV (NFCI)
Nowadays, we do not allow pointers in multiplies, and adds can only have a single pointer, which is also guaranteed to be last by complexity sorting. As such, we can somewhat simplify the treatment of pointer types.
show more ...
|
| #
0445c340 |
| 30-Jun-2022 |
Nikita Popov <[email protected]> |
[ConstantFold] Support loads in ConstantFoldInstOperands()
This allows all constant folding to happen through a single function, without requiring special handling for loads at each call-site.
This
[ConstantFold] Support loads in ConstantFoldInstOperands()
This allows all constant folding to happen through a single function, without requiring special handling for loads at each call-site.
This may not be NFC because some callers currently don't do that special handling.
show more ...
|
| #
a6d4b413 |
| 30-Jun-2022 |
Nikita Popov <[email protected]> |
[ConstantFold] Supports compares in ConstantFoldInstOperands()
Support compares in ConstantFoldInstOperands(), instead of forcing the use of ConstantFoldCompareInstOperands(). Also handle insertvalu
[ConstantFold] Supports compares in ConstantFoldInstOperands()
Support compares in ConstantFoldInstOperands(), instead of forcing the use of ConstantFoldCompareInstOperands(). Also handle insertvalue (extractvalue was already handled).
This removes a footgun, where many uses of ConstantFoldInstOperands() need a separate check for compares beforehand. It's particularly insidious if called on a constant expression, because it doesn't fail in that case, but will just not do DL-dependent folding.
show more ...
|
| #
30ea6a06 |
| 29-Jun-2022 |
Nikita Popov <[email protected]> |
[SCEV] Don't create udiv constant expression (NFC)
Work on APInts to make it clear that this will not create a constant expression.
This code path is not reached if the RHS is zero.
|
| #
675080a4 |
| 29-Jun-2022 |
Florian Hahn <[email protected]> |
[SCEV] Construct SCEV iteratively.
This patch updates SCEV construction to work iteratively instead of recursively in most cases. It resolves stack overflow issues when trying to construct SCEVs for
[SCEV] Construct SCEV iteratively.
This patch updates SCEV construction to work iteratively instead of recursively in most cases. It resolves stack overflow issues when trying to construct SCEVs for certain inputs, e.g. PR45201.
The basic approach is to to use a worklist to queue operands of V which need to be created before V. To do so, the current patch adds a getOperandsToCreate function which collects the operands SCEV construction depends on for a given value. This is a slight duplication with createSCEV.
At the moment, SCEVs for phis are still created recursively.
Fixes #32078, #42594, #44546, #49293, #49599, #55333, #55511
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D114650
show more ...
|
| #
327307d9 |
| 27-Jun-2022 |
Nikita Popov <[email protected]> |
[SCEV] Assert that GEP source element type is sized (NFC)
This is checked by the IR verifier, so replace the condition with an assert.
|
| #
e4e22b6d |
| 27-Jun-2022 |
Florian Hahn <[email protected]> |
[SCEV] Use SCEVUnknown(poison) instead of SCEVUnknown(undef).
Use poison instead of undef for SCEVUnkown of unreachable values. This should be in line with the movement to replace undef with poison
[SCEV] Use SCEVUnknown(poison) instead of SCEVUnknown(undef).
Use poison instead of undef for SCEVUnkown of unreachable values. This should be in line with the movement to replace undef with poison when possible.
Suggested in D114650.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D128586
show more ...
|
| #
a7938c74 |
| 26-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::hasValue (NFC)
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
|
| #
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
| #
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
7a47ee51 |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::getValue (NFC)
|
| #
0916d96d |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|