[all-commits] [llvm/llvm-project] 5b3501: [ScalarEvolution] Fix overflow in computeBECount.

Eli Friedman via All-commits all-commits at lists.llvm.org
Thu Jul 8 10:11:03 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5b350183cdabd83573bc760ddf513f3e1d991bcb
      https://github.com/llvm/llvm-project/commit/5b350183cdabd83573bc760ddf513f3e1d991bcb
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2021-07-08 (Thu, 08 Jul 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/ScalarEvolution.h
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/test/Analysis/ScalarEvolution/2008-11-18-Stride1.ll
    M llvm/test/Analysis/ScalarEvolution/2008-11-18-Stride2.ll
    M llvm/test/Analysis/ScalarEvolution/trip-count-unknown-stride.ll

  Log Message:
  -----------
  [ScalarEvolution] Fix overflow in computeBECount.

There are two issues with the current implementation of computeBECount:

1. It doesn't account for the possibility that adding "Stride - 1" to
Delta might overflow. For almost all loops, it doesn't, but it's not
actually proven anywhere.
2. It doesn't account for the possibility that Stride is zero. If Delta
is zero, the backedge is never taken; the value of Stride isn't
relevant. To handle this, we have to make sure that the expression
returned by computeBECount evaluates to zero.

To deal with this, add two new checks:

1. Use a variety of tricks to try to prove that the addition doesn't
overflow.  If the proof is impossible, use an alternate sequence which
never overflows.
2. Use umax(Stride, 1) to handle the possibility that Stride is zero.

Differential Revision: https://reviews.llvm.org/D105216




More information about the All-commits mailing list