llvm dev - Apr 2008 - [LLVMdev] getting started with IR needing GC

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 **FieldPtr)  
> > { *FieldPtr = V; }
> 
> You can just emit loads and stores directly if your read/write  
> barriers do nothing. Also, there's nothing special about the  
> llvm_gc_read or llvm_gc_write functions any more; they will not be  
> called unless you call them yourself.
Gordon:

Since GC strategies change as implementations mature, is there a way to
go ahead and emit these calls, but then in a simple implementation
indicate somewhere that they should be trivially inlined? This would
allow us to debug things without imposing performance penalties on the
simple implementation.

Actually, I can see wanting to inline these even in barrier-oriented GC
implementations...

shap

On Apr 28, 2008, at 10:50, Jonathan S. Shapiro wrote:
> 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 **FieldPtr)  
>>> { *FieldPtr = V; }
>>
>> You can just emit loads and stores directly if your read/write  
>> barriers do nothing. Also, there's nothing special about the  
>> llvm_gc_read or llvm_gc_write functions any more; they will not be  
>> called unless you call them yourself.
Here, I was making two points. First and foremost, the user symbols  
llvm_gc_read and llvm_gc_write are not special any more, so Lane  
shouldn't bother with them. :)

Secondly, it's not strictly necessary to use the barrier intrinsics,  
which is the point you're addressing.
> Gordon:
>
> Since GC strategies change as implementations mature, is there a way  
> to go ahead and emit these calls, but then in a simple  
> implementation indicate somewhere that they should be trivially  
> inlined? This would allow us to debug things without imposing  
> performance penalties on the simple implementation.
>
> Actually, I can see wanting to inline these even in barrier-oriented  
> GC implementations...

Indeed so! If you do use the @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 IR-to-IR for this hook, if you're working in this  
area.)

However, GC lowering happens just before code generation, after any IR  
optimizations; thus, the use of the intrinsics can inhibit IR analysis  
and optimization. Even ignoring that the intrinsics are opaque to most  
optimizations, the read barrier can't even be marked readonly.  
Therefore, the most optimal output is probably be achieved by  
propagating knowledge about the GC model into the front-end, emitting  
simple loads and stores when allowed by the GC.

Chris has observed that read and write barriers lowering could equally  
well be implemented by the front-end with no special compiler support.  
The only significant value these these intrinsics add is if they are  
transparent to optimizations—e.g., if @llvm.gcreads of the same SSA  
value are coalesced even though @llvm.gcread can have side effects.  
This is an area for future work.

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080428/4870e62f/attachment.html>

On Mon, 2008-04-28 at 12:28 -0400, Gordon Henriksen wrote:
> However, GC lowering happens just before code generation... Therefore,
> the most optimal output is probably be achieved by propagating
> knowledge about the GC model into the front-end, emitting simple loads
> and stores when allowed by the GC.
Given the current infrastructure, I concur, but the appropriate
selection of GC is target and application dependent, so one does not
want to bind this decision too tightly. Embedding knowledge in the front
end is a very tight binding indeed.

It isn't an immediate problem for us, and one fine solution would be for
us to move the lowering into the front end down the road as Chris has
suggested. I asked mainly because if there was a way to dodge the
premature decision binding problem up front, it seemed worthwhile to do
so.


shap