similar to: [LLVMdev] (no subject)

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

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

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

Hi, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what

Hi, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifierPass. This is what

Hi, I'm fighting with this quite some time now: Is there a way to mark an Analysis (in my case ProfileInfo) as perserved by _all_ passes? I have tried to add ProfileInfo directly in Pass.h:getAnalysisUsage() but that produces nasty circular library dependecies. I also tried to simply store a pointer to the ProfileInfo in Module but then the PassManager gets confused resulting in double

When I searched for branch frequency profiling on the internet, I got this link by a casual chance: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch. It seems it was written by Andrei Rimsa. So I downloaded and integrate these files into the llvm-2.8 building. After the building, I tried "opt -static-profile bitcnt_1.bc", and an segment fault error occured. I debugged it

Hi all, I am experiencing a problem managing the command line option of a set of passes in my LLVM project. Attached you find a toy project the triggers the problem. The project is made up of two passes: "AnalysisPass" and "TransformPass". "TransformPass" requires "AnalysisPass" and they both share a common integer command line option called

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, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a

If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysis pass can crash the system if the TargetData pass is lurking in the list without

Hi I am modifying LLVM to enable runtime feedback directed optimizations. I have modified the instrumentation part of LLVM to keep instrumentation data in some pre-setup structures in memory and use the JIT to recompile some of the hot functions with profiling information. I need an analysis pass which loads the profiling data in memory and can be used by different optimization passes in LLVM,

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

On Wed, Jul 1, 2009 at 2:36 AM, Andreas Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> [...] >> >> 1. The intent of ProfileInfo is that it is the public interface used by the rest >> of LLVM for all "profiling" related analyses. As such, we want it to have a >> thin, well-defined interface which can be implemented by multiple analysis >>

Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader,

Shuguang Feng wrote: >> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass >> really the last pass to touch the ProfileInfo before you are using it? > > Below is the sequence of passes that I see. Although the > NoProfileInfo pass is being run, it should be subsequently overridden > by ProfileInfoLoaderPass (LoaderPass) correct? Yes. >

Hi. On 11/17/2009 08:16 PM, Andreas Neustifter wrote: > Hi, > > Devang Patel wrote: >> On Tue, Nov 17, 2009 at 9:03 AM, Andreas Neustifter >> <astifter-llvm at gmx.at> wrote: >> >>> Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately

Hello: I am following the example code in BasicBlockPlacement.cpp. That transformation relies on basic block execution frequencies that have been read from a profile file. This is how it loads the profile data: 1. In getAnalysisUsage, it calls addRequired<ProfileInfo>(), and 2. In the runOnFunction, it calls getAnalysis<ProfileInfo>() which returns a ProfileInfo object pointer.

Hi all, after some work I finally am able to preserve the ProfileInfo in quite some passes. My first question is how to deal with this patch. I have touched quite some code, everywhere are scattered bits of "preserving code" and a quite some additions to the ProfileInfo-API. I guess checking in the ProfileInfo part is not a problem, but how shall I proceed with all the code in the

Hi all, I have some questions about the maintenance of the Profiling Code, since this is largely my contribution I still feel responsible for it. (I have not finished my master thesis, so it also is still work in progress... :-) When there are API changes in LLVM, I guess the person changing the API is responsible for changing all the occurrences in LLVM? (So I do not have to worry about