search for: recompileandrelinkfunct

Hello, JIT::recompileAndRelinkFunction's runJITOnFunction does not use the MCI arg, causing null pointer deferences at every call. Attached patch makes runJITOnFunction more reliable. Thanks, Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learn...

On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >> Attached patch makes runJITOnFunction more reliable. > > When would MCI be null? Everytime you call recompileAndRelinkFunction. It calls runJITOnFunction without specifying the MCI argument, which get defaulted to NULL. Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learned that I had been introduced to electronic engineers....

Please add a test to http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup verifying that recompileAndRelinkFunction() keeps working. Then this fix will look fine to me. On Tue, Dec 22, 2009 at 12:23 AM, Gianluca Guida <glguida at gmail.com> wrote: > On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: >> On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >>...

On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: > Hello, > > JIT::recompileAndRelinkFunction's runJITOnFunction does not use the > MCI arg, causing null pointer deferences at every call. > > Attached patch makes runJITOnFunction more reliable. When would MCI be null? -Chris

On Tue, Dec 22, 2009 at 5:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Please add a test to > http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup > verifying that recompileAndRelinkFunction() keeps working. Then this > fix will look fine to me. Here it is. Unfortunately I'm not exactly a C++ guy so I'm open to change this code after any comment you might want to have. Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspi...

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...

...clones of basic blocks in CloneOrigFunc. iv. Set the successors of basic blocks, because this information is lost, when the basic blocks are cloned. (Am I correct?) With the second approach, if I dump the IR for the module after changing the basic blocks, everything looks correct. But when the recompileAndRelinkFunction(Fn) is executed, I get the error: /home/varun/llvm-git/lib/CodeGen/MachineLICM.cpp:956: bool <anonymous namespace>::MachineLICM::IsLoopInvariantInst(llvm::MachineInstr &): Assertion `MRI->getVRegDef(Reg) && "Machine instr not mapped for this vreg?!"' failed....

Dear All, "recompileAndRelinkFunction" found in Interpreter and previously in JIT, is not found in MCJIT. Can I just implement it in MCJIT like its old definition in JIT, or it contradicts with some design issue in MCJIT? Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department Faculty of Engineering - Benha...

...eck, in debug builds, I memset the freed buffer with garbage to try to make it obvious if the buffer is called into. If you don't *know* that all (e.g.) function pointers to this code are dead (which means that execution could come back to the function), you should use the ExecutionEngine::recompileAndRelinkFunction(F) method. I'm happy to answer any questions about this functionality, as usual. -Chris -- http://nondot.org/sabre/ http://llvm.org/

Hi Chris, > If you don't *know* that all (e.g.) function pointers to this code are > dead (which means that execution could come back to the function), you > should use the ExecutionEngine::recompileAndRelinkFunction(F) method. recompileAndRelinkFunction() overwrites the old machine code with a branch to the new. Is it always guaranteed that there's space to write the new branch instructions? A quick look suggests the x86 takes five bytes, PowerPC 16, and the Alpha's implementation is an assert(0)...

...putc(strval[i], stdout); } } gcc 3.2.2 does not inline this by default. Also, on llvm.cs.uiuc.edu/demo, the compiler does not inline the function. However, on my version of the compiler, the function print_string is inlined by default. Question 2: What is the behavior of the function "recompileAndRelinkFunction" (in VM.{h,cpp}) if a program running in lli is currently executing within the function that is being recompiled? Thanks in advance, Brian Brian M. Fahs Graduate Student University of Illinois

On Fri, 12 May 2006, Ralph Corderoy wrote: >> If you don't *know* that all (e.g.) function pointers to this code are >> dead (which means that execution could come back to the function), you >> should use the ExecutionEngine::recompileAndRelinkFunction(F) method. > > recompileAndRelinkFunction() overwrites the old machine code with a > branch to the new. Is it always guaranteed that there's space to write > the new branch instructions? Yes. > A quick look suggests the x86 takes five > bytes, PowerPC 16, PPC should be...

Hi Filip Thank you for your detailed explanation, I was actually looking to implement an adaptive approach which 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

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 something else). Although this method can stop the whole prog...

...it 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 it's compiled with > asserts, of course...

...s a problem with functions calling into other modules. > (which perhaps I could try to solve if would understand addGlobalMapping > better) This is somewhat tricky. To replace a function in-place like this, you should actually modify the function in the original module, then call EE->recompileAndRelinkFunction(fn). This will require some C++ code to delete the original function body, then splice the body of the new function into the old function. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...nd conditional checks enforce this. These checks can all be removed (assertions and conditionals), making M obsolete. At the moment there are a number of call sites for emitObject. I removed all of them and replaced them with a single emitObject call site accessible through the extant, but unused, recompileAndRelinkFunction method. This then becomes the clients access point to compile each individual module. This is obviously a hack to maintain the integrity of the existing API (i.e. bad name, evil type munging F->M etc..). void *MCJIT::recompileAndRelinkFunction(Function *F) { emitObject((Module*) F); fina...

...epatching? for a certain OO system I am working on this could be > desirable when an object/class is updated and replaced- making it > possible in certain cases to update the call point as the code is > replaced. You can repatch a function that was hitted with the ExecutionEngine::recompileAndRelinkFunction method. If you have a symbol that isn't JIT'd that you want to move around, just define a global that holds the pointer, and change the pointer as you wish. -Chris

Dear LLVMers, Can the LLVM JIT, at run-time, take a function for which it has already generated native code, re-optimize it at the LLVM level, and then re-generate its native code, replacing calls of the old function with calls to the new function? I seem to recall that it could, but I need to make sure. Thanks in advance. -- John T.

...or which it has > already > generated native code, re-optimize it at the LLVM level, and then > re-generate its native code, replacing calls of the old function with > calls to the new function? > > I seem to recall that it could, but I need to make sure. Sure, ExecutionEngine::recompileAndRelinkFunction is your API. -Chris