search for: jitinfo

...e and friends. Is it possible to just link in selected object files instead of entire libraries? Second, there is functionality that the loader needs to have that depends on VMCore, but doesn't actually need it for my purposes. The main thing is the 'relocate' function in each (System)JITInfo.cpp file. I would like to be able to get the correct JITInfo object (really just the function) without having to link in extra stuff, instantiate modules,targets, etc. Ideally this would not require duplicating any code :) How does one go about doing this? -- -Alex

...then link with "LLVMCore.a" instead of just "LLVMCore". > > Second, there is functionality that the loader needs to have that > depends on VMCore, but doesn't actually need it for my purposes. The > main thing is the 'relocate' function in each (System)JITInfo.cpp > file. I would like to be able to get the correct JITInfo object > (really just the function) without having to link in extra stuff, > instantiate modules,targets, etc. Ideally this would not require > duplicating any code :) How does one go about doing this? You'd have to bre...

...g results on ARM and PPC64. The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for simple examples. I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. The JITInfo parts can stay, they may be useful if someone wants to implement lazy compilation on top of MCJIT. It would become dead code though. The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT never worked for non-darwin platforms and seems to be broken even there at the moment. Any o...

...> The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even > for simple examples. > > I'm proposing to remove the JIT code emitters for the ARM and PPC targets > now so it's no longer holding back the development of the MC parts for > those backends. The JITInfo parts can stay, they may be useful if someone > wants to implement lazy compilation on top of MCJIT. It would become dead > code though. > > The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT > never worked for non-darwin platforms and seems to be broken even the...

Alexander, Yes, a patch like that would be accepted. Fewer dependencies = good :) Some notes on doing this: (1) Please make sure you use the std c++ iostream libraries for doing I/O. No native calls (we end up with portability problems). If you need something that must be ported, please add it to lib/System (2) You should also use the sys::Path class (include/llvm/System/Path.h) for handling

...on ARM and PPC64. The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for simple examples. > > I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. The JITInfo parts can stay, they may be useful if someone wants to implement lazy compilation on top of MCJIT. It would become dead code though. > > The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT never worked for non-darwin platforms and seems to be broken even there at the mome...

...iter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on MachineCodeEmitter and the GVStub methods. Also the fact that JITEmitter is hidden and quite a large class in a .cpp file. At first I did this by introducing a JITCodeEmitter class between MachineCodeEmitter and the (un)hidden JITEmitter. But this lead to more dependancies an...

On May 16, Chris Lattner wrote: > On Mon, 16 May 2005, Alexander Friedman wrote: > > Would it be possible (ie, relatively straitforward) to do the > > following: Take the code in module A, compile it with the JIT (since > > we cannot make libraries in Windows), and save the resulting binary > > goo in some file. Later (in a different instance of the runtime), with >

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

...the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out to be a semicomplex > modification because of the JITInfo classes dependance on > MachineCodeEmitter and the GVStub methods. Also the fact that > JITEmitter is hidden and quite a large class in a .cpp file. > > At first I did this by introducing a JITCodeEmitter class between > MachineCodeEmitter and the (un)hidden JITEmitter. But thi...

Evan, Here are the modifications you asked for. I have, for the most part, not changed intptr_t to uintptr_t inside the JITInfo classes, because the pointer arithmetic there can sometimes legitimately yield negative numbers. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, November 25, 200...

...etMachine(const Target &T, StringRef TT, "E-p:32:32:32-i8:8:32-i16:16:32-i64:64:64-n32-S64")), InstrInfo(MipsInstrInfo::create(*this)), FrameLowering(MipsFrameLowering::create(*this, Subtarget)), - TLInfo(MipsTargetLowering::create(*this)), TSInfo(*this), JITInfo() { + TLInfo(MipsTargetLowering::create(*this)), + TSInfo(*this), JITInfo() { +} + + +void MipsTargetMachine::setHelperClassesMips16() { + InstrInfoSE.swap(InstrInfo); + FrameLoweringSE.swap(FrameLowering); + TLInfoSE.swap(TLInfo); + if (!InstrInfo16) { + InstrInfo.reset(MipsInstrInfo:...

...evelopers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, December 5, 2008 1:08:57 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Evan, Here are the modifications you asked for. I have, for the most part, not changed intptr_t to uintptr_t inside the JITInfo classes, because the pointer arithmetic there can sometimes legitimately yield negative numbers. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, November 25, 200...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...be more than welcome to do so. > I have looked over the JIT documentation (which is a bit sparse) and > the examples. So far I am completely unclear as to what the JIT > compiler actually does with the code that is passed to it. A target runs the passes listed in the method <target>JITInfo::addPassesToJITCompile() to emit machine code. > To be more precise, does the JIT perform all of the standard llvm > optimizations on the code, or does it depend on it's client to do so > himself? Are there some examples of that? No, the JIT performs no optimizations. The method I m...

Hi List, I am in the preliminary stages of adding a JIT compiler to a sizable Scheme system (PLT Scheme). The original plan was to use GNU Lightning, but 1) it seems to be dead, and 2) LLVM has already done a huge amount of stuff that I would have had to write (poorly) from scratch. At the moment, LLVM seems to be the ideal choice for implementing the Scheme JIT, but there are problems that need