similar to: IndVarSimplify: getBackedgeTakenCount and Release vs Assert

This might be hard cases making bad law, but the loop: void f (unsigned short *x, int *l) { int c = *l; int i; for (i = 0; i < c; i++) if (x[i]) x[i]++; } is converted to decrement-and-branch form by LoopStrengthReduce while: void f (unsigned short *x, int *l) { int i; for (i = 0; i < *l; i++) if (x[i]) x[i]++; } isn't.

Hi Sanjoy, Thanks for investigating the issue! I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which can lead to inconsistencies. These inconsistencies require significant developer time to analyze and fix

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

Thanks Eli, After digging thru mail archives & bugzilla, it seems fixing properly this issue would require a major change in the selectionDAG code --- to have it operate on a per function basis instead of per basic-block. This however, does not seem to be the only issue. The following C code does not produce an efficicient assembly sequence either. extern void f(unsigned long long v); void

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target

2011/11/21 Tobias Grosser <tobias at grosser.es>: > On 11/20/2011 04:36 PM, Marcello Maggioni wrote: >> >> Sorry for the noobish question, but what kind of subscripts generate a >> SCEVCouldNotCompute  from the SCEV engine? >> I tried for a while but I wasn't able to trigger that > > Hi Marcello, > > the SCEV returns SCEVCouldNotCompute in case it

On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > Dear guys, > > I am having problems to obtain good information from the LoopInfo. > I am always getting a trip count of 0, even though I am clearly passing > a loop with a constant bound. I am using this pass below: Hi, I would propose to first check if the trip count is calculated correctly. I would do this with opt

On Thu, Aug 12, 2010 at 5:22 PM, Tobias Grosser <grosser at fim.uni-passau.de>wrote: > On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > >> Dear guys, >> >> I am having problems to obtain good information from the LoopInfo. >> I am always getting a trip count of 0, even though I am clearly passing >> a loop with a constant bound. I am using

Hi, Is it valid to query ScalarEvolution::getSCEVAtScope with a Value which is an Instruction inside the provided Loop? If so, I believe there is a bug in computeSCEVAtScope. Specifically: 04716     // If the scope is outside the addrec's loop, evaluate it by using the 04717     // loop exit value of the addrec. 04718     if (!AddRec->getLoop()->contains(L)) { 04719       // To

Nevermind. I misread the documentation. On Sat, Apr 30, 2011 at 8:12 PM, Thomas Jablin <tjablin at gmail.com> wrote: > Hi, > > Is it valid to query ScalarEvolution::getSCEVAtScope with a Value > which is an Instruction inside the provided Loop? If so, I believe > there is a bug in computeSCEVAtScope. Specifically: > > 04716     // If the scope is outside the

Hi, I am trying to do loop unrolling with loops that don't have constant loop counter. It is highly appreciated if anyone can help me on this. What I want to do is to turn loop (n) { <loop body> } into loop (n/4) { <loop body> <loop body> <loop body> <loop body> } loop (n%4) { <loop

On 11/20/2011 04:36 PM, Marcello Maggioni wrote: > Sorry for the noobish question, but what kind of subscripts generate a > SCEVCouldNotCompute from the SCEV engine? > I tried for a while but I wasn't able to trigger that Hi Marcello, the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression or if the analysis would be to complicated. I am currently not sure if

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a

On 11/21/2011 12:44 PM, Marcello Maggioni wrote: > 2011/11/21 Tobias Grosser<tobias at grosser.es>: >> On 11/20/2011 04:36 PM, Marcello Maggioni wrote: >>> >>> Sorry for the noobish question, but what kind of subscripts generate a >>> SCEVCouldNotCompute from the SCEV engine? >>> I tried for a while but I wasn't able to trigger that >>

hi all, i am have a project need to compute the back-edge taken count of a loop, and the "getBackedgeTakenCount" function of ScalarEvolution could do this for me. but later i found that ScalarEvolution could not compute loops with test expression containing a "=", such as: void scop_func(long A[], long n) { long i; for (i = 1; i<= n; i++) A[i] = 1; } after have

Hi, Scalar evolution seems to be wrapping around the trip count in the following loop. void add (int *restrict a, int *restrict b, int *restrict c) { char i; for (i = 0; i < 255; i++) a[i] = b[i] + c[i]; } When I run scalar evolution on the bit code, I get a backedge-taken count which is obviously wrong. $> cat loop.ll ; Function Attrs: nounwind define void @add(i32* noalias