Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions llvm/include/llvm/Analysis/DependenceAnalysis.h
Original file line number Diff line number Diff line change
Expand Up @@ -921,6 +921,7 @@ class DependenceInfo {
/// checkDstSubscript to avoid duplicate code
bool checkSubscript(const SCEV *Expr, const Loop *LoopNest,
SmallBitVector &Loops, bool IsSrc);

}; // class DependenceInfo

/// AnalysisPass to compute dependence information in a function
Expand Down
349 changes: 345 additions & 4 deletions llvm/lib/Analysis/DependenceAnalysis.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -3308,6 +3308,322 @@ void DependenceInfo::updateDirection(Dependence::DVEntry &Level,
llvm_unreachable("constraint has unexpected kind");
}

namespace {

enum class MonotonicityType {
MaySignedWrap, ///< The expression contains arithmetic operations that may
///< cause signed wrap.
Constant, ///< The expression is constant. If a SCEV is classified as
///< Constant, it also implies that it doesn't contain any
///< arithmetic operations that may cause signed wrap.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the utility of Constant? isa<SCEVConstant>(...) should be sufficient. Did you mean "invariant" to a specific loop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, "invariant" seems more reasonable here.

Monotonic, ///< The expression is monotonically increasing or decreasing. This
///< is exclusive of Constant. That is, we say an SCEV is Monotonic
///< iff it contains at least one AddRec where its step reccurence
///< value is non-zero.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the description should mention it is relative to a specific loop. If it does not contain an SCEVAddRec, it could still contain a SCEVUnkown that is non-invariant in that loop.

It becomes interesting if you have a SCEVAddRec of a nested loop in there. How do you think those should be handled? E.g. the specific loop is counting up but the nested loop is counting down.

for (int i = n; i >= 0; --i) {
  int j = 0;
  for (; j < m; ++j)
    A[i + j] = ...;
  B[i + j] = ...;
}

Is the SCEV for A[i + j] monotonic? I think it for B[i + j] because at that point j==m is invariant, so the min is 0 + m and the max is n + m.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely sure whether the term "monotonic" is appropriate here, but I believe A[i + j] in the example is "valid" in the context of DA. I think what I'm trying to conceptualize is something like how multilinear relates to linear -- perhaps something like 'multimonotonic' for monotonic?

So, I intended these properties to be considered with respect to the outermost loop, rather than any specific loop within the loop nest. In any case, I'm now feeling strongly that I should add some tests to illustrate the expected behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some cases to monotonic.ll to illustrate my thoughts. I used debug outputs for now, but I'd prefer to avoid if it possible...

};

/// A visitor that checks the signed monotonicity of SCEVs.
struct SCEVSignedMonotonicityChecker
: public SCEVVisitor<SCEVSignedMonotonicityChecker, MonotonicityType> {
/// \p Ptr is the pointer that the SCEV is associated with, if any. It may be
/// used for the inferrence.
SCEVSignedMonotonicityChecker(ScalarEvolution *SE, const Loop *OutermostLoop,
const Value *Ptr = nullptr)
: SE(SE), OutermostLoop(OutermostLoop), Ptr(Ptr) {}

MonotonicityType visitAddExpr(const SCEVAddExpr *Expr);
MonotonicityType visitAddRecExpr(const SCEVAddRecExpr *Expr);
MonotonicityType visitMulExpr(const SCEVMulExpr *Expr);
MonotonicityType visitUnknown(const SCEVUnknown *Expr);
MonotonicityType visitZeroExtendExpr(const SCEVZeroExtendExpr *Expr);
MonotonicityType visitSignExtendExpr(const SCEVSignExtendExpr *Expr);

MonotonicityType visitConstant(const SCEVConstant *) {
return MonotonicityType::Constant;
}
MonotonicityType visitVScale(const SCEVVScale *) {
return MonotonicityType::Constant;
}

// TODO: Handle more cases.
MonotonicityType visitPtrToIntExpr(const SCEVPtrToIntExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitTruncateExpr(const SCEVTruncateExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitUDivExpr(const SCEVUDivExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitSMaxExpr(const SCEVSMaxExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitUMaxExpr(const SCEVUMaxExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitSMinExpr(const SCEVSMinExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitUMinExpr(const SCEVUMinExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitSequentialUMinExpr(const SCEVSequentialUMinExpr *) {
return MonotonicityType::MaySignedWrap;
}
MonotonicityType visitCouldNotCompute(const SCEVCouldNotCompute *) {
return MonotonicityType::MaySignedWrap;
}

private:
ScalarEvolution *SE;
const Loop *OutermostLoop;
Copy link
Member

@Meinersbur Meinersbur Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly remove the "Outermost", does not necessarily need to be an outermost loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel it's safer to make this outermost. Otherwise, unexpected behavior might occur in cases like below

; The value of step reccurence is not invariant with respect to the outer most
; loop (the i-loop).
;
; offset_i = 0;
; for (int i = 0; i < 100; i++) {
; for (int j = 0; j < 100; j++)
; a[offset_i + j] = 0;
; offset_i += (i % 2 == 0) ? 0 : 3;
; }
;
define void @step_is_variant(ptr %a) {
; CHECK-LABEL: 'step_is_variant'
; CHECK: Failed to prove monotonicity for: %offset.i
; CHECK: Failed to prove monotonicity for: {%offset.i,+,1}<nuw><nsw><%loop.j>
; CHECK: Monotonicity: Unknown expr: {%offset.i,+,1}<nuw><nsw><%loop.j>
;
entry:
br label %loop.i.header
loop.i.header:
%i = phi i64 [ 0, %entry ], [ %i.inc, %loop.i.latch ]
%offset.i = phi i64 [ 0, %entry ], [ %offset.i.next, %loop.i.latch ]
%step.i.0 = phi i64 [ 0, %entry ], [ %step.i.1, %loop.i.latch ]
%step.i.1 = phi i64 [ 3, %entry ], [ %step.i.0, %loop.i.latch ]
br label %loop.j
loop.j:
%j = phi i64 [ 0, %loop.i.header ], [ %j.inc, %loop.j ]
%offset = add nsw i64 %offset.i, %j
%idx = getelementptr inbounds i8, ptr %a, i64 %offset
store i8 0, ptr %idx
%j.inc = add nsw i64 %j, 1
%exitcond.j = icmp eq i64 %j.inc, 100
br i1 %exitcond.j, label %loop.i.latch, label %loop.j
loop.i.latch:
%i.inc = add nsw i64 %i, 1
%offset.i.next = add nsw i64 %offset.i, %step.i.0
%exitcond.i = icmp eq i64 %i.inc, 100
br i1 %exitcond.i, label %exit, label %loop.i.header
exit:
ret void
}

const Value *Ptr = nullptr;
};

using MinMaxType = std::pair<const SCEV *, const SCEV *>;
const MinMaxType Bottom = {nullptr, nullptr};

/// A visitor that calculates the possible minimum and maximum values of SCEVs.
/// This class assumes that the given SCEV is constant or monotonic.
struct SCEVMinMaxCalculator
: public SCEVVisitor<SCEVMinMaxCalculator, MinMaxType> {
SCEVMinMaxCalculator(ScalarEvolution *SE, const Loop *OutermostLoop)
: SE(SE), OutermostLoop(OutermostLoop) {}

MinMaxType visitAddExpr(const SCEVAddExpr *Expr);
MinMaxType visitAddRecExpr(const SCEVAddRecExpr *Expr);
MinMaxType visitMulExpr(const SCEVMulExpr *Expr);
MinMaxType visitSignExtendExpr(const SCEVSignExtendExpr *Expr);

MinMaxType visitUnknown(const SCEVUnknown *Expr) {
return constantHelper(Expr);
}
MinMaxType visitConstant(const SCEVConstant *Expr) {
return constantHelper(Expr);
}
MinMaxType visitVScale(const SCEVVScale *Expr) {
return constantHelper(Expr);
}

MinMaxType visitZeroExtendExpr(const SCEVZeroExtendExpr *) { return Bottom; }
MinMaxType visitPtrToIntExpr(const SCEVPtrToIntExpr *) { return Bottom; }
MinMaxType visitTruncateExpr(const SCEVTruncateExpr *) { return Bottom; }
MinMaxType visitUDivExpr(const SCEVUDivExpr *) { return Bottom; }
MinMaxType visitSMaxExpr(const SCEVSMaxExpr *) { return Bottom; }
MinMaxType visitUMaxExpr(const SCEVUMaxExpr *) { return Bottom; }
MinMaxType visitSMinExpr(const SCEVSMinExpr *) { return Bottom; }
MinMaxType visitUMinExpr(const SCEVUMinExpr *) { return Bottom; }
MinMaxType visitSequentialUMinExpr(const SCEVSequentialUMinExpr *) {
return Bottom;
}
MinMaxType visitCouldNotCompute(const SCEVCouldNotCompute *) {
return Bottom;
}

MinMaxType constantHelper(const SCEV *C) { return MinMaxType(C, C); }

private:
ScalarEvolution *SE;
const Loop *OutermostLoop;
};

} // anonymous namespace

MonotonicityType
SCEVSignedMonotonicityChecker::visitAddExpr(const SCEVAddExpr *Expr) {
if (!Expr->hasNoSignedWrap())
return MonotonicityType::MaySignedWrap;

MonotonicityType Result = MonotonicityType::Constant;
for (const SCEV *Op : Expr->operands()) {
switch (visit(Op)) {
case MonotonicityType::MaySignedWrap:
return MonotonicityType::MaySignedWrap;
case MonotonicityType::Constant:
break;
case MonotonicityType::Monotonic:
// Monotonic + Monotonic might be constant, so at the moment return
// MaySignedWrap.
// TODO: Should we separate Monotonically increasing and decreasing? Or
// SCEV is always simplified enough so that we don't have to consider such
// cases?
if (Result == MonotonicityType::Monotonic)
return MonotonicityType::MaySignedWrap;
Result = MonotonicityType::Constant;
break;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont understand one thing here. If the entire SCEV is NSW, why do we need to check if its NSW for individual operands? Do you have specific case in mind?

Also, I am trying to understand what MonotonicityType::Monotonic really means. Just going by the mathematical definition of monotonicity,

  1. why Monotonic + Monotonic should be MaySignedWrap? Shouldnt it be Monotonic?
  2. why Monotonic + Constant should be Constant? Shouldnt it be Monotonic?

Copy link
Contributor Author

@kasuga-fj kasuga-fj Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, probably the name is misleading. MaySignedWrap should be renamed to something like Unknown.

If the entire SCEV is NSW, why do we need to check if its NSW for individual operands? Do you have specific case in mind?

I was imagining an example like {0,+,%m}<%loop> + {0,+,%n}<%loop>, but I'm not sure if such a representation can actually exist. If ScalarEvolution guarantees that this form is always folded into something like {0,+,(%m+%n)}<%loop>, then maybe this is unnecessary. But if not, I'm not confident it's safe when each operand can potentially overflow (although DA doesn't support this kind of format)

Just going by the mathematical definition of monotonicity

DA breaks exactly due to the gap between mathematical theory and LLVM IR semantics.

  1. why Monotonic + Monotonic should be MaySignedWrap? Shouldnt it be Monotonic?

To clearly distinguish between Constant and Monotonic. I was considering a case like {0,+,1}<%loop> + {0,+,-1}<%loop>. This always seems to evaluate to 0 (i.e., a Constant), but again, I'm not sure if such a representation can exist in SCEV.

  1. why Monotonic + Constant should be Constant? Shouldnt it be Monotonic?

I think this is just a simple implementation mistake. Thanks for pointing it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, probably the name is misleading. MaySignedWrap should be renamed to something like Unknown

ok, please change to Unknown or CouldNotCompute. MaySignedWrap is confusing

example like {0,+,%m}<%loop> + {0,+,%n}<%loop>

If the entire expression is nuw/nsw then individual SCEVs must follow the same pattern but vice-versa cant be true(this may wrap).

that this form is always folded into something like {0,+,(%m+%n)}<%loop>

this is not true because when its split form, each AddRed can have different values . But with (%m+%n) , every itr is multiple of (%m+%n)

{0,+,1}<%loop> + {0,+,-1}<%loop>

this expr can have values 0(=0+0), -1(=0-1), 1(=1+0), 0(=1-1). This is definitely not a constant. So, this should be Unknown

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm not entirely sure about is whether, given the following IR, the SCEV corresponding to %mn_i is guaranteed to be {0,+,(%m + %n)}<%loop> rather than {0,+,%m}<%loop> + {0,+,%n}<%loop>

loop:
  %i = phi i64 [ 0, %entry ], [ %i.inc, %loop ]
  %m_i = mul nsw i64 %m, %i
  %n_i = mul nsw i64 %n, %i
  %mn_i = add nsw i64 %m_i, %n_i
  ...

If not, then I don't think we can say "Monotonic + Monotonic = Monotonic", since %m could be equal to -1 * %n, in which case %mn_i would always be zero. I don't know whether a constant value is considered to "monotonic" in general mathematical theory, but it is a corner case in the context of DA.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if m is invariant in current loop then it should be {0,+,(%m + %n)}<%loop> and vice-versa if n comes from outer loop

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, then I think the logic can be simplified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kasuga-fj Expressions like {0,+,%m}<%loop> + {0,+,%n}<%loop> are possible if SCEV either hits the arithmetic depth limit, or the huge expression limit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikic I see, thanks for letting me know.

}
return Result;
}

MonotonicityType
SCEVSignedMonotonicityChecker::visitMulExpr(const SCEVMulExpr *Expr) {
if (!Expr->hasNoSignedWrap())
return MonotonicityType::MaySignedWrap;

// Same as visitAddExpr.
MonotonicityType Result = MonotonicityType::Constant;
for (const SCEV *Op : Expr->operands()) {
switch (visit(Op)) {
case MonotonicityType::MaySignedWrap:
return MonotonicityType::MaySignedWrap;
case MonotonicityType::Constant:
break;
case MonotonicityType::Monotonic:
if (Result == MonotonicityType::Monotonic)
return MonotonicityType::MaySignedWrap;
Result = MonotonicityType::Constant;
break;
}
}
return Result;
}

MonotonicityType
SCEVSignedMonotonicityChecker::visitAddRecExpr(const SCEVAddRecExpr *Expr) {
if (!Expr->isAffine())
return MonotonicityType::MaySignedWrap;

const SCEV *Start = Expr->getStart();
const SCEV *Step = Expr->getStepRecurrence(*SE);

MonotonicityType StartRes = visit(Start);
if (StartRes == MonotonicityType::MaySignedWrap)
return MonotonicityType::MaySignedWrap;

MonotonicityType StepRes = visit(Step);
if (StepRes != MonotonicityType::Constant || !SE->isKnownNonZero(Step))
return MonotonicityType::MaySignedWrap;

bool IsNSW = [&] {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be IsNoWrap ?

if (Expr->hasNoSignedWrap())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldnt you check for NoWrap? The expression, if unsigned, may not fit into the signed range

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentional. DA currently mixes signed and unsigned interpretations, which can lead to incorrect results. One of the main goals of this PR (and future ones) is to unify all integer interpretations in DA under a signed one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it only has nuw, the analysis would go wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and the expected behavior is to detect such expressions and bail out of the analysis. The subsequent checks attempt to prove properties similar to nsw when it's not explicitly attached, although I'm not sure they're truly necessary (I've not tested enough yet).

return true;

if (Ptr) {
// TODO: This seems incorrect. Maybe we should check the reachability from
// the GEP to the target instruction. E.g., in the following case, maybe
// no-wrap is not guaranteed:
//
// entry:
// ...
// %gep = getelementptr inbounds i32, ptr %ptr, i32 %addrec
// br i1 %cond, label %store, label %sink
//
// store:
// store i32 42, ptr %ptr
// br label %sink
//
// sink:
// ...
//
auto *GEP = dyn_cast<GetElementPtrInst>(Ptr);
if (GEP && GEP->hasNoUnsignedSignedWrap())
return true;
}

return false;
}();

if (!IsNSW) {
if (!SE->isKnownNegative(Step))
// If the coefficient can be positive value, ensure that the AddRec is
// monotonically increasing.
if (!SE->isKnownOnEveryIteration(ICmpInst::ICMP_SGE, Expr, Start))
return MonotonicityType::MaySignedWrap;

if (!SE->isKnownPositive(Step))
// If the coefficient can be positive value, ensure that the AddRec is
// monotonically decreasing.
if (!SE->isKnownOnEveryIteration(ICmpInst::ICMP_SLE, Expr, Start))
return MonotonicityType::MaySignedWrap;
}

return MonotonicityType::Monotonic;
}

MonotonicityType SCEVSignedMonotonicityChecker::visitZeroExtendExpr(
const SCEVZeroExtendExpr *Expr) {
return visit(Expr->getOperand());
}

MonotonicityType SCEVSignedMonotonicityChecker::visitSignExtendExpr(
const SCEVSignExtendExpr *Expr) {
return visit(Expr->getOperand());
}

MonotonicityType
SCEVSignedMonotonicityChecker::visitUnknown(const SCEVUnknown *Expr) {
return SE->isLoopInvariant(Expr, OutermostLoop)
? MonotonicityType::Constant
: MonotonicityType::MaySignedWrap;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is SCEVUnknown in the context of current loop. Why do we need to evaluate in the scope of outermost loop?

Copy link
Contributor Author

@kasuga-fj kasuga-fj Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to align with the current behavior.

// Returns true if Expression is loop invariant in LoopNest.
bool DependenceInfo::isLoopInvariant(const SCEV *Expression,
const Loop *LoopNest) const {
// Unlike ScalarEvolution::isLoopInvariant() we consider an access outside of
// any loop as invariant, because we only consier expression evaluation at a
// specific position (where the array access takes place), and not across the
// entire function.
if (!LoopNest)
return true;
// If the expression is invariant in the outermost loop of the loop nest, it
// is invariant anywhere in the loop nest.
return SE->isLoopInvariant(Expression, LoopNest->getOutermostLoop());
}

But I'm not sure whether checking invariance in the current loop is sufficient or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think conversely. If this was MonotonicityType::Constant, would this function be ever called? It should still be MonotonicityType::MaySignedWrap

}

MinMaxType SCEVMinMaxCalculator::visitAddExpr(const SCEVAddExpr *Expr) {
if (!Expr->hasNoSignedWrap())
return Bottom;

const SCEV *Min = SE->getZero(Expr->getType());
const SCEV *Max = SE->getZero(Expr->getType());
for (const SCEV *Op : Expr->operands()) {
auto [OpMin, OpMax] = visit(Op);
if (!OpMin || !OpMax)
return Bottom;
Min = SE->getAddExpr(Min, OpMin, Expr->getNoWrapFlags());
Max = SE->getAddExpr(Max, OpMax, Expr->getNoWrapFlags());
}
return MinMaxType(Min, Max);
}

MinMaxType SCEVMinMaxCalculator::visitMulExpr(const SCEVMulExpr *Expr) {
// TODO: Impl
return Bottom;
}

MinMaxType SCEVMinMaxCalculator::visitAddRecExpr(const SCEVAddRecExpr *Expr) {
assert(Expr->isAffine() && "Expected affine AddRecExpr");
const SCEV *Start = Expr->getStart();
const SCEV *Step = Expr->getStepRecurrence(*SE);

const SCEV *BTC = SE->getBackedgeTakenCount(Expr->getLoop());
if (!BTC || !SE->isLoopInvariant(BTC, OutermostLoop))
return Bottom;

auto [StartMin, StartMax] = visit(Start);
if (!StartMin || !StartMax)
return Bottom;
assert(SE->isLoopInvariant(Step, OutermostLoop) &&
"Expected step to be loop invariant");

const SCEVAddRecExpr *MinAddRec = dyn_cast<SCEVAddRecExpr>(SE->getAddRecExpr(
StartMin, Step, Expr->getLoop(), Expr->getNoWrapFlags()));
const SCEVAddRecExpr *MaxAddRec = dyn_cast<SCEVAddRecExpr>(SE->getAddRecExpr(
StartMax, Step, Expr->getLoop(), Expr->getNoWrapFlags()));

const SCEV *MinLast = MinAddRec->evaluateAtIteration(BTC, *SE);
const SCEV *MaxLast = MaxAddRec->evaluateAtIteration(BTC, *SE);

// If the step value is positive, the AddRec is monotonically increasing,
if (SE->isKnownPositive(Step))
return MinMaxType(StartMin, MaxLast);

// If the step value is negative, the AddRec is monotonically decreasing,
if (SE->isKnownNegative(Step))
return MinMaxType(MinLast, StartMax);

const SCEV *Min = SE->getSMinExpr(StartMin, MinLast);
const SCEV *Max = SE->getSMaxExpr(StartMax, MaxLast);
return MinMaxType(Min, Max);
}

MinMaxType
SCEVMinMaxCalculator::visitSignExtendExpr(const SCEVSignExtendExpr *Expr) {
auto [Min, Max] = visit(Expr->getOperand());
if (!Min || !Max)
return Bottom;
return MinMaxType(SE->getSignExtendExpr(Min, Expr->getType()),
SE->getSignExtendExpr(Max, Expr->getType()));
}

/// Check if we can delinearize the subscripts. If the SCEVs representing the
/// source and destination array references are recurrences on a nested loop,
/// this function flattens the nested recurrences into separate recurrences
Expand Down Expand Up @@ -3500,19 +3816,44 @@ bool DependenceInfo::tryDelinearizeParametricSize(
// to the dependency checks.
if (!DisableDelinearizationChecks)
for (size_t I = 1; I < Size; ++I) {
if (!isKnownNonNegative(SrcSubscripts[I], SrcPtr))
const Loop *OutermostLoop =
LI->getLoopFor(Src->getParent())->getOutermostLoop();

MonotonicityType SrcMonotonicity =
SCEVSignedMonotonicityChecker(SE, OutermostLoop, SrcPtr)
.visit(SrcSubscripts[I]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment. Why evaluate only in the scope of Outermost loop? Shouldnt this be in context of current loop?

if (SrcMonotonicity == MonotonicityType::MaySignedWrap)
return false;

if (!isKnownLessThan(SrcSubscripts[I], Sizes[I - 1]))
MonotonicityType DstMonotonicity =
SCEVSignedMonotonicityChecker(SE, OutermostLoop, DstPtr)
.visit(DstSubscripts[I]);
if (DstMonotonicity == MonotonicityType::MaySignedWrap)
return false;

if (!isKnownNonNegative(DstSubscripts[I], DstPtr))
auto [SrcMin, SrcMax] =
SCEVMinMaxCalculator(SE, OutermostLoop).visit(SrcSubscripts[I]);
if (!SrcMin || !SrcMax)
return false;
if (!SE->isKnownPositive(SrcMin) ||
!SE->isKnownPredicate(CmpInst::ICMP_SLT, SrcMax, Sizes[I - 1]))
return false;

if (!isKnownLessThan(DstSubscripts[I], Sizes[I - 1]))
auto [DstMin, DstMax] =
SCEVMinMaxCalculator(SE, OutermostLoop).visit(DstSubscripts[I]);
if (!DstMin || !DstMax)
return false;
if (!SE->isKnownPositive(DstMin) ||
!SE->isKnownPredicate(CmpInst::ICMP_SLT, DstMax, Sizes[I - 1]))
return false;
}

// TODO: Maybe we must check the the address calculation against delinearized
// result is safe. That is, the following calculation doesn't wrap, where Sub
// is either SrcSubscripts or DstSubscripts and Sz is Sizes:
//
// Sub[0] + Sub[1]*Sz[0] + ... + Sub[N-1]*Sz[N-2]*Sz[N-3]*...*Sz[0]

return true;
}

Expand Down
Loading