similar to: [LLVMdev] Newbie question: Getting info about JIT-compiled function

Apologies if this is a FAQ. I am using the LLVM JIT facility on an x86_64 platform. I generate IR for a single function using IRBuilder(), use the FunctionPassManager to do some optimization passes, and then call ExecutionEngine::getPointerToFunction() to get a native-code version of the function. Everything works fine so far. Two questions: Question (1): How can I get the size of the native

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.

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) );

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

I've been profiling more; see <https://dl.dropbox.com/u/46791180/perf.png>. One thing I'm a bit confused about is why I see a FunctionPassManager there. I use a FunctionPassManager at the end of LLVM IR code generation, write the IR to disk, then read it back later. Why is apparently another FunctionPassManager being used during the JIT'ing of the IR code? And how do I

Thanks. The reason I ask is because I'm looking at some code that does just that. A single FunctionPassManager is constructed with a dummy Module and createStandardFunctionPasses is called on it. The FunctionPassManager cached and run on Functions in other Modules. So far I haven't noticed any problems but I guess that is because the passes added by createStandardFunctionPasses don't

The passes run are determined by TargetMachine::adPassesToEmitMachineCode (or addPassesToEmitMC in the case of MCJIT), which is called from the JIT constructor. You can step through that to see where the passes are coming from or you can create a custom target machine instance to control it. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

On Thu, 24 Jun 2004, Vladimir Prus wrote: > I wonder in what cases FunctionPass is better that Pass. For example, > addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes > FunctionPassManager. Here's a simple way to look at it. Use a Function pass whenever you can. A function pass will always work where a Pass works (it derives from pass as you've noticed),

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if

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

I am trying a setup where the one loop is rewritten as two loops. This avoids the 'rem' and 'div' instructions in the index calculation (which give the loop vectorizer a hard time). However, with this setup the loop vectorizer complains about a too small loop. LV: Checking a loop in "main" LV: Found a loop: L3 LV: Found a loop with a very small trip count. This loop

Thanks, that helps. I saw the possibility to redefine function bodies in the Kaleidoscope tutorial. What's not so clear to me yet, is how to support multiple Modules, but it's getting clearer now. Can I run a potential case past you just to be sure that it is/isn't possible? I'd like to support users dynamically adding and using functions (plus structs, globals etc) to a

In the case when coming from C it was probably the loop unroller and SLP vectorizer which vectorized the code. Potentially I could do the same in the IR. However, the loop body that is generated in the IR can get very large. Thus, the loop unroller will refuse to unroll the loop in a large number of (important) cases. Isn't there a way to convince the loop vectorizer that it should

The loop rotation pass does modify the function, which I'm guessing means that a FunctionPassManager can be used to run LoopPasses (this is not obvious to me after looking through the FunctionPassManager code). Unfortunately none of the other passes I'm using (ScalarEvolution, LCSSA, IndVarSimplify, and LoopUnroll) appear to have an effect. I verified that the function can be loop

Hi Son Tuan, Thanks for taking a look at this :). Responses inline -- > On Mar 14, 2018, at 8:11 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, hi all, > > My goal is to measure debug info loss of each optimization pass in LLVM. I am trying to create a debugify-each mode in opt, inspired by verify-each mode which is supposed to already work. +

Hi Vedant, Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of

> I'd like to support users dynamically adding and using functions > (plus structs, globals etc) to a Module, JIT compiling to an > ExecutionEngine, in an interleaved fashion. That is, declare & define > a function, run it through a FunctionPassManager, add it to an > ExecutionEngine, use it, go ahead and repeat for a different function > with the same Module,

> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project.

On Nov 13, 2012, at 6:15 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > The passes run are determined by TargetMachine::adPassesToEmitMachineCode (or addPassesToEmitMC in the case of MCJIT), which is called from the JIT constructor. You can step through that to see where the passes are coming from or you can create a custom target machine instance to control it.