Summary:
Currently, when a loop is cloned while inlining function (A) into function (B) the loop metadata is copied and then not modified at all. The loop metadata can encode the loop's start and end DILocations. Therefore, the new inlined loop in function (B) may have loop metadata which shows start and end locations residing in function (A).
This patch ensures loop metadata is updated while inlining so that the start and end DILocations are given the "inlinedAt" operand. I've also added a regression test for this.
This fix is required for D60831 because that patch uses loop metadata to determine the DILocation for the branches of new loop preheaders.
Reviewers: aprantl, dblaikie, anemet
Reviewed By: aprantl
Subscribers: eraman, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D61933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361132 91177308-0d34-0410-b5e6-96231b3b80d8
This is the sibling transform for rL360899 (D61691):
maxnum(X, GreaterC) == C --> false
maxnum(X, GreaterC) <= C --> false
maxnum(X, GreaterC) < C --> false
maxnum(X, GreaterC) >= C --> true
maxnum(X, GreaterC) > C --> true
maxnum(X, GreaterC) != C --> true
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361118 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In D61918 i was looking at dropping it in DAGCombiner `visitShiftByConstant()`,
but as @craig.topper pointed out, it was copied from here.
That check claims that the transform is illegal otherwise.
That isn't true:
1. For `ISD::ADD`, we only process `ISD::SHL` outer shift => sign bit does not matter
https://rise4fun.com/Alive/K4A
2. For `ISD::AND`, there is no restriction on constants:
https://rise4fun.com/Alive/Wy3
3. For `ISD::OR`, there is no restriction on constants:
https://rise4fun.com/Alive/GOH
3. For `ISD::XOR`, there is no restriction on constants:
https://rise4fun.com/Alive/ml6
So, why is it there then?
As far as i can tell, it dates all the way back to original check-in rL7793.
I think we should just drop it.
Reviewers: spatel, craig.topper, efriedma, majnemer
Reviewed By: spatel
Subscribers: llvm-commits, craig.topper
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61938
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361043 91177308-0d34-0410-b5e6-96231b3b80d8
With a fix for PR41917: The predecessor list was changing under our feet.
- for (BasicBlock *Pred : predecessors(EntryBlock_)) {
+ while (!pred_empty(EntryBlock_)) {
+ BasicBlock* const Pred = *pred_begin(EntryBlock_);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361009 91177308-0d34-0410-b5e6-96231b3b80d8
These are all of the ones involving the same data layout string. Remainder take a bit more consideration, but at least everything can be auto-updated now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360961 91177308-0d34-0410-b5e6-96231b3b80d8
Newly written tests to cover the simple cases. We don't appear to have broad coverage of this transform anywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360957 91177308-0d34-0410-b5e6-96231b3b80d8
These were new tests I added in r360808. I made a mistake while converting the exisiting binary FNeg test into the new unary FNeg tests. Correct that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360928 91177308-0d34-0410-b5e6-96231b3b80d8
This is the conservatively correct default. It is always safe to
assume xnack is enabled, but not the converse.
Introduce a feature to blacklist targets where xnack can never be
meaningfully enabled. I'm not sure the targets this is applied to is
100% correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360903 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645
Previously, LLVM had no functional way of performing casts inside of a
DIExpression(), which made salvaging cast instructions other than Noop casts
impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is
now possible, and so can be used to fix the attached bug as well as any cases
where SExt instruction results are lost in the debugging metadata. This patch
introduces this fix by expanding the salvage debug info method to cover these
cases using the new operator.
Differential revision: https://reviews.llvm.org/D61184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360902 91177308-0d34-0410-b5e6-96231b3b80d8
minnum(X, LesserC) == C --> false
minnum(X, LesserC) >= C --> false
minnum(X, LesserC) > C --> false
minnum(X, LesserC) != C --> true
minnum(X, LesserC) <= C --> true
minnum(X, LesserC) < C --> true
maxnum siblings will follow if there are no problems here.
We should be able to perform some other combines when the constants
are equal or greater-than too, but that would go in instcombine.
We might also generalize this by creating an FP ConstantRange
(similar to what we do for integers).
Differential Revision: https://reviews.llvm.org/D61691
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360899 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We should excluded unreachable operands from processing as their DFS visitation order is undefined. When `renameUses` function sorts `OpsToRename` (https://fburl.com/d2wubn60), the comparator assumes that the parent block of the operand has a corresponding dominator tree node. This is not the case for unreachable operands and crashes the compiler.
Reviewers: dberlin, mgrang, davide
Subscribers: efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61154
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360796 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The return value of a TryToUnfoldSelect call was not checked, which led to an
incorrectly preserved loop info and some crash.
The original crash was reported on https://reviews.llvm.org/D59514.
Reviewers: davidxl, amehsan
Reviewed By: davidxl
Subscribers: fhahn, brzycki, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61920
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360780 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645
Previously, LLVM had no functional way of performing casts inside of a
DIExpression(), which made salvaging cast instructions other than Noop
casts impossible. With the recent addition of DW_OP_LLVM_convert this
salvaging is now possible, and so can be used to fix the attached bug as
well as any cases where SExt instruction results are lost in the
debugging metadata. This patch introduces this fix by expanding the
salvage debug info method to cover these cases using the new operator.
Differential revision: https://reviews.llvm.org/D61184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360772 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of patching the original blocks, we now generate new blocks and
delete the old blocks. This results in simpler code with a less twisted
control flow (see the change in `entry-block-shuffled.ll`).
This will make https://reviews.llvm.org/D60318 simpler by making it more
obvious where control flow created and deleted.
Reviewers: gchatelet
Subscribers: hiraditya, llvm-commits, spatel
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360771 91177308-0d34-0410-b5e6-96231b3b80d8
The 3-field form was introduced by D3499 in 2014 and the legacy 2-field
form was planned to be removed in LLVM 4.0
For the textual format, this patch migrates the existing 2-field form to
use the 3-field form and deletes the compatibility code.
test/Verifier/global-ctors-2.ll checks we have a friendly error message.
For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the
2-field form (add i8* null as the third field).
Reviewed By: rnk, dexonsmith
Differential Revision: https://reviews.llvm.org/D61547
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360742 91177308-0d34-0410-b5e6-96231b3b80d8
When an outer loop gets deleted by a different pass, before LICM visits
it, we cannot clean up its sub-loops in AliasSetMap, because at the
point we receive the deleteAnalysisLoop callback for the outer loop, the loop
object is already invalid and we cannot access its sub-loops any longer.
Reviewers: asbirlea, sanjoy, chandlerc
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D61904
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360704 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed while glancing through the code for other reasons. The extension is trivial enough, decided to just do it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360694 91177308-0d34-0410-b5e6-96231b3b80d8
Some atomic loads are implemented as cmpxchg (particularly if large or
floating), and that usually requires write access to the memory involved
or it will segfault.
We can still propagate the constant value to users we understand though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360662 91177308-0d34-0410-b5e6-96231b3b80d8
Orlando Cazalet-Hyams