similar to: (no subject)

Exactly this.  (As the person who wrote the line in question.) On 10/18/19 8:50 AM, Hiroshi Yamauchi via llvm-dev wrote: > I think it's referring to a "moving" garbage collector (as opposed to > a "non-moving" garbage collector that never moves/relocates objects.) > The difference is that for a moving one, all pointers need to be > tracked and potentially

Correct, with a couple of nit picks. Relocation isn't an optimization the collector performs.  It's a key primitive the collector is built upon.  Being unable to relocate is not an allowed state.  (i.e. pinning can't be required by the compiler) When you talk about variables, that's true for the *source* language and for the *abstract* machine before lowering.  After lowering

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, My collector supports only base pointers as stack roots. This wasn't a problem until I tried to run some optimizations before RS4GC, which introduced (interior) derived pointers. The statepoint documentation mentions that these collectors exist, but doesn't mention whether and how this is currently supported. What could I do to make it work? -Manuel

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like

Thanks, I think that's a useful way to look at it (though if I wanted to bikeshed I'd suggest the name "DoubleIndirect" as a bit more precise than "VeryIndirect"). An aspect of it that I'm still puzzling over is that my target runtime (at least in its current form) doesn't have a way to represent/process a "VeryIndirect" pointer. So I'd like to

Is there an explanation anywhere of what code that uses a stack map looks like? I'm interested in writing a garbage collector, but it's not clear to me how my code should make use of the stack map format to actually locate roots in memory. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Sanjoy Das wrote: > In your > example, foo will have to treat its argument differently depending on > whether it is a GC pointer or not. In practice, this is not true of many functions that don't call other functions. Take the example of a simple "print" function that takes a void * to cast and print, type_int to determine what to cast to: why should it care about whether

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

Hi, I implemented a garbage collector for a language I wrote in college using the llvm gc statepoint infrastructure. Information for statepoints: https://llvm.org/docs/Statepoints.html Example usage of parsing the llvm stackmap can be found at: https://github.com/dotnet/llilc/blob/master/lib/GcInfo/GcInfo.cpp https://llvm.org/docs/StackMaps.html#stackmap-format

For anyone following along on ToT using the gc.statepoint mechanism, you should know that ToT is currently not able to express arbitrary exceptional control flow and relocations along exceptional edges. This is a direct result of moving the gc.statepoint representation to using a token type landingpad. Essentially, we have a design inconsistency where we expect to be able to

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

I'm have a [PATCH] isDereferenceablePointer: look through gc.relocates and I want to know how to test this patch. So far, I've found one candiate: speculative execution in SimplifyCFG (test/Transforms/SimplifyCFG/SpeculativeExec.ll). However, it's somewhat involved to show that SimplifyCFG does kick in for gc.relocate. Is there a better way to directly test it? Signed-off-by:

Hi, So, we currently have gc.result.int, gc.result.float. gc.result.ptr, gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with a iPTRAny as the first argument. gc.result is in trouble, because none of the signatures admit even a simple array of integers, and there's no aAny. And certainly no vectors. So we can get a gc.result.vector to add to this mess, and admit [1] to

Hello, I was wondering if there is an example list somewhere of whole program optimizations done by LLVM based compilers? I'm only familiar with method-level optimizations, and I'm being told wpo can deliver many great speedups. My language is currently staticly typed JIT based and uses the JVM, and I want to move it over to LLVM so that I can have options where it can be ahead of time

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

Here's an interesting problem - is it legal to copy the _Unwind_Exception struct to a different address in memory before calling _Unwind_Resume? I'm thinking of the scenario in which a garbage collection run is triggered in the middle of a "finally" block. If it's a copying collector, it might relocate the exception object, which has the _Unwind_Exception structure embedded

For example, the illustrate part says "ES.getMainJITDylib().setGenerator" while the full code list says "ES.getMainJITDylib().addGenerator", I guess the API is changed, the tutorial part is up to date while the full code list leaves to the old version. On Thu, Sep 19, 2019 at 10:51 AM Yafei Liu <yfliu at mobvoi.com> wrote: > Yes, the function type mismatch, just copy

On Mar 6, 2011, at 11:01 AM, Talin wrote: > Here's an interesting problem - is it legal to copy the _Unwind_Exception struct to a different address in memory before calling _Unwind_Resume? > > I'm thinking of the scenario in which a garbage collection run is triggered in the middle of a "finally" block. If it's a copying collector, it might relocate the exception