similar to: [LLVMdev] code-altering Passes for llc

On Aug 2, 2009, at 7:09 AM, Artjom Kochtchi wrote: > > Greetinigs, > > I am extending llc to include runtime checks for calls (in X86). So > a call > 'call target' is altered to look like this: > > [some check] > jne error_function > call target > > I've done this by implementing a MachineFunctionPass that is > instantiated > and added

Dan Gohman-2 wrote: > > You don't need a ModulePass to modify a CFG. A MachineFunctionPass > is fine for this. > Well, okay. But I need to insert some BasicBlock that contains the error handling (that the runtime check jumpts to on failure). Just putting another MachineBasicBlock at the beginning of some arbitrary MachineFunction doesn't seem to be the right way to go, does

Does the error function *have* to be auto-generated in your pass? Perhaps the original code should use invokes, and your pass insert the error check with a jne to the "unwind" block. On Mon, Aug 3, 2009 at 5:18 AM, Artjom Kochtchi<artjom.kochtchi at googlemail.com> wrote: > > > Dan Gohman-2 wrote: >> >> You don't need a ModulePass to modify a CFG. A

Hi, Does the current LLVM backend support reading in profile information (without preserving across transformations)? An earlier poster http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7 noted that accessing execution counts in a MachineFunction pass (using the BasicBlock* corresponding to the respective MachineBasicBlock) returned 0 for all blocks. Running llc with

How can I vmjc to run CallGraphSCCPasses? I wrote a test pass that does nothing, and all vmjc says is: vmjc: PassManager.cpp:1604: virtual void llvm::ModulePass::assignPassManager(llvm::PMStack&, llvm::PassManagerType): Assertion `!PMS.empty() && "Unable to find appropriate Pass Manager"' failed. 0 vmjc 0x08a6bfd8 Aborted Running even a built in pass like prune-eh

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

Hi, Shuguang Feng wrote: > Does the current LLVM backend support reading in profile information > (without preserving across transformations)? An earlier poster Yes, it does. > http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7 > > noted that accessing execution counts in a MachineFunction pass (using > the BasicBlock* corresponding to the respective

On Sep 8, 2009, at 1:27 AM, Andreas Neustifter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > the second part of my work is to preserve the profiling information > through all the transformation passes and make it available to the > backend machinery. > > Attached is an example patch on how I plan to preserve the information > for a given

"A module pass can use function level passes (e.g. dominators) using getAnalysis interfacegetAnalysis<DominatorTree>(Function), if the function pass does not require any module passes." http://llvm.org/docs/WritingAnLLVMPass.html In your case, A module pass (ModPass2) is trying tu use function level pass (FunPass1) which uses module level pass (ModPass1). This is not

Hi all, I too am getting this error for x86_64 when I am trying to use the Data Structure Analysis ...I svn upped both the llvm main branch and the poolalloc today in the morning and recompiled everything from scratch : $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so -ds-aa < o.bc opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual void

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the second part of my work is to preserve the profiling information through all the transformation passes and make it available to the backend machinery. Attached is an example patch on how I plan to preserve the information for a given transformation pass. And now comes the question into place: whats the best way to attach the profile info

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

On Sun, 15 Jul 2007, Paolo Invernizzi wrote: > First, I'm not sure if deleting the ExecutionEngine is all I need to > clean-up... so I started with a minimal test just to check Is this llvm 2.0 or llvm svn head? Several minor memory leaks have been fixed since llvm 2.0. -Chris > int main( int argc, char **argv ){ > while( true ){ > Module *M = new

Hi, I'm trying to use analysis results from a CallGraphSCCPass in a ModulePass. Here is the relevant code: struct MyCallGraphSCCPass : CallGraphSCCPass { ... bool runOnSCC(CallGraphSCC& scc){...} }; char MyCallGraphSCCPass::ID = 0; static RegisterPass<MyCallGraphSCCPass> X("cgscc", "Dummy CG SCC pass"); struct MyModulePass : public ModulePass {

Hi, I am trying to use the poolallocator. More specific, I am trying to play around with the pointer compression pass. Though, I get assertion failures for the pass dependencies. This is when it in PointerCompress::getAnalysisUsage tries to register the the BU pass as required. I.e. when AU.addRequired<CompleteBUDataStructures>(); is called. $ opt -f -load

Dear Prakash, Yes, DSA is still in active use, although nobody else uses the -ds-aa pass as far as I know. I tried the below sample (although ds-aa should be in libLLVMDataStructure.so and not libpoolalloc.so), and I get the same error. I've seen similar problems with other passes in our work here. My guess is that -ds-aa is requiring two passes that claim to invalidate each other; this

Dear Prakash, I believe I've fixed the problem you were having with ds-aa. Please update your poolalloc tree, recompile, and let me know if it works. -- John T. Criswell, John T wrote: > [snip] > > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Prakash Prabhu [prakash.prabhu at gmail.com] > Sent:

Hi, all: I wanted to use a FunctionPass (e.g. *MemoryDependenceAnalysis*) in a ModulePass, and then I used the method "getAnalysis<* MemoryDependenceAnalysis*>(llvm::Function *)" described at http://llvm.org/docs/WritingAnLLVMPass.html#ModulePass to get the FunctionPass. But , it still crashed when I invoked this pass in tool 'opt'. However, if I change my pass to

Hi, I'm trying to build llvm on a Solaris/Sparc machine. I get many undefined symbols during the link phase of opt. The link command being run is below. It is identical to the link command that gets run and works on an x86 host. Thanks, Tarun g++ -I/n/fs/scratch/tpondich/ParallelAssert/llvm-objects/include -I/n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt

On 2007-07-14, at 13:56, Anton Korobeynikov wrote: >> You can find out what exactly leaks with the help of valgrind. > > It seems, that Paolo is on Mac OS X. No valgrind there :( All is not lost… http://developer.apple.com/documentation/Performance/Conceptual/ ManagingMemory/Articles/FindingLeaks.html — Gordon