search for: reoptimise

Hi, Has anyone had any success with running different PassManagers on llvm::Modules they've already JITed and are executing? In detail: 1) getting the IR, in form of an llvm::Module 2) calling PassManager->run() on the module 3) calling getFunction() and getPointerToFunction() to JIT the module 4) executing the JITed code using the function pointer received in step 3 and then what I

Hi Stephen, I confirm your observation. AFAIK the current JIT keeps informations from the module, for example AssertingHandle on Values. It's part of my plan to make the MCJIT independent from Module stuff to allow reoptimizations, or to have multiple copies of JITed functions for one function in the module, but there is a long road to go. Olivier. On Tue, Nov 9, 2010 at 6:57 PM, Stephen

Hi, I found the following wiki page in the Unladen Swallow project: http://code.google.com/p/unladen-swallow/wiki/CodeLifecycle This would appear to answer my question. Could someone confirm for me if it's definitely unsafe to attempt to optimise/JIT any Modules while a different thread is currently executing a JITed function which has been generated from them? Or am I just missing

...lementing is something like the following scenario. a. The JIT interpreter starts executing the program. b. It compiles it, inserting instrumentation, and lets it run for 2 seconds. c. During the run, it records how many times each function is executed. d. After 2 seconds, all hot functions are reoptimised using the info from the instrumentation. Said instrumentation is then removed, and the new versions replace the old. e. The program is resumed. Is this possible to do using the JIT interpreter? As far as I can see, the interpreter itself won't execute during the execution of main() - i.e...

On 29 March 2011 12:35, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > *Project Description:* > > * > * > > LLVM has gained much popularity in the programming languages and compiler > industry from the time it is developed. Lots of researchers have used LLVM > as frameworks for their researches and many languages have been ported to > LLVM IR and interpreted,

...ch doesn't quite achieve this properly due to the slight misuse of SHF_LINK_ORDER, but I expect that a pivot to using non-COMDAT group sections should solve this problem. 3) Provide some kind of halfway house between simply writing tombstone values into dead DWARF and fully parsing the DWARF to reoptimise its/discard the dead bits. I'm hopeful that changes could be made to the linker to improve the link-time cost. There seems to be a significant amount of the link time spent creating the input sections. An alternative would be to devise a scheme that would avoid the literal splitting into secti...

sounds like a good idea to me. but one of the current issues of back-patching in the LLVM is that the back-patching is not done atomically on some of the architectures, i.e. Intel x86. and this makes LLVM JIT not thread-safe in lazy compilation mode. what we need to make sure is that the "updating the resolution for a given symbol" you mentioned is done in an atomic fashion. also, how

*Project Description:* * * LLVM has gained much popularity in the programming languages and compiler industry from the time it is developed. Lots of researchers have used LLVM as frameworks for their researches and many languages have been ported to LLVM IR and interpreted, Just-in-Time compiled or statically compiled to native code. One of the current drawbacks of the LLVM JIT is the lack of an

...suse of SHF_LINK_ORDER, but I expect that a pivot to using non-COMDAT >>>>> group sections should solve this problem. >>>>> 3) Provide some kind of halfway house between simply writing tombstone >>>>> values into dead DWARF and fully parsing the DWARF to reoptimise >>>>> its/discard the dead bits. >>>>> >>>>> I'm hopeful that changes could be made to the linker to improve the >>>>> link-time cost. There seems to be a significant amount of the link time >>>>> spent creating the inpu...