similar to: [LLVMdev] "Multithreaded LLVM" in "Writing an LLVM Pass"

On 8 Oct 2012, at 18:26, Lu Mitnick wrote: > 1. Multiple threads handle different modules (Thread : Module = 1 : 1) > or For ModulePasses, yes. > 2. Multiple threads handle one module (Thread : Module = N : 1) For FunctionPasses, yes. Note that this part is in the future work section, meaning that no one has done it yet. FunctionPasses are independent of each other when running on

On Tue, Oct 09, 2012 at 08:35:57AM +0100, David Chisnall wrote: > On 8 Oct 2012, at 18:26, Lu Mitnick wrote: > > > 1. Multiple threads handle different modules (Thread : Module = 1 : 1) > > or > > For ModulePasses, yes. > > > 2. Multiple threads handle one module (Thread : Module = N : 1) > > For FunctionPasses, yes. > > Note that this part is in

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

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 :

Hi, In following link: https://www.youtube.com/watch?reload=9&v=6X12D46sRFw They have specified that the inliner can't use DomTree/LoopInfo/MemorySSA analysis. 1. What's the reason for this? 2. Why can't we do it using getAnalysisUsage() construct? 3. Can inline use this information in the new Pass Manager? 4. What all information can we derive from DomTree to be of help to

Hi, I'm trying to access an analysis pass from the Inliner pass, and I'm having a lot of trouble getting that to work - I can verify that my pass is loaded and run (it is a dynamically loaded pass that is part of an analysisgroup), however, when I access it using getAnalysis<> from within Inliner::runOnSCC, I am instead getting the default, dummy version of my analysis, which should

On Tue, 7 Nov 2006, Vikram Adve wrote: > 1. The LoopPassManager might become much simpler if the more complex > loop passes are given control over how they iterate over the loops, > rather always rely on the manager to enumerate the loops in some > fixed order. Then the pass could be responsible for making sure that > it handles issues like loops that are deleted during the pass.

Hey LLVMDev, I'm working on a ModulePass that uses ScalarEvolution along with several other analyses. After some debugging, it looks to me like ScalarEvolutionWrapperPass does not handle memory correctly for this case. Here's my current understanding of the problem. ScalarEvolutionWrapperPass maintains a unique_ptr to a ScalarEvolution. Calling getSE() dereferences this pointer.

On Mon, 20 Mar 2006, Michael McCracken wrote: > Hi, I'm trying to access an analysis pass from the Inliner pass, and > I'm having a lot of trouble getting that to work - I can verify that > my pass is loaded and run (it is a dynamically loaded pass that is > part of an analysisgroup), however, when I access it using > getAnalysis<> from within Inliner::runOnSCC, I am

I am trying to write a ModulePass which requires PostDominator sets for every function in the module. Now finding post dominators is a function pass. The link on the llvm.org website says that : "Currently it is illegal for a ModulePass<http://llvm.org/docs/WritingAnLLVMPass.html#ModulePass>to require a FunctionPass <http://llvm.org/docs/WritingAnLLVMPass.html#FunctionPass>.

On 9 Oct 2012, at 08:55, 陳韋任 (Wei-Ren Chen) wrote: > No one has done it yet? From [1], it seems parallel JIT is workable. > Or I just misread the question? Your citation refers to a proprietary program that was presented at EuroLLVM - their changes are not upstream. They are running multiple MCJIT instances in parallel, but they are completely independent - different modules and

Having a ModulePass that requires a FunctionPass that in turn requires another ModulePass results in an assertion being fired. Is this expected behavior (that seems to be undocumented), or a bug? Specifically, the following code will emit the assertion: [VMCore/PassManager.cpp:1597: virtual void llvm::ModulePass::assignPassManager(llvm::PMStack&, llvm::PassManagerType): Assertion

Hello all, I am willing to do "eliminating the void type" project. Is there anyone working on it? === Overview === The general concept is to replaced void with {}. And 'ret void' is a synonym of 'ret {} {}.' === Further Implementation Details === 1. Deleting VoidTyID 2. Deleting LLVMVoidTypeKind (one-to-one relation between VoidTyID and LLVMVoidTypeKind) 3. Use

Hi folks, So, various folks are in the process of porting Grand Central Dispatch to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev for mailing list discussion on the topic) and are making good progress, but one of the issues they're running into is support for Blocks in FreeBSD. On the one hand, they could try and back-port

On 3/21/06, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 20 Mar 2006, Michael McCracken wrote: > > > Hi, I'm trying to access an analysis pass from the Inliner pass, and > > I'm having a lot of trouble getting that to work - I can verify that > > my pass is loaded and run (it is a dynamically loaded pass that is > > part of an analysisgroup),

Chris and Devang, Before you implement the LoopPassManager class, I'd like to discuss this a little bit. I have a suggestion and a question; we can discuss this now or later, as you wish: 1. The LoopPassManager might become much simpler if the more complex loop passes are given control over how they iterate over the loops, rather always rely on the manager to enumerate the loops in

On 02/28/14 04:20 AM, Rick Mann wrote: > Tangentially related, I have a question: > > I don't know, well, anything about how OpenMP is implemented. But does it make sense to use Grand Central Dispatch on platforms that support it (instead of, I assume, pthreads)? We played with implementing OpenMP 3.x tasks on top of libdispatch and while we got it to work - there was some

Hello all, I caught a problem related to pthread library. I built llvm and llvm-gcc then compiling a multithreaded benchmark written in POSIX thread library. The command "llvm-gcc -o bench bench.c -lpthread" ran well while "llvm-gcc -c bench; llvm-ld -o bench bench.o -lpthread" crashed. It told that "llvm-ld: error: Cannot find library 'pthread'". I could

So I got very mixed results. With the CallGraphSCCPass, both `addRequired<DominatorTreeWrapperPass>` and `addRequired<MemoryDependenceAnalysis>` fail at runtime. The LLVM core has just two CallGraphSCCPasses and neither uses neither analyses, so it's hard to find a valid example. I transformed the pass into a ModulePass, using scc_iterator as shown in CGPassManager to process

Dear John, First thing, the 3 loops in Densemap are all " Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " in the 3 functions. The dense map is in a ImmutablePass. I got it in FunctionPass and tried insert the information in this FunctionPass. So to turn the FunctionPass to ModulePass may be a better idea? Another interesting thing: if just before