similar to: [LLVMdev] Future plans for GC in LLVM

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

I'm moving this to a different thread. I think the newly proposed intrinsic definitions and their current implementation are valuable regardless of how it gets tied into GC... On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: > Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo

Hello LLVM community, We have been experimenting with using LLVM IR as a target for a managed (dynamically typed) language via an AOT compiler (including a backend for ARM). One main challenge is getting the garbage collection right: We would like to be able to implement a moving collector. This requires us to a) find a precise set of root pointers and b) be able to rewrite those pointers after

On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote: > On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > >> On 10/22/13 10:34 AM, Filip Pizlo wrote: >>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >>> >>>> On 10/17/13 10:39 PM, Andrew Trick wrote:

As I've mentioned on the mailing list a couple of times over the last few months, we've been working on an approach for supporting precise fully relocating garbage collection in LLVM. I am happy to announce that we now have a version of the code available for public view and discussion. https://github.com/AzulSystems/llvm-late-safepoint-placement

Thanks for the feedback. I think both of the suggestions are very reasonable. I’ll incorporate them. Given there were no objections for two weeks, I’m going to go ahead with posting individual patches for review. One small question inline: On Sep 28, 2020, at 10:56 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: In general, I am

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > On 10/22/13 10:34 AM, Filip Pizlo wrote: >> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >> >>> On 10/17/13 10:39 PM, Andrew Trick wrote: >>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>>> first client

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

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies

Hi Martin, Philip covered all of it very well, I'll just add one minor comment: > More generally, can I back up and ask an important question? Do you have to > support deoptimization (i.e. osr side exits) in any form? If you do, you'll > probably want to avoid the PlaceSafepoints utility pass. If you need to PlaceSafepoints is inadequate only if you have asynchronous

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects are invalidated at every > safepoint" somehow in the IR itself. So, if %a and %b are values the > GC is

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

On 10/25/13 1:10 PM, Ben Karel wrote: > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com > <mailto:sanjoy at azulsystems.com>> wrote: > > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

Thanks for the comments and for taking a look. On 06/05/2014 02:19 AM, David Chisnall wrote: > Hi Philip, > > The first thing that I notice on looking at the code is the lack of comments. For example, about the only comment that I see in include /llvm/IR/Statepoint.h is a note telling me that a class is only intended to be used on the stack. Doxygen comments and, for a feature like

On 02/24/2014 11:27 AM, Andrew Trick wrote: > > On Feb 24, 2014, at 11:17 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/24/2014 12:45 AM, Andrew Trick wrote: >>> >>> On Feb 21, 2014, at 10:37 AM, Philip Reames >>> <listmail at philipreames.com <mailto:listmail at

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

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves