similar to: ScalarEvolution in a ModulePass

I'm seeing some very unexpected behavior in a ModulePass I've created. To support both the legacy and new pass managers, I've abstracted away the code to get the passes it depends on: bool MyPass::runOnModule(Module &M) override { auto DominatorGetter = [this] (Function &F) -> DominatorTree & { return

I have modified the code as follows; now i am using both scopdetection and scopinformation before dependency check but i think link is missing... virtual bool runOnFunction(Function &F) { std::unique_ptr<ScopInfo> Result; std::unique_ptr<ScopDetection> Result2; //polly::ScopDetection pl; auto &LI = getAnalysis<LoopInfoWrapperPass>().getLoopInfo(); auto

Dear all, Hi! I encounter an interesting assertion failure when implementing my Pass, which is defined with the member functions shown below: ======================My Pass====================================== bool MYPass::runOnModule(Module &M) { for (auto &F : M) { SE = &getAnalysis<ScalarEvolutionWrapperPass>(F).getSE(); ......

HI Hameeza, what do mean by link is still missing? Currently it is not possible to use polyhedral information from within in-tree LLVM passes. This is because Polly is not currently part of the LLVM tree, and is only linked into the tools as an external project. I.e., you can't depend on Polly passes in an in-tree pass. What you can do, though, is use Polly from an out-of-tree context. If

Dear all, I write a new LoopPass which wants to use passes including LoopInfoWrapperPass, ScalarEvolutionWrapperPass and LoopAccessLegacyAnalysis. Therefore, I implement the following code based on LLVM 9.0.0: ===================================================================== bool LoopInformationCollect::runOnLoop(Loop *L, LPPassManager &) { auto &SE =

Hello, I need to analyze dependencies in my llvm ir by using polly. i created a new pass called mypass there i added polly dependency analysis pass but when i execute this pass in gdb i get no data. Why is that so? My code is follows; namespace { struct mypass : public FunctionPass { static char ID; mypass() : FunctionPass(ID) { } virtual bool runOnFunction(Function &F) {

Thank You. Actually i pass polly canonaclize IR to my new created polly pass called "mypass". Mypass should first detect scops then find depedndencies as the mechanism conventional approach. Now i know how to write llvm pass here i am writing pass as loadable module first afterwards i will integrate it with opt in the end. I tried writing following code. Could you please help me on

How do you compile the code? Within the Polly subdirectory using CMake? How do you run your pass. Using "opt -mypass inputfile.ll"? Michael 2018-01-28 9:30 GMT-06:00 hameeza ahmed via llvm-dev <llvm-dev at lists.llvm.org>: > Hello, > > I need to analyze dependencies in my llvm ir by using polly. i created a new > pass called mypass there i added polly dependency

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

Hi all, I am getting the infamous error: Assertion `ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"' but i really don't understand why. I have: voidInstrumentationPass::getAnalysisUsage(llvm::AnalysisUsage&AU) const{     AU.setPreservesAll();     AU.addRequired<DetectKernelsPass>();    

The loop rotation pass does modify the function, which I'm guessing means that a FunctionPassManager can be used to run LoopPasses (this is not obvious to me after looking through the FunctionPassManager code). Unfortunately none of the other passes I'm using (ScalarEvolution, LCSSA, IndVarSimplify, and LoopUnroll) appear to have an effect. I verified that the function can be loop

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

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,

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

Hi, Can someone who's familiar with lld take a look? [2980/3371] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/disassemble.c.o [2981/3371] Building CXX object tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o FAILED: tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o /opt/arm/arm-linux-compiler-20.0_Generic-AArch64_RHEL-7_aarch64-linux/bin/armclang++ -DGTEST_HAS_RTTI=0

Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll

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