similar to: [LLVMdev] MAJOR API CHANGE: Pass initialization without static constructors

On 10/8/10 3:15 PM, Owen Anderson wrote: > > On Oct 8, 2010, at 1:05 PM, John Criswell wrote: > >> On 10/8/10 1:29 PM, Owen Anderson wrote: >>> Hello fellow LLVM-ers, >>> >>> As those of you who follow llvm-commits have probably noticed, I've >>> been hard at work reworking our pass infrastructure to perform pass >>>

Forgot to reply to the list. -- John T. -------- Original Message -------- Subject: Re: [LLVMdev] MAJOR API CHANGE: Pass initialization without static constructors Date: Fri, 8 Oct 2010 15:05:21 -0500 From: John Criswell <criswell at illinois.edu> To: Owen Anderson <resistor at mac.com> On 10/8/10 1:29 PM, Owen Anderson wrote: > Hello fellow LLVM-ers, > > As

Hello fellow LLVM-ers, As those of you who follow llvm-commits have probably noticed, I've been hard at work reworking our pass infrastructure to perform pass initialization/registration without static constructors. This is a boon for clients of the LLVM libraries, as they can now control when and if initialization occurs, as opposed to being forced to incur the initialization cost at

On Oct 8, 2010, at 1:37 PM, John Criswell wrote: > On 10/8/10 3:15 PM, Owen Anderson wrote: >> >> On Oct 8, 2010, at 1:05 PM, John Criswell wrote: >> >>> On 10/8/10 1:29 PM, Owen Anderson wrote: >>>> Hello fellow LLVM-ers, >>>> >>>> As those of you who follow llvm-commits have probably noticed, I've been hard at work

John, On Oct 8, 2010, at 1:05 PM, John Criswell wrote: >> These initialization routines must be invoked before the PassManager will be able to resolve pipelines involving your pass. For convenience, LLVM now exposes per-library batch initialization routines, i.e. initializeScalarOpts(), which initialize all the passes within a given library in a single go. > > From an ease of

On 10/8/10 3:44 PM, Owen Anderson wrote: > [snip] > >> Hrm. I see. >> >> I still don't like the idea of having every statically-linked tool explicitly initializing every library that gets linked in. Just dumping the library into the Makefile and being done with it was much nicer. >> >> If you can find a reasonable way to support that, it would be nice.

Your constructor is not calling initializeTestMPPass(), and you're using RegisterPass which I think was deprecated in favor of INITIALIZE_PASS. You can look at, for example, lib/Transforms/Scalar/IndVarSimplify.cpp for examples of how to initialize, e.g. having "INITIALIZE_PASS_DEPENDENCY(LoopInfo)" sandwiched between BEGIN and END. Note that you'll want a forward declaration of

On Oct 30, 2012, at 3:15 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 10/30/2012 4:10 PM, Ashwin kumar wrote: >> >> Assertion failed: (PI && "Expected required passes to be initialized"), >> function schedulePass, file PassManager.cpp, line 597. >> >> >> I register the passes using RegisterPass function call.

Hi Michael, hi Duncan, yesterday I stumbled over something that might be related. At least I could also just be doing some initialization wrong or something in this direction... In my case, I hit a segfault in PassInfo::isAnalysisGroup() after PassManager.add(myModulePass) is called. My setup seems fairly simple, the attached code should reproduce the error. Compile with g++ test.cpp

Thanks for the response. I do have assertions enabled, and none of them are getting hit. I did do a search of the mailing list for the past year (approximately) before writing my email, and what I found was that you should be allowed to use LoopInfo and other analysis function passes from a module pass, with the only difference being that getAnalysis is passed the function. The example code I

Dear all, I wrote a machine function pass to run with llc. But I get this error while building: "/home/erdem/llvm/lib/CodeGen/CodeGen.cpp:80: error: undefined reference to 'llvm::initializeNoopInserterPass(llvm::PassRegistry&)'" NoopInserter is the name of my pass. I already added this line to InitializePasses.h: "void

I had INITIALIZE_PASS_BEGIN and INITIALIZE_PASS_END macros. I replaced them with INITIALIZE_PASS but I get the same error. If I understand correctly, I need to modify Passes.h, InitializePasses.h, and Codegen.cpp files to register my pass, right? Another question is: Is it necessary to have the createNoopInserterPass function? Erdem -------------- next part -------------- An HTML

Let me rephrase to make sure I understand. Once we have this settled, I'll update the comments in the file to summarize and possibly update the docs. On 08/21/2015 10:27 AM, Owen Anderson wrote: > The macro versions should be preferred, as they reduce static initializaters. Makes sense. But the tradeoff is that they need to be baked into the list of known passes so that someone knows

Does anyone know what the guidelines are supposed to be for properly initializing a pass? Looking around, we seem to have three styles of pass registration in use. INITIALIZE_PASS(...) INITIALIZE_PASS_BEGIN(...) INITIALIZE_PASS_DEPENDENCY(...) ... INITIALIZE_PASS_END(...) static RegisterPass<FooPass> X(...); (This is the one encouraged in the docs, but seemingly the least widely used

Hello everyone, I have written several complex passes till now, but I cannot write a MachineFunctionPass pass. It just gives me segfault. Hence I reduced the pass to the following form : using namespace llvm; namespace { class CFGexplorator : public MachineFunctionPass { public: static char ID; // Pass identification, replacement for typeid CFGexplorator() : MachineFunctionPass(ID)

I found that : "Code generator passes are registered and initialized specially by TargetMachine::addPassesToEmitFile and similar routines, so they cannot generally be run from the *opt* or *bugpoint* commands."...So how I can run a MachineFunctionPass? In the end, I just want to apply a DFS on a CFG of a function. And I need oriented edges and wanted to use

I've been puzzling over this for a day: Unable to schedule 'Unnamed pass: implement Pass::getPassName()' required by '<some pass>' Unable to schedule pass UNREACHABLE executed at llvm/lib/VMCore/PassManager.cpp:1213! First, why can't getPassName find the name? I have provided one in the usual way. Second, why is it unable to schedule the pass? -debug-pass=Details

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

When migrating my project to 2.9, I've encountered a strange segfault where if a ModulePass's getAnalysisUsage adds LoopInfo and DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will segfault. What's odd is that if I rearrange this (add required for DominatorTree before LoopInfo), it does not segfault. I realize that LoopInfo requires and preserves DominatorTree, but this

On Jul 8, 2009, at 7:57 AM, John Criswell wrote: > Owen Anderson wrote: > Can you give a brief example of where to find the LLVMContext within a > ModulePass or FunctionPass? Is this just the context stored within > the > Module or Function passed to runOnModule/runOnFunction? Passes have a protected Context member, which is set for them by the PassManager, if you don't