search for: reoptimisation

...PassManager with different (more time-consuming) Passes, call run() on the module again 6) call getFunction() and getPointerToFunction() again 7) use the new function pointer to execute the JITed code instead. As an added complication, different threads may be performing the initial compilation or reoptimisation, but before we consider this, is there any reason why the above shouldn't work? When I do it, I occasionally get assertion errors such as: <more path...>/RELEASE_28/include/llvm/ADT/APInt.h:819: bool llvm::APInt::operator==(const llvm::APInt&) const: Assertion `BitWidth == RHS.BitWi...

...Passes, call run() on the module again > > 6) call getFunction() and getPointerToFunction() again > > 7) use the new function pointer to execute the JITed code instead. > > > > As an added complication, different threads may be performing the > > initial compilation or reoptimisation, but before we consider this, is > > there any reason why the above shouldn't work? > > > > When I do it, I occasionally get assertion errors such as: > > > > <more path...>/RELEASE_28/include/llvm/ADT/APInt.h:819: bool > > llvm::APInt::operator==(const...

...ore time-consuming) > Passes, call run() on the module again > 6) call getFunction() and getPointerToFunction() again > 7) use the new function pointer to execute the JITed code instead. > > As an added complication, different threads may be performing the > initial compilation or reoptimisation, but before we consider this, is > there any reason why the above shouldn't work? > > When I do it, I occasionally get assertion errors such as: > > <more path...>/RELEASE_28/include/llvm/ADT/APInt.h:819: bool > llvm::APInt::operator==(const llvm::APInt&) const: Asse...

Hi All, I've just started investigating LLVM for use in a project of mine, and I've got a couple of questions: 1. How does LLVM support run-time optimisation - i.e: which elements of the toolchain will optimise a running bytecode / binary? 2. Is there a way, with the existing infrastructure, to do adaptive compilation using the JIT interpreter? Watching said interpreter through GDB

...stem to an instruction set simulator developed at my university which heavily relies on LLVM for JIT compilation. It performs all the compilation in a separate thread from where the interpretation of the simulated program is taking place, meaning it never needs to wait for any compilation. Adaptive reoptimisation also takes place in a separate thread, and this has caused me a multitude of headaches, but I digress... Basically: if the initial compilation is done in a separate thread, can you ensure that any adaptive reoptimisation also happens asynchronously, or will such use cases have to do without your s...

Hi all, At the recent LLVM developers' meeting, I presented a lightning talk on an approach to reduce the amount of dead debug data left in an executable following operations such as --gc-sections and duplicate COMDAT removal. In that presentation, I presented some figures based on linking a game that had been built by our downstream clang port and fragmented using the described approach.

...t simulator > developed at my university which heavily relies on LLVM for JIT > compilation. > It performs all the compilation in a separate thread from where the > interpretation of the simulated program is taking place, meaning it never > needs to wait for any compilation. Adaptive reoptimisation also takes place > in a separate thread, and this has caused me a multitude of headaches, but > I > digress... > > Basically: if the initial compilation is done in a separate thread, can you > ensure that any adaptive reoptimisation also happens asynchronously, or > will > s...

*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

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.