similar to: [LLVMdev] No getSmallConstantTripCount function in current LLVM version

In my pass, I add LoopInfo as a required pass. Then I'd like to print the constant loop trip count of each loop if it has one. However, every time I call loop-> getSmallConstantTripCount(), it returns 0, even for a very simple loop: for(i=0; i<3; ++i) {;} What's the possible cause of this problem? regards, Bo -------------- next part -------------- An HTML attachment was

Hi, I am trying to use the DependenceAnalysis pass to get the Distance vector for the innermost loop. I am in LLVM learing process. I have used the following code inside my original code to get the distance vector. It is not giving any syntax error but it is has some logical but and giving segmentation fault. void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll();

Hello, I'm finding problems with BackEdgeTaken count calculation in even simple fortran loops with gfortran-4.6 + DragonEgg 3.0. Even for simple double loops like this one: program test2 integer i,j,k dimension k(100,100) do j=1,100 do i=1,100 k(i,j) = i enddo enddo write(*,*) k(1,30) end make the ScalarEvolution

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

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

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

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

Hi, I have problems to estimate the loop exit count of a simple loop with the ScalarEvolution class. simple loop: ...... int a = 0; for(int i; i < 10; ++i){ a = a + 1; }; ...... For the loop analyzation I use the ScalarEvolution class with the following initialization: ...... void analysis(Function* func) DominatorTree DT = DominatorTree(); DT.recalculate(*func);

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

Hi, My pass heavily relies on llvm::Loop's getSmallConstantTripCount method. However, I found that it doesn't work for some simple cases. In the following example, I can get the constant trip count of the outermost loop if statement "a[l] = a[l] + 1" is there. After commenting out this line, the returned constant trip count for that loop is 0. In my pass, I traverse the nested

Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may be ...) , this one should be ok (and passess all the ScalarEvolution tests in LLVM): diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp index daf7742..b10fab2 100644 --- a/lib/Analysis/ScalarEvolution.cpp +++ b/lib/Analysis/ScalarEvolution.cpp @@ -4293,9 +4293,15 @@

Your patch should include a testcase, see test/Analysis/ScalarEvolution for examples. "BranchInst* " should be "BranchInst *". You should have spaces after the // in your comments. One of the comment lines isn't indented properly. Nick On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote: > Attached > > 2012/2/8 Marcello Maggioni

Hi Taemin, On 03/07/2012 01:53, Taemin Kim wrote: > I found out that Loop::getTripCount method is obsolete in LLVM 3.1 > Is there an alternative? I use getSmallConstantTripCount() to get loop trip counts using the ScalarEvolution analysis pass. See include/llvm/Analysis/ScalarEvolution.h for a detailed explanation. Ivan > > > _______________________________________________

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,

On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote: > Well, it wasn't intended as a "real" patch to be included , but more > as a "proof of concept" for a solution. Do you think it is a valid > solution and I'm correct in my assumption? If so then I'll clean up > the patch and attach a testcase for inclusion. > I'm

This is instead a very simple (handmade) test case that triggers the problem (attached) Also a more conforming patch has been attached 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is the .ll for that graph (attached). I think I understand what > you are saying. > This particular testcase returns CNC not because the exit block > doesn't have a unique predecessor,

FInally I had the time to complete everything up. Now I included the test case in the patch and the testcase runs with the LLVM tests system. 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is instead a very simple (handmade) test case that triggers the > problem (attached) > Also a more conforming patch has been attached > > 2012/2/9 Marcello Maggioni <hayarms

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

Hi Sriram, Thanks for performing this analysis. The problem here, both for memcpy and the vectorizer, is that we can’t predict the size of “n”, even though the only use of ’n’ is for the loop bound for the alloca [4 x [8 x i32]]. If you change the unroll condition to TC >= 0 then you will disable loop unrolling for all loops because getSmallConstantTripCount returns an unsigned number. You

Hi Nadav, Thanks for the response. I forgot to mention that there is an upper limit of 16 for the Trip Count check, TinyTripCountVectorThreshold = 16; if (TC > 0u && TC < TinyTripCountVectorThreshold). So right now, any loop with Trip Count as 0, or with value >=16, LV with unroll. With the change to the lower bound, it will also include the loop with 0 trip count. SCEV returns 0