[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