similar to: [LLVMdev] [PATCH] Add a GCModuleInfo field to MachineFunction

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that

Hi, I have the solution to my problem :). And the llvm gc infrastructure can work with the current MCJIT without any change (good news). I will explain what I have done to find the garbage collector metadata generated by llvm with MCJIT, I'm pretty sure that it could help someone. And it's very easy. You just have to activate a static gcprinter for the assembly. A very good example is

Hi all, In order to support linking AsmWriter separately from CodeGen, the Collector class (a CodeGen component) had to be decoupled from the AsmWriter interface. This required moving the beginAssembly and endAssembly methods to a separate abstract base class. If you had overridden these methods, your class may compile successfully but fail at runtime with a message of the form:

hi I followed the instructions to compile vmkit step by step. it worked until "Compile into a dynamic library the core Java libs". After "make ENABLE_OPTIMIZED=1", I didn't go get coffee because of these errors: llc -relocation-model=pic -disable-fp-elim glibj-optimized.zip.bc -o glibj.zip.s unsupported GC: vmkit UNREACHABLE executed! 0 llc 0x0000000000e40e4f 1

Hi Chris, Gordon, Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points. I'm not sure who maintains the GC code today in LLVM (I'd be happy to take ownership, if needed). The patch just adds up a custom safepoints flag, similar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as

Hello Philip, it seems like r226311 [1] introduced a bug which causes finishAssembly() to be called multiple times, even if there is only one strategy. For each function, GCModuleInfo::getFunctionInfo() adds the strategy to the StrategyList instance variable. AsmPrinter::doFinalization() calls finishAssembly() for each strategy in this list. -Manuel [1] http://reviews.llvm.org/rL226311

Yiannis, - /// clear - Resets the pass. The metadata deleter pass calls this. + /// clear - Resets the pass. The metadata printer pass calls this. I would propose different text here: /// clear - Resets the pass. Any pass, which uses GCModuleInfo(), should call it in doFinalization(). Does it make sense? -Dmitry On Wed, Feb 27, 2013 at 7:21 PM, Yiannis Tsiouris <gtsiour at

Yiannis, Pedro, I'm not an expert here. Taking closer look I see that it makes sense to do this cleanup job in doFinalization() of the pass, which requested GC info. So the current fix seems to be ok and all external clients will need to do cleanup directly doing the same jobs as Printer::doFinalization() does now. By the way, I've just noticed that comments for GCModuleInfo::clear()

Hi , Can someone commit the attatched (cleanup) patch for r175528? Thanks, yiannis On 02/25/2013 08:11 PM, Dmitry Babokin wrote: > Yiannis, Pedro, > > I'm not an expert here. Taking closer look I see that it makes sense > to do this cleanup job in doFinalization() of the pass, which > requested GC info. So the current fix seems to be ok and all external > clients will

Thanks for the review Gordon. On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com>wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it > wants to insert safe points. I'm not sure who maintains the GC code today > in LLVM (I'd be happy to take ownership, if

On Nov 1, 2011, at 4:47 AM, Nicolas Geoffray <nicolas.geoffray at gmail.com> wrote: > Thanks for the review Gordon. > > On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points.

> On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: Greg Clayton [mailto:gclayton at apple.com] >> Sent: Thursday, November 17, 2016 5:01 PM >> To: David Blaikie >> Cc: llvm-dev at lists.llvm.org; Robinson, Paul; Eric Christopher; Adrian >> Prantl >> Subject: Re:

> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called.

Hi all, I am trying to build VMKit on Linux/x86 and I got error messages like below, llvm[1]: Linking Debug+Asserts executable vmjc /root/llvm/vmkit/tools/vmjc/Debug+Asserts/vmjc.o: In function `mvm::SpinLock::acquire()': /root/llvm/vmkit/include/mvm/Threads/Locks.h:164: undefined reference to `__sync_val_compare_and_swap_4' /root/llvm/vmkit/include/mvm/Threads/Locks.h:168: undefined

On Tue, Jun 23, 2009 at 4:18 AM, Gordon Henriksen <gordonhenriksen at me.com>wrote: > Hi Jeffrey, > On 2009-06-22, at 01:49, Jeffrey Yasskin wrote: > > I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's > safe point support looks like a good way to get code into all the right > places. However, >