[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