search for: performcustomlow

...g custom lowering for the gcroot intrinsic. Hello Yiannis, Yes, what you describe should be possible. In your GCStrategy subclass constructor, make the following change: class MyGCStrategy : public GCStrategy { MyGCStrategy() { - InitRoots = true; + CustomRoots = true; } + + bool performCustomLowering(Function &F) { + // You can use LowerIntrinsics::InsertRootInitializers as a template. + } }; LowerIntrinsics::InsertRootInitializers is only 26 lines of code. You can find it here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/GCStrategy.cpp?annotate=123170#l174 M...

Hello all, I set: InitRoots = true; in my gc plugin as i want the roots to be initialized to the "null" value. Is there a way to define which value should be the initial one? For example, i would like to initialize my roots to -5 (tagged, null value for the GC in my runtime system) instead of 0. Ofcourse, i could do it in the frontend (storing -5 to all GC roots), but i was wondering

...scope for LLVM unless Talin makes some progress with his GC building blocks). • As you observe, your write barrier can be written in LLVM IR without the use of the llvm.gcwrite intrinsic if you so desire. Otherwise, you can perform the IR-to-IR transform to eliminate llvm.gcwrite using the performCustomLowering hook. What else is blocking you? > By the way, I think that adding a GC pointer type is an unnecessary > burden on the the back-ends, front-ends really should be able to > handle this. I don't see how these points mesh together into a single concern, but I can address you...

...omSafePoints || NeededSafePoints != 0; + } /// needsSafePoint(Kind) - True if the given kind of safe point is // required. By default, none are recorded. @@ -109,6 +114,11 @@ /// can generate a stack map. If true, then // performCustomLowering must delete them. bool customRoots() const { return CustomRoots; } + + /// customSafePoints - By default, the GC analysis will find safe + /// points according to NeededSafePoints. If true, + /// then findCustomSafePoints must create them. +...

Gordon Henriksen wrote: > > The "runtime interface" is a historical artifact. LLVM does not impose > a runtime library on its users. I wouldn't have a problem deleting all > mention of it, since LLVM does not impose a contract on the runtime. > Excellent, I found it somewhat unhelpful! >> The semantics of llvm.gcroot are vague: >> "At

...vm then most of my objections to the intrinsics disappear. > • As you observe, your write barrier can be written in LLVM IR without > the use of the llvm.gcwrite intrinsic if you so desire. Otherwise, you > can perform the IR-to-IR transform to eliminate llvm.gcwrite using the > performCustomLowering hook. > > What else is blocking you? > Nothing, except the lack of stack traversal code ;) Once the portable stack-traversal code is available, I'll port my GC, as promised. Thanks for taking the time to discuss this. You've just about convinced me that the intrinsics sh...

...e @llvm.gcread and @llvm.gcwrite intrinsics (not to be confused with the above functions), they will be transparently converted to simple loads and stores, so there's “no cost” to using them. As the implementation matures, an llc plugin can trivially substitute a write barrier using the performCustomLowering hook: http://llvm.org/docs/GarbageCollection.html#custom This gives quite detailed control. The plugin could inline just a "hot" codepath on a barrier and keep a cold one out of line, for instance. (Note: Near-future plan is to use IR-to-selection-DAG lowering rather than I...

On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: > On 2008-04-27, at 21:29, Lane Schwartz wrote: > > Since this is a simple copying collector, the functions llvm_gc_read > > and llvm_gc_write won't really do much: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > > *FieldPtr; } > > void llvm_gc_write(void *V, void *ObjPtr, void