similar to: [LLVMdev] Re-JITing a Function

On Oct 27, 2009, at 9:18 AM, John Criswell wrote: > 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

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

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

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

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

My understanding is that the JIT system allows during the running of the system resolution of call instructions to undefined functions to be trapped and then patched with the correct address (is this true?). The question I have is does the current system also allow for repatching? for a certain OO system I am working on this could be desirable when an object/class is updated and replaced- making

Hi All, I just implemented an often-requested feature: the ability to delete machine code out of the JIT's code buffer (the ExecutionEngine::freeMachineCodeForFunction(F) method). The implementation uses a very general free-list mechanism for tracking free ranges in the buffer, and it works perfectly in my simple test cases designed to cover all of the code paths. However, I don't

On Sat, Jan 30, 2010 at 6:22 PM, Conrado Miranda <miranda.conrado at gmail.com> wrote: > 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

On Jun 29, 2009, at 3:37 AM, Carter Cheng wrote: > > My understanding is that the JIT system allows during the running of > the system resolution of call instructions to undefined functions to > be trapped and then patched with the correct address (is this true?). Yes, see: http://llvm.org/docs/tutorial/LangImpl4.html#jit > The question I have is does the current system also

I am trying to JIT some code containing an indirect branch (and the corresponding store i8* blockaddress(@label)). I am using LLVM 2.7 code base. I build the ExecutionEngine using EngineBuilder, and call engine->getPointerToFunction(func). When I use setOptLevel(llvm::CodeGenOpt::None), the JITing fails with the following message : JIT.h:131: virtual void*

Ok, another explanation. In my runtime that uses LLVM as JIT engine, I have an instnace of GlobalVariable. The program I run in it writes some value to this variable. How can I read it? 2011/5/18 Duncan Sands <baldrick at free.fr>: > Hi, > >> I need to define the global variable which would be modified by JITted >> code. Can I read it from the JITter itself? It is of

On Apr 21, 2005, at 12:12, Chris Lattner wrote: > Ok. Thanks, for forgot about that patch :( No problem, since I still don't know how to integrate it cleanly into the build system. Platform dependencies are very annoying. > I think it would be more straight-forward to have a single lock that > the jit resolver can aquire. Makes sense to me at least This is actually what I ended

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

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

Dear LLVMers, I’m investigating the response time of my JIT, and according to profiling, optimization takes 85% of the compile time, while the rest is being split evenly between the front-end and machine code generation. Much of the optimizer time is spent in various alias analysis passes. I’m happy with the generated code quality and wouldn’t like to lower the optimization level (O2). Would

Hi LLVMers, the example attached I have used to prove that JIT and some visible optimizations are really invoked. Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 on my Athlon XP 1500. Nice. P.S. guys, no fears, I don't plan to flood the cvs repository with my "brilliant" examples ;) --- Valery A.Khamenya -------------- next part -------------- An

I just located a concurrency error in my LLVM patch to add locks to the JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp, which clearly is a problem since This particular issue causes an assertion failure on occasion when running a task that spawns threads on a parallel machine. Any recommendations about if I am doing something that seems horribly wrong are welcome. I'll

Hi all, (thanks to Reid, who gave nice advice) the fibonacci function code works now. Please find attached file. but... the performance is adequate, say, for byte-code interpretation mode and not for optimized JITing. fibonacci function of 35 from attached file is more then 100 times slower then the following code compiled with "gcc -O2" : ----------- #include <iostream> int

On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > (thanks to Reid, who gave nice advice) the fibonacci function code > works now. Please find attached file. > > but... the performance is adequate, say, for byte-code > interpretation mode and not for optimized JITing. > fibonacci function of 35 from attached file is more > then 100 times slower then the following code compiled