search for: howmanylessthans

Hi, I have a question about some code in ScalarEvolution.cpp, in the function HowManyLessThans. Specifically, this function returns CouldNotCompute if the iteration step is greater than one even when the NoWrap flags are set (if the step goes past the limit and wraps). Here's the comment: } else if (isKnownPositive(Step)) { // Test whether a positive iteration can step...

For void test0(unsigned short a, unsigned short * in, unsigned short * out) { for (unsigned short w = 1; w < a - 1; w++) //this will never overflow out[w] = in[w+7] * 2; } I think it will be sufficient to add a couple of new cases to ScalarEvolution::HowManyLessThans -- zext(A) ult zext(B) == A ult B sext(A) slt sext(B) == A slt B Currently it bails out if it sees a non-add recurrence on the LHS of the ult/slt. You could also teach ScalarEvolution::isImpliedCondOperands the following: zext(A) ult zext(B) <=> A ult B sext(A) slt sext(B) <=&g...

...Line 1953, the switch-case computes the trip count due to >> > different Cond code. >> > But in this case, as it exits on true, the slt is converted to sge, >> > not switch-case for this condtion. >> > > Not sure what you mean. The problem is that HowManyLessThans was > refusing to work on a signed less-than or equal to, even in the trivial > case (just because I haven't yet gotten around to working on the complex > case of a non-unit stride). > > Make sense. >> > 3. As the loop count is over 100, the Brute-Force algorithm a...

Hi Pankaj, Chawla, Pankaj via llvm-dev wrote: > It looks like ScalarEvolution bails out of loop backedge computation if > it cannot prove the IV stride as either positive or negative (based on > loop control condition). I think this logic can be refined for signed IVs. > > Consider this simple loop- > > void foo(int *A, int n, int s) { > > int i; > >

On 27.02.2012, at 18:49, Eli Friedman wrote: > 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

Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This

Hi, Seems pass scalar-evolution+indvars fail to get the loop trip count of the following case: int foo(int x, int y, int lam[256], int alp[256]) { int i; int z = y; for (i = 255; i >= 0; i--) { z += x; lam[i] = alp[i]; } return z; } The final optimized ll code is : define i32 @foo(i32 %x, i32 %y, i32* %lam, i32* %alp) nounwind { entry: br label %bb bb:

Hi, It looks like ScalarEvolution bails out of loop backedge computation if it cannot prove the IV stride as either positive or negative (based on loop control condition). I think this logic can be refined for signed IVs. Consider this simple loop- void foo(int *A, int n, int s) { int i; for(i=0; i<n; i += s) { A[i]++; } } The IV of this loop has this SCEV form-

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) >>     {

On Tue, Jan 24, 2017 at 1:20 PM, Sanjay Patel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I started looking at the log files that you attached, and I'm confused. > The code that is supposedly causing the perf regression is created by the > loop vectorizer, right? Except the bad code is not in the "vector.body", so > is there something peculiar about