search for: indvarsimplify

...while: void f (unsigned short *x, int *l) { int i; for (i = 0; i < *l; i++) if (x[i]) x[i]++; } isn't. This makes a big difference on z, which has a native decrement-and- branch instruction. The problem seems to be that the strength-reduction pass relies on IndVarSimplify to convert loop exit conditions into a canonical != form: // Equality (== and !=) ICmps are special. We can rewrite (i == N) as // (N - i == 0), and this allows (N - i) to be the expression that we work // with rather than just N or i, so we can consider the register // requirement...

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i...

...{ > int i; > for (i = 0; i < *l; i++) > if (x[i]) > x[i]++; > } > > isn't. This makes a big difference on z, which has a native decrement-and- > branch instruction. > > The problem seems to be that the strength-reduction pass relies on > IndVarSimplify to convert loop exit conditions into a canonical != form: > > // Equality (== and !=) ICmps are special. We can rewrite (i == N) as > // (N - i == 0), and this allows (N - i) to be the expression that we work > // with rather than just N or i, so we can consider the register &...

On May 6, 2010, at 6:32 PM, ether zhhb wrote: > As the comment said: > /// The IndVarSimplify pass transforms loops to have a form that > this > /// function easily understands. > > you could try -indvars. After adding -indvars to the opt command, getTripCount still returns null. I suppose it's possible, depending on the scheduling of the pass manager, that indvars...

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 for sev...

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 sev...

On Fri, Sep 11, 2015 at 10:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Also, if these redundant expressions involve induction variables, then that's something that the IndVarSimplify is already supposed to do, and if it is missing cases, then we should improve that pass (and, thus, folding what you've done into IndVarSimplify might be the right way to go). Hal, thanks for the info. Turns out IndVarSimplify intentionally creates redundant calculation of loop exit values!...

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 c...

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for...

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 for sev...

Hi, I am investigating a difference in code generation between release and assert builds of llvm. The culprit is IndVarSimplify that comes up with different behavior on the same input: in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition' After digging around, it seems that following change is the culprit: ----- Author: Philip Reames <listmail at philipreames.com> 2019-08-01...

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &...

...s this some known issue ? I could not find a bug report matching this. -- Arnaud de Grandmaison -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Sunday, March 13, 2011 11:08 PM To: Arnaud Allard de Grandmaison Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] IndVarSimplify too aggressive ? 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...

...TP.NE.AND P0, PT, R0, RZ, PT; /*00a0*/ IADD R2.CC, R2, 0x4; /*00a8*/ IADD.X R3, R3, RZ; /*00b0*/ @P0 BRA `(.L_1); I hope the issue is clear up to this point. So what's a good solution to fix this issue? I am thinking of having IndVarSimplify consult TargetTransformInfo about the cost of integer arithmetics of different types. If operations on wider integer types are more expensive, IndVarSimplify should disable the widening. Another thing I am concerned about: are there other optimizations that make similar assumptions about integer w...

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::IVUsers::AddUsersIfInteresting(class llvm::Instruction *)" (?AddUsersIfInteresting at IVUsers@llvm@@QAE_NPAVInstruction at 2@@Z) referenced in function "public: virtual bool __thiscall `anonymous namespac...

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, which supports natively all types, but it is a real one for sev...

Hi, For me, getTripCount always returns null, even for trivial loops such as: void simple(int j) { for (int i = 0; i < 10; i++) { j++; } } Looking through the mailing list archive, it appears that getTripCount requires certain optimization passes to run first, but it's not clear which ones. There doesn't seem to be any documentation on this. Does anybody

...that getTripCount > requires certain optimization passes to run first, but it's not clear > which ones. There doesn't seem to be any documentation on this. Does > anybody know exactly which passes must run in order for getTripCount > to work? > As the comment said: /// The IndVarSimplify pass transforms loops to have a form that this /// function easily understands. you could try -indvars. > > Thanks, > > Trevor > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >...

​Hi, Would you be able to kindly check and assist with the IndVarSimplify / SCEV problem I got in the latest LLVM, please? Sometimes IndVarSimplify may not eliminate narrow IV's when there actually exists such a possibility. This may affect other LLVM passes and result in inefficient code. The reproducing test 'indvar_test.cpp' is attached. The problem is w...

...oth SCEV canonicalization and default canonicalization will slightly increase the compile-time overhead (at most 30% extra compile-time). They also lead to some execution-time regressions and improvements. The only difference between SCEV canonicalization and default canonicalization is the "IndVarSimplify" pass as shown in the code RegisterPasses.cpp:212: if (!SCEVCodegen) PM.add(polly::createIndVarSimplifyPass()); However, I find it is interesting to look into the comparison between SCEV canonicalization and default canonicalization (http://188.40.87.11:8000/db_default/v4/nts/32?...