Displaying 6 results from an estimated 6 matches for "gcroot_valu".
Did you mean:
gcroot_value
2004 Jul 22
0
[LLVMdev] GC questions.
...nt to the llvmbugs list, but this subject
has some design discussion, so it's ok for it to be on llvmdev :)
> While I was editing LowerGC.cpp I made a little test (not part of this
> patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
> intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
> directly instead and transforms it into an alloca. The idea is the
...
> In this way, the frontends don't have to explictly alloca the gcroots,
> but instead just use the intrinsic, which hides how the gcroots are
> implemented.
Unfortunate...
2004 Jul 22
2
[LLVMdev] GC questions.
On Thu, 22 Jul 2004, Chris Lattner wrote:
> > While I was editing LowerGC.cpp I made a little test (not part of this
> > patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
> > intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
> > directly instead and transforms it into an alloca. The idea is the
> ...
> > In this way, the frontends don't have to explictly alloca the gcroots,
> > but instead just use the intrinsic, which hides how the gcroots are
> >...
2004 Jul 22
2
[LLVMdev] GC questions.
Ok, here's the new patch. (Please tell me if I shouldn't mail patches
directly on the mailing list.)
While I was editing LowerGC.cpp I made a little test (not part of this
patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
directly instead and transforms it into an alloca. The idea is the
following,
this:
%X = call sbyte* %llvm_gc_allocate(uint 16)
call void %llvm.gcroot_value(sbyte* %X, sbyte* null)
is transformed into:
%stackGcRoot = alloca sbyte*
%X = call sbyte*...
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > > return *FieldPtr;
> > > }
> >
> > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > cases?
>
> For the field pointer, one
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr
2004 Jul 22
0
[LLVMdev] GC questions.
...s at the LLVM level is a bad idea. The basic idea of the alloca model
> > is that it directly exposes to the optimizer the fact that GC pointers may
> > change at unpredictable times, which is something that memory can do, but
> > SSA registers do not do.
>
> Ok. But if the gcroot_value transformation in done before any
> optimizations, I get the same result as if I had used gcroot and alloca.
> So maybe I can move it to a independent pass which I then use with my
> frontend.
Keeping it as part of your front-end is fine, but including it with the
LLVM distro is not. Th...