search for: gcroot

...t 12:44 AM, Paul Melis >> <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: >> >> Hi, >> >> Talin wrote: >> > I'm a little confused as to the rules for the arguments to >> llvm.gcroot, >> > which says it must be a pointer alloca. I'm not sure >> whether that means it >> > must be an alloca (which is always a pointer by definition) >> or an alloca >> > *of* a pointer. >> >> I...

...00:20, Talin wrote: > On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis > <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: > > Hi, > > Talin wrote: > > I'm a little confused as to the rules for the arguments to > llvm.gcroot, > > which says it must be a pointer alloca. I'm not sure whether > that means it > > must be an alloca (which is always a pointer by definition) or > an alloca > > *of* a pointer. > > I'm pretty sure it should be "alloca of a point...

...which need to be traced. >>> >>> >> Yes. >> >> >>> The way that I handle non-pointer types is to generate an array of field >>> offsets (containing the offset of each pointer field within the struct) as >>> the metadata argument to llvm.gcroot. This meta argument is then processed >>> in my GCStrategy, where I add the stack root offset to the offsets in the >>> field offset array, which yields the stack offsets of the actual pointers in >>> the call frame. >>> >>> >> >> Did you thi...

...ented in LLVM using structs, and may contain pointer > fields which need to be traced. > > Yes. > The way that I handle non-pointer types is to generate an array of field > offsets (containing the offset of each pointer field within the struct) as > the metadata argument to llvm.gcroot. This meta argument is then processed > in my GCStrategy, where I add the stack root offset to the offsets in the > field offset array, which yields the stack offsets of the actual pointers in > the call frame. > > Did you think of the alternative of calling llvm.gcroot on pointers i...

...part of Module" since the topic has decidedly changed. This > also relates to the email "RFC: GEP as canonical form for pointer > addressing" I just sent. > > On 02/10/2014 05:25 PM, Nick Lewycky wrote: >> ... >> >> We're supposed to have the llvm.gcroots intrinsic for this purpose, >> but you note that it prevents gc roots from being in registers (they >> must be in memory somewhere, usually on the stack), and that fixing >> it is more work than is reasonable. > This is slightly off, but probably close to what I actually sa...

...mind - indeed you need some kind of static > information in such a case. The GC infrastructure in LLVM having so little > love, I think it is good if you can improve it in any ways, as well as > defining new interfaces. So the patch is OK then? All it does is change the verifier -- llvm.gcroot already has the ability to do this, its just that the verifier wouldn't allow it. > > Cheers, > Nicolas > > > On Sat, Sep 25, 2010 at 6:38 PM, Talin <viridia at gmail.com> wrote: > >> On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray < >> nicolas.geoff...

...ed. >>> This also relates to the email "RFC: GEP as canonical form for >>> pointer addressing" I just sent. >>> >>> On 02/10/2014 05:25 PM, Nick Lewycky wrote: >>>> ... >>>> >>>> We're supposed to have the llvm.gcroots intrinsic for this purpose, >>>> but you note that it prevents gc roots from being in registers >>>> (they must be in memory somewhere, usually on the stack), and that >>>> fixing it is more work than is reasonable. >>> This is slightly off, but prob...

...assumetheposition.nl>wrote: > On 04/27/10 00:20, Talin wrote: > > On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis <llvm at assumetheposition.nl>wrote: > >> Hi, >> >> Talin wrote: >> > I'm a little confused as to the rules for the arguments to llvm.gcroot, >> > which says it must be a pointer alloca. I'm not sure whether that means >> it >> > must be an alloca (which is always a pointer by definition) or an alloca >> > *of* a pointer. >> >> I'm pretty sure it should be "alloca of a pointer&qu...

Hi, Talin wrote: > I'm a little confused as to the rules for the arguments to llvm.gcroot, > which says it must be a pointer alloca. I'm not sure whether that means it > must be an alloca (which is always a pointer by definition) or an alloca > *of* a pointer. I'm pretty sure it should be "alloca of a pointer", as the first argument of llvm.gcroot has type i8...

...contain pointer >> fields which need to be traced. >> >> > Yes. > > >> The way that I handle non-pointer types is to generate an array of field >> offsets (containing the offset of each pointer field within the struct) as >> the metadata argument to llvm.gcroot. This meta argument is then processed >> in my GCStrategy, where I add the stack root offset to the offsets in the >> field offset array, which yields the stack offsets of the actual pointers in >> the call frame. >> >> > > Did you think of the alternative of cal...

I’ve been tinkering around with some llvm assembly trying out some of the GC related features. When I add a call to @llvm.gcroot, it is consistently acting like it doesn’t know what that function is. I’m just getting started so it is probably something small and simple but some googling didn’t yield much in the way of an answer. Any help is appreciated. Thanks, Todd ----------------------------------------------------...

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8** %objptr ret i8* %v } However, when I have this: define { i8*, i32 } @foo({ i8*, i...

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the stack, and would like to add this as a > GC roo...

...l "RFC: GEP as canonical form for >>>>> pointer addressing" I just sent. >>>>> >>>>> On 02/10/2014 05:25 PM, Nick Lewycky wrote: >>>>>> ... >>>>>> >>>>>> We're supposed to have the llvm.gcroots intrinsic for this >>>>>> purpose, but you note that it prevents gc roots from being in >>>>>> registers (they must be in memory somewhere, usually on the >>>>>> stack), and that fixing it is more work than is reasonable. >>>>&gt...

On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis <llvm at assumetheposition.nl>wrote: > Hi, > > Talin wrote: > > I'm a little confused as to the rules for the arguments to llvm.gcroot, > > which says it must be a pointer alloca. I'm not sure whether that means > it > > must be an alloca (which is always a pointer by definition) or an alloca > > *of* a pointer. > > I'm pretty sure it should be "alloca of a pointer", as the first argume...

...aven't been able to keep up with it lately. > I'm trying to get a very simple copying collector to work with LLVM, basically your standard semi-space collector with Cheney scan, using the included shadow stack support to track roots. I'm writing everything in C, using llvm-gcc's gcroot attribute in a test app to mark GC roots where appropriate, which seems to work fine when translating to LLVM IR (and finally an executable). Be forewarned that this attribute should be considered ‘experimental’ at best. > Implementing a GC is actually quite new to me, so perhaps that's wh...

So I understand now that calls to llvm.gcroot have to be in the first block. (Might be a good idea to mention this in the GC docs). For each local variable that is created, there are 5 possible steps. 1. Allocate the storage for the variable using alloca(). 2. Declare the variable as a root via llvm.gcroot. 3. Initialize the variabl...

I'm moving this thread to llvm-dev in the hopes of reaching a wider audience. This patch relaxes the restriction on llvm.gcroot so that it can work with non-pointer allocas. The only changes are to Verifier.cpp - it appears from my testing that llvm.gcroot always worked fine with non-pointer allocas, except that the verifier wouldn't allow it. I've used this patch to build an efficient stack crawler (an alternative...

...the caller. Value types are represented in LLVM using structs, and may contain pointer fields which need to be traced. The way that I handle non-pointer types is to generate an array of field offsets (containing the offset of each pointer field within the struct) as the metadata argument to llvm.gcroot. This meta argument is then processed in my GCStrategy, where I add the stack root offset to the offsets in the field offset array, which yields the stack offsets of the actual pointers in the call frame. It's all pretty simple really. > > Nicolas > > On Fri, Sep 24, 2010 at 7:0...

...icolas On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at apple.com> wrote: > On Sep 22, 2010, at 8:52 AM, Talin wrote: > > I'm moving this thread to llvm-dev in the hopes of reaching a wider > audience. > > > > This patch relaxes the restriction on llvm.gcroot so that it can work > with non-pointer allocas. The only changes are to Verifier.cpp - it appears > from my testing that llvm.gcroot always worked fine with non-pointer > allocas, except that the verifier wouldn't allow it. I've used this patch to > build an efficient stack craw...