search for: gc_common

On Thu, Jul 14, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi llvm-dev! > > I have attached the current state of my GSoC work in patches [1] for > review; this currently allows LLVM to correctly handle functions running > out of stack space and variable sized stack objects. > > Firstly, since I think it is better to get things merged in

...riables of that frame. The lanuguage specific runtime would then use this base address, along with the generated stack maps, to access all of the stack roots for that frame. An example of how this stack walking is done can be seen here: http://code.google.com/p/tart/source/browse/trunk/runtime/lib/gc_common.cpp#155However, this code only works on x86 - the intrinsics that I envision would work on a much wider set of backend targets. Note that these items are just a tiny part of a complete collector, however, the design of LLVM is that each language is supposed to implement its own collector, and LLVM...

...gt; The lanuguage specific runtime would then use this base address, along with > the generated stack maps, to access all of the stack roots for that frame. > > An example of how this stack walking is done can be seen here: > http://code.google.com/p/tart/source/browse/trunk/runtime/lib/gc_common.cpp#155However, this code only works on x86 - the intrinsics that I envision would > work on a much wider set of backend targets. > > Note that these items are just a tiny part of a complete collector, > however, the design of LLVM is that each language is supposed to implement > its...

...e specific runtime would then use this base address, along with >> the generated stack maps, to access all of the stack roots for that frame. >> >> An example of how this stack walking is done can be seen here: >> http://code.google.com/p/tart/source/browse/trunk/runtime/lib/gc_common.cpp#155However, this code only works on x86 - the intrinsics that I envision would >> work on a much wider set of backend targets. >> >> Note that these items are just a tiny part of a complete collector, >> however, the design of LLVM is that each language is supposed to im...

Hi, I'm currently working for the next 6 months, but I would be very interested in looking into this. Are there any discussions in this mailing list that would be useful in finding out more information? Regards Michael Thorpe Internet Services Developer Netcraft Ltd -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Yiannis

...me would then use this base address, along with >>> the generated stack maps, to access all of the stack roots for that frame. >>> >>> An example of how this stack walking is done can be seen here: >>> http://code.google.com/p/tart/source/browse/trunk/runtime/lib/gc_common.cpp#155However, this code only works on x86 - the intrinsics that I envision would >>> work on a much wider set of backend targets. >>> >>> Note that these items are just a tiny part of a complete collector, >>> however, the design of LLVM is that each language i...

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been

On 4/6/12 2:21 AM, Talin wrote: > I would really like to see someone work on LLVM's garbage collection > support - it hasn't been updated in 4 years, and while there's been a > lot of talk about ways that it could be improved, there's been no action. That is *sooo* true! :-) I'm one of the authors of an LLVM backend for Erlang (ErLLVM [1]); we have tested and