search for: simplifyicmpoperand

...can do the simplification. Depending on what you want to do, you may want to either do not extend src and dst to 64 bits or add a NSW flag to the computations. That will hopefully make SCEV push the sext outside and then perform the simplification. You can also take a look at ScalarEvolution::SimplifyICmpOperands(). Nuno -----Original Message----- From: Preston Briggs Sent: Saturday, June 16, 2012 3:52 AM To: LLVM Developers Mailing List Subject: [LLVMdev] SCEV not simplifying I have a pair of SCEVs that appear different to me. However, when I compute the difference, it's not known to be non-zero....

...r have a look at the code that computing the back-edge taken count, i found that ScalarEvolution could only compute back-edge taken count if the exit condition is ICMP_NE/ICMP_EQ/ICMP_SLT/ICMP_SGT/ICMP_ULT/ICMP_UGT (ignoring "ComputeBackedgeTakenCountExhaustively"), and the function "SimplifyICmpOperands" will try to convert other conditions to the conditions listed above, by doing something like "i <= n" to "i < n+1", but it refuse to do that unless it could prove "n + 1" will not cause a overflow. So, could us just set "n + 1" to the Exact fiel...

I have a pair of SCEVs that appear different to me. However, when I compute the difference, it's not known to be non-zero. src = (sext i32 %n to i64) dst = (sext i32 (1 + %n) to i64) delta = ((sext i32 %n to i64) + (-1 * (sext i32 (1 + %n) to i64))) Is this behavior expected? If I repeat the experiment with 64-bit ints (or unsigned), things work out like I expect. 32-bit

...    a[j] = a[j+1] + 2;   } } The only difference between the two loops is the loop exit condition, both semantically same. Scalar Evolution is unable to determine the exit value of the second loop, leading to the vectorizer failing to vectorize. It seemed to me that this is due to ScalarEvolution::SimplifyICmpOperands failing to canonicalize the corresponding ICMP_ULE instruction. Thanks, - Vaivaswatha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150422/41a73399/attachment.html>

...that adds the missing logic. > > Off the top of my head, the attached is missing a check for whether > the increment is nsw, and the upper bound computation is wrong. No doubt, it was just a test if this would work at all. Looking deeper into SCEV, this should really be canonicalized in SimplifyICmpOperands. Currently it checks whether the value cannot possibly be the maximum or minimum signed value and only does the transform if that's the case. I wonder if that condition could be weakened a bit. - Ben

On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 27.02.2012, at 17:13, Николай Лихогруд wrote: > >> Dear LLVM, >> >>     Consider two loops with one interation - >>     First with constant lower bound, second with usual non-constant lower bound: >> >>     int main(int argc, char ** argv) >>     {

...r have a look at the code that computing the back-edge taken count, i found that ScalarEvolution could only compute back-edge taken count if the exit condition is ICMP_NE/ICMP_EQ/ICMP_SLT/ICMP_SGT/ICMP_ULT/ICMP_UGT (ignoring "ComputeBackedgeTakenCountExhaustively"), and the function "SimplifyICmpOperands" will try to convert other conditions to the conditions listed above, by doing something like "i <= n" to "i < n+1", but it refuse to do that unless it could prove "n + 1" will not cause a overflow. > > So, could us just set "n + 1" to the...