search for: createpasses

While trying to add a pass to the ARM back end I'm getting quite a lot of this assertion failure: Pass.cpp:255: llvm::Pass* llvm::PassInfo::createPass() const: Assertion `NormalCtor && "Cannot call createPass on PassInfo without default ctor!"' failed. A simple way to get it is to add two lines to ARMTargetMachine.cpp: #include "llvm/Transforms/Scalar.h" and

Hi, I've been encountering a problem with function pass manager with llvm-2.6. Somehow system does not know how to create analysis pass if it's required by some other pass. I got following after adding various debug prints to PassManager.cpp I got following results for my reduced test program which just loads module and then tries to make a function pass manager. elhigu at

...gt; wrote: >> This function is marked virtual but doesn't override anything, doesn't have >> any overrides, and has no in tree callers. Can it be removed? > > Given that it is dead, yes :-) > It used to be called from clang, from lib/CodeGen/BackendUtils.cpp, function CreatePasses. It doesn't seem to be the case anymore. I'm not familiar with that part of the code. +Matthew -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Dear everyone, I want to traverse call graph, but I have some trouble . In my pass MyPass which need to traverse call graph, I firstly added the CallGraph analysis to the pass requirements by *AU.addRequired<CallGraph>();* My pass MyPass then will be added to a pass manager by *manager.add(new MyPass());* and then I want to traverse the call graph such as: CallGraph CG =

Good morning! After updating and recompiling my copy of the LLVM trunk I noticed that the line "_passManager.add(llvm::createTailDuplicationPass());" in my code fails with the following assertion: Assertion failed: NormalCtor && "Cannot call createPass on PassInfo without default ctor!", file D:\Workspace\llvmtrunk\include\llvm/PassSupport.h, line 111 This behavior

I'm trying to access the MachineFunctionInfo structure from a pre-ISel pass. In order to do this I have to get access to the MachineFunction and then call getInfo(). Currently in my pass I request it via: void AMDILBarrierDetect::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<MachineFunctionAnalysis>(); FunctionPass::getAnalysisUsage(AU); } However, I am getting an

The option handling in clang in fairly different from opt. The comment about the mixed name was just a guess as to why you don't see the driver passing it down to -cc1. Once that is working, you will probably need to: * Patch ParseCodeGenArgs to record the option * Patch EmitAssemblyHelper::CreatePasses to set the option to enable the pass in the pass manager (assuming that is the effect you want). On 1 October 2013 15:48, Diego Novillo <dnovillo at google.com> wrote: > On Tue, Oct 1, 2013 at 3:42 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> You are c...

...ing the handling of this option too far down. I moved it up and it's now being passed. Not sure what order needs to be kept in this function, however. > Once that is working, you will probably need to: > > * Patch ParseCodeGenArgs to record the option > * Patch EmitAssemblyHelper::CreatePasses to set the option to enable > the pass in the pass manager (assuming that is the effect you want). Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. The attached patch does what I want. Does it look like it's in the right direction? Thanks. Dieg...

...anything, >>>> doesn't have >>>> any overrides, and has no in tree callers. Can it be removed? >>> >>> Given that it is dead, yes :-) >>> >> >> It used to be called from clang, from lib/CodeGen/BackendUtils.cpp, >> function CreatePasses. It doesn't seem to be the case anymore. I'm >> not familiar with that part of the code. >> +Matthew >> >> -Krzysztof >> > > It is actually part of a patch that we do not intend to upstream. > Unfortunately this part of the patch slipped through. I...

On Tue, Oct 1, 2013 at 3:42 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > You are calling the option -auto-profile in some places and > -fauto-profile in others. Maybe it is just a typo? In opt, the option is named '-auto-profile' when I instantiate the pass: INITIALIZE_PASS(AutoProfile, "auto-profile", "Auto Profile loader", false,

---------- Forwarded message ---------- From: Qingan Li <ww345ww at gmail.com> Date: 2011/5/30 Subject: To: llvmdev at cs.uiuc.edu Hi, I wrote an analysis pass, myPass, inherited from both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const

I recall having a similar problem while coding my own special-purpose "opt". My guess: try adding the following lines before your pass is inserted into the PassManager: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeIPA(Registry); You might require other library initializations. Have a look at the "opt" source code. On 02/12/13 10:36,

Mehdi, I’m seeing lots of “upgrading” logic, If (UseIPRA) createPass(new DummyCGSCCPass); if (UseIPRA) addPass(createRegUsageInfoPropPass()); if (UseIPRA) addPass(createRegUsageInfoCollector()); ??? --Peter. From: mehdi.amini at

Hi, I have trouble making my ProfileInfo-Analysis available in the backend, I have changed llc so it loads the ProfileInfo if requested, the PassManger gives this output: > Target Data Layout > Create Garbage Collector Module Metadata > Basic Alias Analysis (default AA impl) > DWARF Information Writer > No Profile Information > Module Information > ModulePass

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

Hi, I wrote an analysis pass, myPass, inherited from both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const {* * AU.addRequired<CallGraph>();* * AU.setPreservesAll();* *}* Then, I assumes the UnreachableBlockElim (inherited from

...option too far down. I moved it up and it's now being passed. > Not sure what order needs to be kept in this function, however. > >> Once that is working, you will probably need to: >> >> * Patch ParseCodeGenArgs to record the option >> * Patch EmitAssemblyHelper::CreatePasses to set the option to enable >> the pass in the pass manager (assuming that is the effect you want). > > Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. > > The attached patch does what I want. Does it look like it's in the > right...

This function is marked virtual but doesn't override anything, doesn't have any overrides, and has no in tree callers. Can it be removed? -- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140429/fd552b41/attachment.html>

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" ><div>Hello,<br><br>I notice some strange behavior with the LegacyPassManager. I’ve added a new pass requirement of BlockFrequencyInfoWrapperPass to lib/Transforms/IPO/GlobalOpt.cpp.<br>However,

I'm trying to port llvm-lua so it's buildable with llvm trunk. A problem I'm running into is that it uses the older BlockPlacement pass. From searching around and reading llvm's commit, this pass has been replaced and superseded by Chandler's MachineBlockPlacement pass. What's unclear to me is how exactly do you add this pass to say a function pass manager? The current