similar to: [LLVMdev] Pass Scheduling Information without using opt

Hi Ralf, I believe all you need to do is call llvm::llvm_shutdown(). - Daniel On Sun, Jul 26, 2009 at 11:51 AM, Ralf Karrenberg<Ralf.Karrenberg at gmx.de> wrote: > Hello everybody, > > is it somehow possible to get information about what passes were run in > what order  or timing analysis of passes *without* using opt? > I am implementing a ModulePass that at some point

Hey Daniel, thanks for the response. > I believe all you need to do is call llvm::llvm_shutdown(). > I am not sure that this is what I need. When and how should I call llvm_shutdown()? After the FunctionPassManager is done, the calling ModulePass still performs quite a few actions on the transformed code and also calls the FunctionPassManager on different functions. However, I need

On Sun, Jul 26, 2009 at 1:48 PM, Ralf Karrenberg<Chareos at gmx.de> wrote: > Hey Daniel, > > thanks for the response. > >> I believe all you need to do is call llvm::llvm_shutdown(). >> > I am not sure that this is what I need. When and how should I call > llvm_shutdown()? At the end of the program, this just arranges for LLVM's "managed statics"

Daniel Dunbar wrote: > Ah, in this case llvm_shutdown isn't what you are looking for. I've > never looked at the Statistic implementation so I can't be any help > here, but if you poke around starting with "llvm/ADT/Statistic.h" you > may find a way to do what you want. I looked into that already, but Statistic.h only gives me the possibility to implement tracking

On Mon, Jul 27, 2009 at 1:43 AM, Ralf Karrenberg<Chareos at gmx.de> wrote: > Here is some example code that describes what I am doing: > > MyPass : ModulePass { > > bool runOnModule(mod) { > > for some Functions f in mod { > (do some stuff) > > ExistingModuleProvider mp(mod); > FunctionPassManager* fpm = > new FunctionPassManager(&mp); I think

Hi, I am expieriencing strange behaviour of llvm's optimization passes and I don't understand what I am doing wrong. Basically all I've done is extracting code for optimization of a llvm-function in a llvm-module and put it into a separate function for better readability. The original code looks like follows (and works as expected): ----------------------------- std::string

On 2008-12-19, at 06:59, Ralf Karrenberg wrote: > I am expieriencing strange behaviour of llvm's optimization passes > and I don't understand what I am doing wrong. > Basically all I've done is extracting code for optimization of a > llvm-function in a llvm-module and put it into a separate function > for better readability. The original code looks like follows

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm working with code that uses a plain PassManager and want it to generate code, are there any options better than doing this: /** * Wrapper class to run a FunctionPassManager as a ModulePass so that it * can be added to a plain PassManager. */ class FunctionPassManagerModulePass : public ModulePass { FunctionPassManager

On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > working with code that uses a plain PassManager and want it to > generate > code, are there any options better than doing this: That's what FPPassManager does (include/llvm/PassManagers.h) . Function pass manager itself is a module level pass.

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

On Thu, Jun 21, 2007 at 04:37:14PM -0700, Devang Patel wrote: > > On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > > > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > > working with code that uses a plain PassManager and want it to > > generate > > code, are there any options better than doing this: > > That's what

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

Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor

> >> You can look at AddOptimizationPasses() in opt.cpp. > > > > As far as I understand, the two passmanager do not interleave their > > passes. It first runs all the function passes and below. Then all the > > module passes. So if you specify: > > > > opt -mymodulepass0 -myfunctionpass -mymodulepass1 > > > > What you actually get is:

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

Thanks for such a rapid response! > Don't know about Passes in the backend, but this could be a problem of > an FunctionPassManager trying to use a ModulePass. I manually applied the patch you provided for llc (I'm using the 2.5 release of LLVM not ToT) and it fixed my compilation error. When your patch replaced the FunctionPassManager used by llc with a PassManager the error went

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

Hi again, I come back to this issue with an example. It's a pass which does nothing but throw the 'Unable to schedule' error. namespace { struct MyPass : public FunctionPass { static char ID; // Pass identification, replacement for typeid MyPass() : FunctionPass(ID) { initializeMyPassPass(*PassRegistry::getPassRegistry()); } virtual void

Hello We are migrating from 2.9 to 3.2 Here is some code that does not compile any more llvm::PassManager *pm; llvm::FunctionPassManager *fpm; module = llvm::ParseBitcodeFile(mb,context,&err_str); if (!module) { error() <<"Failed to load module from bitcode file: " <<err_str <<endl; exit(1); } pm = new PassManager();

Hi, I'm trying to add support in my back end for certain functions that are seen as built-in by the target. Some of these functions can be implemented in a) LLVM, and some in b) the native target language. My approach to case a) is to write the built-in function implementation in C, compile it to LLVM using Clang, link it to the module that uses it and finally add a pass to inline it.