search for: gc_relocates

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 interested in, the safepoint at the back-edge of a loop might look like: ; <label>: body %a = phi i32 [ %a.relocated,

On Oct 24, 2013, at 2:50 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: >> Hello llvm-dev! >> >> My colleages and I are currently evaluating llvm's suitability as a >> JIT compiler interfacing with a precise, relocating garbage collector. >> While we

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

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

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

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

All, This buildbot is getting lots of assertion failures in the test suite. They were probably caused by my commit: ------------------------------------------------------------------------ r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines Changed paths: M /llvm/trunk/lib/VMCore/LLVMContextImpl.h M /llvm/trunk/lib/VMCore/Type.cpp PR1210: make uniquing of struct and

On Tue, Feb 21, 2012 at 2:51 AM, Jay Foad <jay.foad at gmail.com> wrote: > All, > > This buildbot is getting lots of assertion failures in the test suite. > They were probably caused by my commit: > > ------------------------------------------------------------------------ > r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines > Changed paths: >

...er we simply deprecate the existing gcroot support and target it for complete removal a couple of releases down the road.. * What programmatic interface should we present at the IR level and where should it live? We're moving towards a CallSite like interface for statepoints, gc_relocates, and gc_results call sites. Is this the right approach? If so, should it live in the IR subtree, or Support? (Note: The current code is only about 40% migrated to the new interface.) * To support invokable calls with safepoints, we need to make the statepoint intrinsic invokabl...

...uld prefer we simply deprecate the existing gcroot support and target it for complete removal a couple of releases down the road.. >> • What programmatic interface should we present at the IR level and where should it live? We're moving towards a CallSite like interface for statepoints, gc_relocates, and gc_results call sites. Is this the right approach? If so, should it live in the IR subtree, or Support? (Note: The current code is only about 40% migrated to the new interface.) >> • To support invokable calls with safepoints, we need to make the statepoint intrinsic invokable. This...