Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] runtime/GC/SemiSpace/semispace.c does not build in release 2.2?"
2008 Apr 21
2
[LLVMdev] getting started with IR needing GC
On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote:
> The shadow stack walker is in the runtime directory with the semispace
> heap example. The runtime directory is built to LLVM IR using llvm-
> gcc. So it's skipped unless you configure llvm with llvm-gcc support.
doh! That's how I missed the binary. thanks!
> Since the semispace heap doesn't actually work (it's
2008 Apr 21
0
[LLVMdev] getting started with IR needing GC
Hi Terence,
On 2008-04-20, at 20:08, Terence Parr wrote:
> I've exhausted what I can do on my own to make a GC example bind
> (usual googling, reading, playing, looking at source). I can't find
> the shadow collector lib or perhaps the -l options needed to link my
> sample (not even to point where I'm figuring out GC actually as I
> can't link).
The shadow
2008 Apr 22
3
[LLVMdev] getting closer!
Ok, I *might* be getting this from the assembly code. The assembly
code has:
L_llvm_gc_root_chain$non_lazy_ptr:
.indirect_symbol _llvm_gc_root_chain
.long 0
and I see it being used in the function preamble. Is that a ref to an
extern symbol or the def? I.e., is it referring to
StackEntry *llvm_gc_root_chain;
that I must have in my GC C code? (semispace.c has it)
SO!
2008 Apr 21
0
[LLVMdev] getting started with IR needing GC
On 2008-04-20, at 21:05, Terence Parr wrote:
> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote:
>
>> Since the semispace heap doesn't actually work (it's an example, at
>> best), I suggest you simply copy the stack visitor into your
>> project; it's only a dozen lines of code or so.
>
>
> Ok, copying; can't find ShadowStackEntry though.
2008 Apr 21
2
[LLVMdev] getting started with IR needing GC
On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote:
> On 2008-04-20, at 21:05, Terence Parr wrote:
>
>> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote:
>>
>>> Since the semispace heap doesn't actually work (it's an example,
>>> at best), I suggest you simply copy the stack visitor into your
>>> project; it's only a dozen lines of
2008 Apr 22
0
[LLVMdev] getting started with IR needing GC
Hi Terence,
I think you're getting hung up on the details of the shadow stack
collector. The shadow stack is a GC that is possible within this
framework, but of course could be implemented without any special
support. Its presence is more misleading than anything else. Taking a
step back, the concepts are:
llvm.gcroot instructs the code generator --> My GC needs to be able to
2008 Apr 21
2
[LLVMdev] getting started with IR needing GC
Howdy do LLVM folks!
I've exhausted what I can do on my own to make a GC example bind
(usual googling, reading, playing, looking at source). I can't find
the shadow collector lib or perhaps the -l options needed to link my
sample (not even to point where I'm figuring out GC actually as I
can't link). Not sure this IR is correct but here is what I've been
playing
2008 Apr 28
2
[LLVMdev] getting started with IR needing GC
On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen
<gordonhenriksen at mac.com> wrote:
> As for the compiler plugin interface, I suggest you ignore it
> initially and use the provided shadow-stack option for the time being.
> The shadow stack generates significantly suboptimal code, but will let
> you avoid writing some platform-specific code. Instead, simply copy
> the
2006 Feb 27
0
[LLVMdev] Garbage collection questions
On Mon, 27 Feb 2006, Sandro Magi wrote:
> Couple of questions:
Ok, it's been a long while since I've worked on the GC stuff, but I'll try
to help :)
> 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr)
>
> I haven't seen an adequate explanation of these, but I'm guessing:
> void *V: value being written to the field
> void *ObjPtr: current value
2008 Apr 28
0
[LLVMdev] getting started with IR needing GC
On 2008-04-27, at 21:29, Lane Schwartz wrote:
> Hi guys,
Hi Lane!
This is a lot of questions. I'm not going to answer each individually,
but will instead give general guidance to help you avoid the pain
points…
> I somehow need to inform the garbage collection runtime (my
> copycollector.c) about my variables - specifically about gc roots.
> So, after I get new memory
2008 Apr 28
0
[LLVMdev] getting started with IR needing GC
On Apr 28, 2008, at 14:28, Lane Schwartz wrote:
> On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen
> <gordonhenriksen at mac.com> wrote:
>
>> As for the compiler plugin interface, I suggest you ignore it
>> initially and use the provided shadow-stack option for the time
>> being. The shadow stack generates significantly suboptimal code,
>> but will
2008 Apr 28
3
[LLVMdev] getting started with IR needing GC
On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen
<gordonhenriksen at mac.com> wrote:
>
> Hi Terence,
>
>
> I think you're getting hung up on the details of the shadow stack collector.
> The shadow stack is a GC that is possible within this framework, but of
> course could be implemented without any special support. Its presence is
> more misleading than anything
2006 Mar 14
0
[LLVMdev] Re: Garbage collection questions
On 3/14/06, Chris Lattner <sabre at nondot.org> wrote:
>
> > How exactly does this indicate X is no longer live? Is this internal
> > code-generator logic/magic?
>
> No, this just prevents the GC from accidentally thinking that *X is live
> through that pointer. The collector cannot distinguish between
> pointers that are out of scope from those that aren't,
2006 Feb 27
0
[LLVMdev] Garbage collection questions
Couple of questions:
1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr)
I haven't seen an adequate explanation of these, but I'm guessing:
void *V: value being written to the field
void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon
entry to llvm_gc_write)
void **FieldPtr: address of the field being written
2. The current semispace collector includes
2006 Feb 27
4
[LLVMdev] Garbage collection questions
Couple of questions:
1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr)
I haven't seen an adequate explanation of these, but I'm guessing:
void *V: value being written to the field
void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr
upon entry to llvm_gc_write)
void **FieldPtr: address of the field being written
2. The current semispace collector includes
2008 Apr 22
2
[LLVMdev] getting closer!
On Apr 21, 2008, at 6:23 PM, Gordon Henriksen wrote:
> On Apr 21, 2008, at 20:09, Terence Parr wrote:
>
>> Ok, I *might* be getting this from the assembly code. ... From
>> that, it will push/pop in functions? If so, that's easy enough. :)
>
> Yup! Sounds like you've got it.
Yup, what i was missing and what somebody should add to the doc is
that
2008 Apr 22
0
[LLVMdev] getting closer!
Hi again Terence,
On Apr 22, 2008, at 15:20, Terence Parr wrote:
> Sorry for the long questions...gotta figure this out.
Not a problem!
> On Apr 21, 2008, at 6:23 PM, Gordon Henriksen wrote:
>
>> On Apr 21, 2008, at 20:09, Terence Parr wrote:
>>
>>> Ok, I *might* be getting this from the assembly code. ... From
>>> that, it will push/pop in
2004 Oct 27
0
[LLVMdev] Getting started with GC
On Wed, 27 Oct 2004, Tom Brown wrote:
> On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote:
> > On Tue, 26 Oct 2004, Tom Brown wrote:
> > > $ llvm-as alloc_loop.ll
> > > $ lli alloc_loop.bc
> > > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&,
2004 Oct 27
0
[LLVMdev] Getting started with GC
On Tue, 26 Oct 2004, Tom Brown wrote:
> I'm in a group tasked with improving the GC of LLVM for a 421 project.
> We are having trouble getting started with the given SemiSpace
> collector.
>
> We found the string llvm_gc_initialize called from a single source file
> ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll
> which we tried with the following... (showing LLVM
2004 Oct 27
2
[LLVMdev] Getting started with GC
On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote:
> On Tue, 26 Oct 2004, Tom Brown wrote:
> > $ llvm-as alloc_loop.ll
> > $ lli alloc_loop.bc
> > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&, llvm::Module*): Assertion `Initializer->getType() == Ty