search for: ep_earlyasposs

Hello all, I've followed the example in https://github.com/CompilerTeaching/SimplePass/blob/master/SimplePass.cc in order to create a custom pass. The pass needs to be added before any transformation, so I used EP_EarlyAsPossible extension point to register it. Furthermore, I need to access to every GlobalVariable in the IR, so my pass has to be a ModulePass, like this: struct MyPass : public ModulePass { static char ID; MyPass(): ModulePass(ID) {} virtual bool runOnModule(Module &M) {...} ......

...all, I was able to create a pass following [1]. Now goal is amend the pass and try to dump the call graph. I think I have properly amended the source extending my pass from CallGraphSCCPass but unfortunately every time I run it, it crashes. I tried with llvm-6 and llvm-7. I notice that if I change EP_EarlyAsPossible to anything else it does not crash but I don't see the expected string printed by the runOnSCC. Could you help me to solve this problem? How should I create the pass? Thanks for your time [1] https://www.cs.cornell.edu/~asampson/blog/llvm.html -------------- next part -------------- An H...

Hi Tobias, I am trying to move Polly later. LLVM provides some predefined ExtensionPointTy: EP_EarlyAsPossible, EP_ModuleOptimizerEarly, EP_LoopOptimizerEnd, EP_ScalarOptimizerLate, ... Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >Instead of removing canonicalization passes, I believe we may want to >move Polly to a la...

On 09/19/2013 04:46 PM, Star Tan wrote: > Hi Tobias, > > > I am trying to move Polly later. > > > LLVM provides some predefined ExtensionPointTy: > EP_EarlyAsPossible, > EP_ModuleOptimizerEarly, > EP_LoopOptimizerEnd, > EP_ScalarOptimizerLate, > ... > > > Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >> Instead of removing canonicalization passes, I beli...

...amp;Builder, llvm::PassManagerBase &PM) { PM.add(llvm::createPromoteMemoryToRegisterPass()); // create my own createHelloPass() method? } static llvm::RegisterStandardPasses PassRegister(llvm::PassManagerBuilder::EP_EarlyAsPossible, registerPollyPasses); I'm not sure how to code a possible createHelloPass, as the constructor for my class takes a argument(ID for ModulePass). Thanks On Tue, Nov 8, 2011 at 4:10 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 11/08/2011 03:20 AM, ret...

...llvm::PassManagerBase&PM) { > PM.add(llvm::createPromoteMemoryToRegisterPass()); > // create my own createHelloPass() method? > } > > static llvm::RegisterStandardPasses > PassRegister(llvm::PassManagerBuilder::EP_EarlyAsPossible, > registerPollyPasses); > > I'm not sure how to code a possible createHelloPass, as the > constructor for my class takes a argument(ID for ModulePass). This is the code interesting to you: 66 void initializePollyPasses(PassRegistry &Registry) { 67...

On 09/17/2013 04:12 AM, Star Tan wrote: > Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity Hi Star Tan, thanks for this very extensive analysis. The results look very interesting. As you found out, just removing some canonicalization passes will reduce compile time, but this reduction may in large part being due to Polly not being able to

> opt -load lib­dum­my­pass.so -dum­my­pass hel­lo.ll Looks like you are loading a shared library different from "LLVMHello.so". did you change the name of the compilation unit from "Hello.cpp" into "dummypass.cpp"? (As asked previously by Andrzej) did you register the dummy pass? > RegisterPass<DummyPass> X("dummypass",

...At 2013-09-19 22:59:25,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/19/2013 04:46 PM, Star Tan wrote: >> Hi Tobias, >> >> >> I am trying to move Polly later. >> >> >> LLVM provides some predefined ExtensionPointTy: >> EP_EarlyAsPossible, >> EP_ModuleOptimizerEarly, >> EP_LoopOptimizerEnd, >> EP_ScalarOptimizerLate, >> ... >> >> >> Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >>> Instead of removing...

...s,At 2013-09-19 22:59:25,"Tobias Grosser" <tobias at grosser.es> wrote:>On 09/19/2013 04:46 PM, Star Tan wrote: >> Hi Tobias, >> >> >> I am trying to move Polly later. >> >> >> LLVM provides some predefined ExtensionPointTy: >>      EP_EarlyAsPossible, >>      EP_ModuleOptimizerEarly, >>      EP_LoopOptimizerEnd, >>      EP_ScalarOptimizerLate, >>      ... >> >> >> Currently Polly uses "EP_EarlyAsPossible" to run as early as possible.  As what you suggested: >>> Instead of removing...

On 11/08/2011 03:20 AM, ret val wrote: > I'm writing a Pass that I would like to remain loadable by opt. The > pass also requires DominatorTree(for PromoteMemToReg). > > Looking for examples the only way I found to require a dependecny is > by doing something like this: > char Hello::ID = 0; > namespace llvm { void

...anagerBase&PM) { >>                PM.add(llvm::createPromoteMemoryToRegisterPass()); >>                // create my own createHelloPass() method? >>         } >> >>         static llvm::RegisterStandardPasses >>         PassRegister(llvm::PassManagerBuilder::EP_EarlyAsPossible, >>                      registerPollyPasses); >> >> I'm not sure how to code a possible createHelloPass, as the >> constructor for my class takes a argument(ID for ModulePass). > > This is the code interesting to you: > > 66 void initializePollyPasses(Pa...

I'm writing a Pass that I would like to remain loadable by opt. The pass also requires DominatorTree(for PromoteMemToReg). Looking for examples the only way I found to require a dependecny is by doing something like this: char Hello::ID = 0; namespace llvm { void initializeHelloPass(llvm::PassRegistry&); } INITIALIZE_PASS_BEGIN(Hello, "hello", "Hello

...lifetime of the caller, we remove dynamic allocation of coroutine state and replace it with an `alloca` on the caller's frame. These optimizations are done by a function pass CoroElide run by the main IPO optimization at EP_ScalarOptimizerLate extension point. CoroEarly Pass: (Function Pass @ EP_EarlyAsPossible) --------------- Pretty boring pass that lowers coroutine intrinsics that are not needed for later coroutine passes. CoroCleanup Pass: (Function Pass @ EP_OptimizerLast) -------------- Another boring pass that lowers all remaining coroutine intrinsics that were not processed by earlier corouti...

Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity I mainly care about the compile-time and execution time impact for the following cases: pBasic (run 45): clang -O3 -load LLVMPolly.so pNoGenSCEV (run 44): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly -polly-optimizer=none -polly-code-generator=none pNoGenSCEV_nocan (run 47): same option

Hi Sanjoy, >> I'm not familiar with fiber-type APIs, but I assume fiber_fork is like >> setjmp, in that it can "return twice"? Yes, user-mode stack switching API are somewhat similar to setjmp. Here are links to a doc page and implementation, just in case you are curious: http://www.boost.org/doc/libs/1_59_0/libs/context/doc/html/context/context.html

...Triple(module->getTargetTriple())); PMBuilder->LibraryInfo = &tlii; if (is_debug) { PMBuilder->Inliner = createAlwaysInlinerLegacyPass(false); } else { target_machine->adjustPassManager(*PMBuilder); PMBuilder->addExtension(PassManagerBuilder::EP_EarlyAsPossible, addDiscriminatorsPass); PMBuilder->Inliner = createFunctionInliningPass(PMBuilder->OptLevel, PMBuilder->SizeLevel, false); } addCoroutinePassesToExtensionPoints(*PMBuilder); // Set up the per-function pass manager. legacy::FunctionPassManager FPM = legacy::Fu...

On Fri, Jun 10, 2016 at 5:25 PM, Gor Nishanov <gornishanov at gmail.com> wrote: > Hi Eli: > > >> Naively, you would expect that it would be legal to hoist the store... > >> but that breaks your coroutine semantics because the global could be > mutated > >> between the first return and the resume. > > Hmmm... I don't see the problem. I think

I think I got it. Original model (with coro.fork and two-way coro.suspend) will work with a tiny tweak. In the original model, I was replacing coro.suspend with br %return in original function. The problem was coming from potential phi-nodes introduces into return block during optimizations. Let's make sure that there is only entry into the return block. In the original model, ReturnBB had

...UNREACHABLE } Accessing anything in the coroutine frame after coro.fork "true" is undefined. As by the time you get to returnBB, the coroutine frame could already be destroyed. Both problems can be statically detected in the Verifier. Alternatively, in CoroEarly pass that runs at EP_EarlyAsPossible extension point, we can replace: %val = *%t with %val = undef (used after coro.fork() returned true) and free(%mem) (*%t) = 20 with @llvm.trap() ; used after frame is destroyed --Gor