search for: deletebody

...gt;V'' in the pristine function map, make V''->V' in the Module map. 4. Fix up arguments to the pristine functions _a_la_ what is done in CloneModule. 5. Delete the function bodies of all functions in the cloned Module (these are the optimized bodies) by calling deleteBody on them. 6. Call CloneFunctionInto to clone the pristine functions into the cloned Module. 7. Fix up linkages (set function linkages in the Module to what they are in the pristine function clones (they were changed to External by deleteBody). 8. Delete all the pristine Function clones, t...

On Wednesday 09 July 2008 13:24, Devang Patel wrote: > Is it possible to explain intended use of original unoptimized version ? bugpoint. I want to run it on the IR produced by our frontend. This will help us generate new LLVM tests we can send upstream. We've fixed bugs that aren't caught by the upstream tests and it would be nice to capture the problem and make the test

I think you need to call "llvm::Function::deleteBody() first" On Tue, Mar 23, 2010 at 15:49, Reid Kleckner <rnk at mit.edu> wrote: > On Tue, Mar 23, 2010 at 7:04 AM, Gabi <bugspynet at gmail.com> wrote: >> Hi >> I get huge memory leaks using LLVM IRBuilder (trunk version) >> >> Basically I recreate a funct...

...; function map, make V''->V' in the Module map. > > 4. Fix up arguments to the pristine functions _a_la_ what is done in > CloneModule. > > 5. Delete the function bodies of all functions in the cloned Module > (these are > the optimized bodies) by calling deleteBody on them. > > 6. Call CloneFunctionInto to clone the pristine functions into the > cloned > Module. > > 7. Fix up linkages (set function linkages in the Module to what they > are in > the pristine function clones (they were changed to External by > deleteBody). &...

...Is. OK. > > I'm not sure I understand your goal with having one context per > function. The goal is to remove all constants created during IR creation of a function, once the function has been JITted. For example, after the function has been JIIted, I can call llvm::Function->deleteBody, that will delete the instructions in the function. But all llvm::Constants created by the function will remain in memory. If I could attach a LLVMContext per function to create the constants, I would be able to delete all constants created for the function's body by deleting the LLVMConte...

...do it before and after jitting the new function and subtract them, in which case I'll get the size of the new function which I can then book to the agent. > > Finally, can I free the memory used by the in-memory IR after the code > > is generated? > > Yes, you can call F->deleteBody() after JIT'ing F. Sorry, I meant to ask whether it's still necessary to keep F around, ie. to delete generated code. Is there a standard approach to garbage collecting code in LLVM? Sandro

...g? Or would I have to subclass JITEmitter and add a > method to perform this calculation? You could do that, it will tell you the size of all of the machine code jit'd. > Finally, can I free the memory used by the in-memory IR after the code > is generated? Yes, you can call F->deleteBody() after JIT'ing F. -Chris > Sandro > > [1] http://llvm.org/doxygen/classllvm_1_1Function.html#a27 > [2] http://llvm.org/doxygen/classllvm_1_1JIT.html > [3] http://llvm.org/doxygen/classllvm_1_1MachineCodeEmitter.html > _______________________________________________ > LLV...

Nicholas, > What if I want to have global llvm::Type's, that can be used by many > LLVMContext's. For example, I'd like to have one LLVMContext per > function, and be able to create constants that belong to the context > but using a global, shared amongst LLVMContext's, llvm::Type. > > I know that's not doable right now, but aren't we losing this >

...ne::freeMachineCodeForFunction without needing the > llvm::Function? Is it safe to use the llvm::Function outside the > LLVMContext in the way described here? Is there a way to clean up the > constants allocated in the LLVMContext manually? > I believe it is safe to use llvm::Function::deleteBody() to free the IR from the function. IIRC we used deleteBody() for Unladen Swallow, which was a few years ago now. You'd still have to implement some kind of type cleanup in/on the context, and the function type will still reference the types of the parameters. Or maybe would it be possible t...

In my quest to account for memory, I've now come to the in-memory IR, and the generated code. I want to book the generated code memory against the agent that is generating the code. I see that LLVM's Function class [1] has a size function; what does this represent and can I use it to account for the space used by the in-memory IR? As for generated code, the JIT [2] class simply returns a

Hi, I am working on a binary translator and use LLVM for this. In the process, I generate millions of constants (immediate values in the source binary code). The problem is that these constants seem to be not cleaned when I delete the LLVM code (using Function::deleteBody() ) and as a result the memory usage keeps growing. I browsed the forum and found that constants "live forever" by design. Is there are simple way of cleaning the used memory without destroying everything (unloading the ExecutionEngine, freeing the module, calling llvm_shutdown) ? Ideall...

Hello all, I've already bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

...ion( "print2" ); print2f->takeName( print1f ); llvm::Function *mainf = main->getFunction( "mainOfLibrary" ); ee->freeMachineCodeForFunction( mainf ); ee->freeMachineCodeForFunction( print1f ); print1f->replaceAllUsesWith( print2f ); print1f->deleteBody(); print1f->dropAllReferences(); print1f->eraseFromParent(); mainfPtr = ee->recompileAndRelinkFunction( mainf ); ASSERT_NE( mainfPtr, nullptr ); ret = ((int(*)(void))(mainfPtr))(); EXPECT_EQ(0xbeefdead, ret); Can you please let me know if I am missing something in the...

...nction *f = &*I; >     if(!f->isDeclaration()) { >       execution_engine->getPointerToFunction(f); >     } >   } >   // all functions are compiled so I'd like to dispose of the bitcode any > memory used in the compilation - how can I do this? You can call (I think) deleteBody on each compiled function if you're done with it to delete the IR and leave the machine code. You can't delete the functions themselves, because their pointers are used as keys in a hashtables. Reid

Hi, I'm seeing rather high memory usage from LLVM and I'd like to track down what I'm doing to cause it. My application is a simple web application server that compiles web pages with embedded script to bitcode and compiles them with the JIT on demand. I've taken tools/lli.cpp as a starting point and extended it to load additional modules. However, if I load successive pages and

Hi Gael I am sorry that I couldn't explain what I was trying to say, anyway I've got the answer :) . In the *parseFunction* method returns *llvmfunction* pointer of compiled method and then it will be stored in to cache. Could you please more elaborate on how those machine instructions ( native functions) executing by llvm. I was trying trace and I couldn't able to find

Hi Chris, thanks for your answers! [large executables] > It depends on what you're building. A release build of LLVM (make > ENABLE_OPTIMIZED=1, with the results in llvm/Release) is > significantly smaller than a debug build. Even with that, however, > the binaries are larger than they should be (5M?). Noone has spent > the time to track down why this is to my

...lizer(nullptr); > + if (isSafeToDestroyConstant(Init)) > + Init->destroyConstant(); > + } > + I->removeDeadConstantUsers(); > + NumVariables++; > + } > > Do you need to set the linkage of global variables to external? I noticed > that Function::deleteBody() does this but setInitializer(nullptr) does not. > Ditto for aliases. Hmm, I am not sure - I basically am doing the same things GlobalDCE does (aside from erasing them from the function/variable/alias list). I guess it didn't matter in the GlobalDCE case since they were being completely er...

But in my module this function already exist… I first want to delete it but without also deleting the calls to it… From: Boldizsar.Palotas at esa.int <Boldizsar.Palotas at esa.int> Sent: Donnerstag, 13. Dezember 2018 10:53 To: Gaier, Bjoern <Bjoern.Gaier at horiba.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Setting a function in a

On Tue, Mar 23, 2010 at 7:04 AM, Gabi <bugspynet at gmail.com> wrote: > Hi > I get huge memory leaks using LLVM IRBuilder (trunk version) > > Basically I recreate a function over and over again, and pretty sure > that my code doesn't cause the leak > while(true) > { >  Function *fn = module->getFunction(name); >    if (fn) >