search for: gcroot_value

Displaying 6 results from an estimated 6 matches for "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. Unfortunatel...
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 > > i...
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. The...