search for: unlower

...ishing this. > Is it common practice to emit function calls that are expected to be lowered by a later pass? I know LLVM uses this kind of thing with intrinsics (llvm.gcroot, for instance), but a pass lowering calls to specific functions seems very... messy. What about something like a --emit-unlowered-llvm option on llcj that just spits out the LLVM IR before running this lowering pass? > >> * Access to stack maps at GC safe points >> >> > LLVM/VMKit already has it: VMKit uses the OCaml GC in LLVM to generate > stack maps in the executable. > > >> * Acc...

...ll (ie that will get lowered) to get the virtual table of the object and put the indirect call instruction in place (ie it will not get lowered). Or a single runtime call that will get lowered to both getting the virtual table and do the indirect call. > > What about something like a --emit-unlowered-llvm option on llcj that just > spits out the LLVM IR before running this lowering pass? > Yes, that's what I had in mind. llcj is just a driver here for VMKit, the real executable is vmjc, to which you can give a number of passes, including your pass that will lower your virtual call....

On Tue, Jul 20, 2010 at 5:35 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > Hi Nicolas, > > I plan on using the Avian GC (which is a precise, generational collector). > OK - Great! > Eventually, I'd like to fully integrate all of the runtime services Avian > provides - even integrating the existing Avian JIT compiler, to allow for > partially-AOT

Hi Nicolas, I plan on using the Avian GC (which is a precise, generational collector). Eventually, I'd like to fully integrate all of the runtime services Avian provides - even integrating the existing Avian JIT compiler, to allow for partially-AOT builds. Avian does indeed have it's own class library, but I would be very surprised if VMKit could compile with them - they are sufficiently