[PATCH] D65276: [SCEV] Disable canonical expansion for nested recurrences.
Artur Pilipenko via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 1 16:00:28 PDT 2019
apilipenko added a comment.
The original patch introduces a function `minIterationWidthForEvaluateAtIteration`. This way it exposes the limitation of evaluateAtIteration through the API and makes it possible for the user to choose the proper It width (e.g. like I did in the first revision https://reviews.llvm.org/D62563?vs=on&id=201795). What was the reason to remove it?
================
Comment at: include/llvm/Analysis/ScalarEvolutionExpressions.h:347-349
+ /// Note that SCEVCouldNotCompute is returned if evaluation attempt failed.
+ /// For example, if precision of \p It is less than required to perform an
+ /// evaluation instance of SCEVCouldNotCompute is returned.
----------------
Because you removed `minIterationWidthForEvaluateAtIteration` from the API, now the description on `evaluateAtIteration` is very vague. I'd prefer to specify this limitation more specifically.
================
Comment at: lib/Analysis/ScalarEvolution.cpp:1208-1212
+ // Zero extension indicates insufficient precision of incoming "It".
+ // In this case result of calculations may be incorrect. Go ahead and return
+ // SCEVCouldNotCompute.
+ if (isa<SCEVZeroExtendExpr>(Dividend))
+ return SE.getCouldNotCompute();
----------------
Any reason to express this check in this way and not as a comparison of CalculationBits with It bitwidth?
================
Comment at: lib/Analysis/ScalarEvolution.cpp:11670
case scCouldNotCompute:
- llvm_unreachable("Attempt to use a SCEVCouldNotCompute object!");
+ return LoopVariant;
}
----------------
I don't think that it makes much sense to ask loop disposition of scCouldNotCompute. I think the caller of this API should handle scCouldNotCompute case instead.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65276/new/
https://reviews.llvm.org/D65276
More information about the llvm-commits
mailing list