search for: freemachinecodeforfunction

Hello Everyone, Does void JIT::freeMachineCodeForFunction(Function *F) work on arm? I get a crash when I call it on arm.I don't have access to gdb on the simulator I am using , so can't say for sure if it works. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-d...

Hello Everyone, Does void JIT::freeMachineCodeForFunction(Function *F) work on arm? I get a crash when I call it on arm.I don't have access to gdb on the simulator I am using , so can't say for sure if it works. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-d...

...e the same execution engine, but memory still leaks. I should note that if interpreter is used instead of JIT no memmory leakage occurs. Instead of posting my Haskell code, I though it would be better if I post short C++ code that (hopefully) demonstrates the possible leakage. My suspicion is that freeMachineCodeForFunction does not do its job properly. Let us look at HowToUseJIT.cpp example that comes with LLVM source bundle and let us modify the last lines in the following way: for (;;) { gv = EE->runFunction(FooF, noargs); // Import result of execution: outs() << "Result: " <...

...nrado at gmail.com> wrote: > > Great! It just worked. I was a bit worried about using pointers to call > > functions because it's a little too overwhelming in a big project, I > think. > > > > Just for the record, if the function code isn't freed with > > freeMachineCodeForFunction, I get a segmentation fault during > > recompileAndRelinkFunction with this stack dump: > > Running pass 'X86 Machine Code Emitter' on function '@do_print' > > Well, it's not supposed to segfault. At worst, it should give you an > assertion error when you do...

...g incorrectly on the UNREACHABLE instead of the actual error message above it (which means it's our fault, not theirs). Miranda, this is pointing at the same problem you had before. You have a function JIT-compiled, and you're trying to RAUW (ReplaceAllUsesWith) it. You'll need to call freeMachineCodeForFunction(x) before you call x->replaceAllUsesWith(y). And yes, putting your code (and a gdb-produced stack trace when there's a crash) somewhere we can see it (for example, pastebin.com) will always help us debug problems. On Sunday, January 31, 2010, Conrado Miranda <miranda.conrado at gmail.co...

...ut memory still leaks. I should note > that if interpreter is used instead of JIT no memmory leakage occurs. > > Instead of posting my Haskell code, I though it would be better if I > post short C++ code that (hopefully) demonstrates the possible > leakage. My suspicion is that freeMachineCodeForFunction does not do > its job properly. > > Let us look at HowToUseJIT.cpp example that comes with LLVM source > bundle and let us modify the last lines in the following way: > > for (;;) > { > gv = EE->runFunction(FooF, noargs); > // Import result of execution...

That's a good point.  But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT").  The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip                  Addition to my previous mail, llvm has recom...

Hi, I'm testing how to free memory of a JIT'd function. I thought ExecutionEngine::freeMachineCodeForFunction() and Function::eraseFromParent() would work and did a test with the following sample code. But I found that the memory usage of the process is constantly growing as the while loop goes. Could someone shed light on this please? Here is the code. int main(int argc, char **argv) { InitializeNativ...

...ich is basically when some function executed more frequently, I was trying to drop that function and compiled and linked with new optimized function. I just did the following - whenever some function executed more times , I called-back to program, so I that I could be able to call freeMachineCodeForFunction (F) then I compiled that more frequent function with some kind of optimization. But , still I am getting previous function signature and not newest one. Could you please explain , why we can not use this freeMachineCodeForFunction for this purpose. If not, how we can hook some instruction in e...

...print2, it doesn't seem to work correctly. This is the sequence of steps that I am following: llvm::Function *print2f = main->getFunction( "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 );...

...for the next function I generated and run it with JIT. Then again the code generated is what I expected, this time function call changes from 'sum()' to 'get_int_10()', however the problem is I get a 5 instead of a 10. I tried 'recompileAndLinkFunction' as well as 'freeMachineCodeForFunction' and I always get the return value from the first function, and not the second as I should even though the generated code that I dump() says that it has the correct function call. I am using version 3.4 for both clang and llvm. And also I'm using the JIT Engine and not the MCJIT. Do yo...

Great! It just worked. I was a bit worried about using pointers to call functions because it's a little too overwhelming in a big project, I think. Just for the record, if the function code isn't freed with freeMachineCodeForFunction, I get a segmentation fault during recompileAndRelinkFunction with this stack dump: Running pass 'X86 Machine Code Emitter' on function '@do_print' I know no one should do this, but it's good to know LLVM doesn't allow you to leak (or it's just a good side effect of som...

...one could please offer some advice/suggestion on this, I would really appreciate it. Best, Naosuke On Thu, Dec 29, 2011 at 6:58 PM, OKUDA Naosuke <okudanaosuke at gmail.com> wrote: > Hi, > > I'm testing how to free memory of a JIT'd function. > I thought ExecutionEngine::freeMachineCodeForFunction() and > Function::eraseFromParent() > would work and did a test with the following sample code. > But I found that the memory usage of the process is constantly growing as > the while loop goes. > Could someone shed light on this please? > > Here is the code. > > int main...

...s _not_ free this machine code when it returns, so subsequent runFunction() calls don't need to re-compile it, but they also get the original definition even if the function has changed. The JIT will automatically destroy the machine code when F is destroyed, or you can destroy it manually with freeMachineCodeForFunction(). If you have an existing IR function A which calls function B, and you've emitted A to machine code, then you have a machine code call to B in there. Now you want A to call C instead. Without the above assert, it would be relatively easy to change the IR to call C: call B->replaceAllUsesW...

...I would > really appreciate it. > > Best, > Naosuke > > On Thu, Dec 29, 2011 at 6:58 PM, OKUDA Naosuke > <okudanaosuke at gmail.com> wrote: > > Hi, > > > > I'm testing how to free memory of a JIT'd function. > > I thought ExecutionEngine::freeMachineCodeForFunction() and > > Function::eraseFromParent() > > would work and did a test with the following sample code. > > But I found that the memory usage of the process is constantly > > growing as > > the while loop goes. > > Could someone shed light on this please? > > &...

...(that perhaps might work, perhaps not). This approach was to compile each request in a new context, but only keep the llvm::Function we have as the result alive outside this context. The only reason we need to have this llvm::Function, is to be able to cleanup the native code (with ExecutionEngine::freeMachineCodeForFunction). So the question is what would be a recommended way to handle this problem? Is there a way to clean up / free native code like ExecutionEngine::freeMachineCodeForFunction without needing the llvm::Function? Is it safe to use the llvm::Function outside the LLVMContext in the way described here? I...

Albert Graef wrote: > The way I do this in Pure is to always call global functions in an > indirect fashion, using an internal global variable which holds the > current function pointer. When a function definition gets updated, the > Pure interpreter just jits the new function, changes the global variable > accordingly, and frees the old code. > > Compared to Duncan's

...ls into the MemoryManager and functions that use globals allocated inside other buffers. You should be able to deal with having separate calls to allocate global space and allocate code space. You'd just remember the answers you gave and preserve them when copying to a new system. I'd like freeMachineCodeForFunction to avoid corrupting emitted globals, and with the current arrangement of information within the JIT, that means globals and code have to live in different allocations. I think Reid's suggesting a flag of some sort, with one setting for "freeMachineCodeForFunction works" and another fo...

getFunction() -> getPointerToFunction() 2014-06-29 6:40 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Hi Adrian, > > freeMachineCodeForFunction is required but recompileAndLinkFunction is > not, > you can use getFunction() always. > > Try to M->dump() calling M->getFunction() where M is the Module *. > See if how the changes appear in the module dump as expected. > > Yaron > > > > > > 2014-06-2...

...Conrado Miranda <miranda.conrado at gmail.com> wrote: > Great! It just worked. I was a bit worried about using pointers to call > functions because it's a little too overwhelming in a big project, I think. > > Just for the record, if the function code isn't freed with > freeMachineCodeForFunction, I get a segmentation fault during > recompileAndRelinkFunction with this stack dump: > Running pass 'X86 Machine Code Emitter' on function '@do_print' Well, it's not supposed to segfault. At worst, it should give you an assertion error when you do something wrong (when i...