search for: ghostlinkage

...he EE does not automatically update the EE. You should be able to add the Function to the Module at any time, then call EE->runFunction or EE->getPointerToFunction on it. materializeFunction is used to load only part of a .bc file from disk. The functions which aren't loaded are given GhostLinkage then loaded later (materialized) when needed. Nick

I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. What is the preferred way to inject a llvm:Function which contains basic blocks into the Module + JIT? My understanding (perhaps

...haps I'm missing something, but can't you accomplish this by using > external constants in the source program, to be supplied at JIT/link > time? > If the JIT could make a callback to dynamically resolve the type, that's the idea (I'm thinking, if a field can have a GhostLinkage, can the compiler generate a callback? In this case I don't need a new intrinsic). > Or, quite similarly, accessor functions also to be supplied by the JIT/ > linker: > You lose performance here, because you have to call the accessor function each time you call the xPlusY functio...

Nicholas, I guess you're trying to solve the fragile base-class problem by deferring field offset calculations until JIT compilation time? Perhaps I'm missing something, but can't you accomplish this by using external constants in the source program, to be supplied at JIT/link time? external constant i32 @obj.x.offs; external constant i32 @obj.y.offs; define

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" <evan.cheng at apple.com> wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>>

Hi everyone, I would like to implement an equivalent mechanism of function callbacks in the JIT, but for fields. Typically in Java, when you compile a method, there may be some instructions (getfield, putfield) that depend on a type which is not yet resolved. I think the best way to do this in LLVM is to add an intrinsic. The intrinsic would be only valid if we jit, and would be lowered only in

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached