similar to: [LLVMdev] Dependence Analysis

On Mon, 18 Jul 2005, Naftali Schwartz wrote: > Hi, everyone. I've been examining llvm for a while and been duly impressed. > I'd like to contribute in the area of dependence analysis, and a good place > to start seems to be in the transformation of pointers to explicit array > accesses. Is anyone else working on this? If not, does this seem a > plausible place to

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. You can check out

On Thu, 21 Jul 2005, Naftali Schwartz wrote: >> If you're interested in dependence analysis, the next important step is > to >> start analyzing distance and direction vectors. > > Well, specifically, I was thinking of a mechanism to turn this: The indvars pass is *intentionally* restricted to only promoting affine expressions to array subscripts, not arbitrary

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. Well, specifically, I was thinking of a

Hi, Is it possible to generate a data dependence graph of llvm assembly file? How can I get the data flow information in X.ll file? Also, in .ll file I see everyline ends with something like this: <type> [#uses=3] What is the significance of this and is it used anyway by the compiler for data dependence analysis. I would be grateful for any help. Regards, Manvi

On Fri, 17 Jun 2005, Manvi Agarwal wrote: > Hi Chris, Hi. FYI, it's usually better to email the llvmdev list with generic llvm questions. > Is it possible to get control flow graph of the application with the llvm > infrastructure in terms of basic blocks? Yes, given a BasicBlock*, you can iterate over the pred/succ blocks in the CFG like this: #include

OK, thanks Chris, I've found that running opt -loopsimplify -instcombine -indvars -stats gives me the setup I need for this transformation, and a small patch makes it happen in the simple case we discussed. However, I'm having some trouble when things get a bit more complicated with 3 nesting levels: int A[3000000], B[20000], C[100], Z; int main() { int i, j, k, *a, *b,

Hi! I can't build LLVM using GCC 4.1 (GCC CVS mainline) after http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050328/025003.html Build terminated with error: /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/SparcV9/ModuloScheduling/DependenceAnalyzer.cpp:25: error: explicit qualification in declaration of `llvm::FunctionPass* llvm::createDependenceAnalyzer()' at line:

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++ ) for ( b = &B[0], j = 0; j != 100; j++

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 ( a =

But it's completely empty, no? const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, std::vector<Value*> &Indices, const TargetData &TD, BasicBlock::iterator *BI) { return 0; } in lib/Transforms/TransformInternals.cpp, how can this be? Naftali On Tue,

I'm sorry, it had seemed to me that the documented functionality: // ConvertibleToGEP - This function returns true if the specified value V is // a valid index into a pointer of type Ty. If it is valid, Idx is filled in // with the values that would be appropriate to make this a getelementptr // instruction. The type returned is the root type that the GEP would point to would be quite

Well, I guess I was hoping soemthing like this would help in the pointer-to-array transformation for the following code: > > int A[100], B[100], C[100], X, Y, Z; > > > > int *p_a = &A[0]; > > int *p_b = &B[0]; > > int *p_c = &C[0]; > > > > int i, j, k, f; > > for ( k = 0; k < Z; k++ ) > >

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > But it's completely empty, no? > > const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, > std::vector<Value*> &Indices, > const TargetData &TD, > BasicBlock::iterator *BI) { > return 0; > }

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > I'm sorry, it had seemed to me that the documented functionality: > > // ConvertibleToGEP - This function returns true if the specified value V is > // a valid index into a pointer of type Ty. If it is valid, Idx is filled in > // with the values that would be appropriate to make this a getelementptr > // instruction. The type

It seems like general dependence analysis in LLVM should require that this function be, well, functional. Is it simply a placeholder waiting for someone to come and fill in the details? It also appears that some other things besides dependence analysis depend on it as well...anyone working on this? Naftali

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > It seems like general dependence analysis in LLVM should require that this > function be, well, functional. Is it simply a placeholder waiting for > someone to come and fill in the details? It also appears that some other > things besides dependence analysis depend on it as well...anyone working on > this? I don't understand

I am not sure if my problem is similar to: http://lists.cs.uiuc.edu/pipermail/llvmdev/2003-December/000715.html It seems that the constructor of the static global pass object isn't called: lib/CodeGen/DependenceAnalyzer.cpp: static RegisterAnalysis<DependenceAnalyzer> X("depana", "Dependence Analysis"); I traced into struct RegisterAnalysis ctor, but my pass

On Wed, Sep 19, 2018 at 4:58 AM Venkataramanan Kumar < venkataramanan.kumar.llvm at gmail.com> wrote: > Hi, > > I tired to see when this behavior changed in LLVM. > It seems to start from. > --snip-- > commit 95e5d37d5868ebde2302bc302c1e0af407c5646d > Author: Sebastian Pop <sebpop at gmail.com> > Date: Tue Mar 6 21:55:59 2018 +0000 > > DA: remove

Hi, I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures. Would someone be willing to take a look at the failures and figure out why we're getting worse output once this patch is applied? If I had to hazard a guess, I'd say that indvars is probably emitting code