similar to: [LLVMdev] Loop Dependence Analysis(getDistance())

Hello everyone, I intend to build a pass to profile some benchmarks for loop carried dependencies. At first I tried looking at LoopDependenceAnalysis.{h,cpp} but the files were removed for some reason. So I continued with the DependenceAnalysis pass. But the flow, anti dependence, etc methods are only reporting sequential and not loop carried dependencies. Does LLVM support loop carried

Hi, The DependenceAnalysis pass will find loop-carried dependences. However, it is a conservative analysis and will sometimes suggest there may be more dependences than actually exist. In your example, I expect the analysis is confused for some reason and is returning the default confused response. You could test it using the isConfused() method. Note that the DVEntry::ALL direction is always

Dear LLVM community, LLVM IR has a concept of 'LoopID' [1] which is a misnomer: (a) LoopIDs are not unique: Any pass that duplicates IR will do it including its metadata (e.g. LoopVersioning) such that thereafter multiple loops are linked with the same LoopID. There is even a test case (Transforms/LoopUnroll/unroll-pragmas-disabled.ll) for multiple loops with the same LoopID. (b)

Hi Arnaldo, On 05/11/12 10:02, Arnaldo wrote: > Hi Duncan, thanks for the quick answer. > > Yes I'm sure the runOnModule is being called, and when I dump the functions > before exiting the method I can see the AlwaysInline attribute. > > I'll check InlineAlways.cpp and will reimplement as last resource but I still > wonder why this is not working. if you want more

Hi Duncan, thanks for the quick answer. Yes I'm sure the runOnModule is being called, and when I dump the functions before exiting the method I can see the AlwaysInline attribute. I'll check InlineAlways.cpp and will reimplement as last resource but I still wonder why this is not working. On Mon, Nov 5, 2012 at 5:03 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arnaldo,

Hi, I am trying to use GDB for debugging my llvm pass. I am following the documentation http://llvm.org/docs/WritingAnLLVMPass.html. When i am doing this the following error and warning messages I am getting. I tried to remove the warning by apt-get install libc6-dbg:i386 command for updating the libc6 but still getting the same. Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+:

On 02/17/2013 11:15 PM, Hal Finkel wrote: > If the unroller somehow differentiates the metadata coming from different > loop iterations, then BBVectorize can use this information as well. Even > better, we could make BasicAA understand that appropriately marked loads > and stores from different iterations don't alias. Then the AA-based > dependency breaker in the scheduler could

I noticed that LoopVectorizeHints::setAlreadyVectorized never deletes old "llvm.loop...." metadata. It just appends more, possibly contradicting the old metadata. E.g., after vectorization, a loop previously marked with llvm.loop.vectorize.width ends up with *two* such annotations, like this: br i1 %exitcond.1, label %for.end.loopexit.unr-lcssa, label %for.body, !llvm.loop !8

Below is a stripped down version of the pass. The compile line is: clang -O0 -S -emit-llvm -o test.S test.c && opt -S -mem2reg -load <path to extract lib> -extract < test.S > test_opt.S #include "llvm/Analysis/DependenceAnalysis.h" #include "llvm/Analysis/LoopInfo.h" #include "llvm/Analysis/LoopPass.h" #include

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

Hi, I have a doubt regarding *getAnalysisUsage.* My assumption is that, as analysis passes will not change the IR, all the passes required by an analysis pass should be preserved. Say, I have an analysis pass which requires another analysis pass called *SomeAnalysis* and I have not added *AU.addPreserved<SomeAnalysis>() *to my pass. Would the pass manager still considers the *SomeAnlaysis

Hi, I'm having problems with the LoopIdiomRegognizer crashing on me with An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:695! If I remove AU.addPreserved<LoopInfoWrapperPass>(); or AU.addPreserved<AAResultsWrapperPass>(); everything goes well. The C-code triggering this is void foo(int a[10][10]) { int i, j,

Hi, I'm writing a function pass which is dynamically loaded by opt and I need some analysis and passes to be run before my pass: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addPreservedID(LoopSimplifyID);

---------- Forwarded message ---------- From: Qingan Li <ww345ww at gmail.com> Date: 2011/5/30 Subject: To: llvmdev at cs.uiuc.edu Hi, I wrote an analysis pass, myPass, inherited from both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>();

Here's an attempt to nail down the annotation semantics with support for respecting forward lexical dependences. Each load, store, call, or invoke instruction can be labeled with !llvm.mem.vector_loop_access, which has two operands: * The first operand is an integer denoting lexical position. The positions need not be consecutive, and may contain duplicates. * The second operand is the

Hello, I am trying to add some thing into LLVM, while I encountered some problems. So my situation is that I have some information W, some transform passes may change it, after these passes, I need the new W. What I did is to create an analysis pass similar to scalar-evolution or loopinfo, I can get the information by using getAnalysis<W>(); and preserve this information W by using

Hi again, I come back to this issue with an example. It's a pass which does nothing but throw the 'Unable to schedule' error. namespace { struct MyPass : public FunctionPass { static char ID; // Pass identification, replacement for typeid MyPass() : FunctionPass(ID) { initializeMyPassPass(*PassRegistry::getPassRegistry()); } virtual void

"Daniel Stewart" <stewartd at codeaurora.org> writes: > I'm no expert on the PassManager, but I happen to be going through it > fairly carefully right now. You didn't state which passes were Module > Passes and which were Function Passes (or other types). Sorry, I did mean to include that. They are all FunctionPasses. > One thing I have noticed is that

Hi, I'm fighting with this quite some time now: Is there a way to mark an Analysis (in my case ProfileInfo) as perserved by _all_ passes? I have tried to add ProfileInfo directly in Pass.h:getAnalysisUsage() but that produces nasty circular library dependecies. I also tried to simply store a pointer to the ProfileInfo in Module but then the PassManager gets confused resulting in double