[PATCH] D70623: [SCEV] Compute trip counts w/frozen conditions
Juneyoung Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Nov 23 08:59:44 PST 2019
aqjune added a comment.
Hi,
Currently `ScalarEvolution::getBackedgeTakenCount()` is commented as follows, which is not clear about the case when instruction returning nondeterministic value is involved (such as freeze).
/// If the specified loop has a predictable backedge-taken count, return it,
/// otherwise return a SCEVCouldNotCompute object. The backedge-taken count is
/// the number of times the loop header will be branched to from within the
/// loop, assuming there are no abnormal exists like exception throws. This is
/// one less than the trip count of the loop, since it doesn't count the first
/// iteration, when the header is branched to from outside the loop.
///
/// Note that it is not valid to call this method on a loop without a
/// loop-invariant backedge-taken count (see
/// hasLoopInvariantBackedgeTakenCount).
Updating its definition as follows helps the tests frozen_condition, frozen_iv, frozen_inc to have `%n` backedge-count.
We can simulate a case where the number of loop iteration is `%n` by properly choosing the freezed values at different iterations.
/// loop, assuming there are no abnormal exists like exception throws.
+ /// If there are more than one possible backedge-taken counts because its branch
+ /// condition is evaluated from nondeterministic operations like freeze,
+ /// any of possible backedge-taken counts is valid. This assumes that variables
+ /// defined outside the loop are fixed.
In case of the frozen_limit example, the number of iterations is fixed to `%freeze` (`%freeze` is defined outside the loop), so it cannot be `%n`. I think the current CHECK is okay.
This update will support sustaining SCEV's analysis after insertion of freezes, but not very sure whether it is correct.
A possible problematic case is creating a code snippet and inserting it into a loop, based on SCEV's analysis result. Loop unrolling might be the case if it adds increment of the induction variable, because it wouldn't create freezed increment right now.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70623/new/
https://reviews.llvm.org/D70623
More information about the llvm-commits
mailing list