[llvm-commits] [llvm] r41879 - in /llvm/trunk: docs/GarbageCollection.html lib/Transforms/Scalar/LowerGC.cpp

[Chris Lattner]

> Here, the FE must emit the highlighted null initializer separate  
> from the use, declaration, and scope of o; otherwise, a GC at a  
> safepoint corresponding to call @g will likely segfault the  
> collector. Of more concern, the FE must do so before any gc points,  
> which are implementation-defined. It's that last property which  
> makes this potentially error-prone.
>
>
> But upon further musings, I'm actually convinced your new spec is  
> best. llvm.gcroot should be purely an annotation, with no runtime  
> component.

Yes, that's the real reason I felt it was best.  gcroot should only  
be a request to the code generator, not change the actual code :).

> • In the case of a liveness-accurate collector:
> The initializers are not necessary, so the collector is free to  
> omit them. The alloca has the same value as if llvm.gcroot were not  
> present.

Ok.

> • In the case of a collector without liveness:
> The null initializers are necessary, but the initializer should  
> immediately follow alloca rather than replacing call @llvm.gcroot.

Yep.  This is something the frontend can do.

>  Effectively, the initial value of the alloca becomes null if and  
> only if required by the collector. This change enables your alloca- 
> store-gcroot sequence to behave as desired.

Yep!

> Regardless of the collector, the FE should not rely on the contents  
> of an uninitialized alloca; it FE should emit initializers if that  
> is necessary for the source language. The collector should perform  
> a trivial DSE of the initial basic block to avoid obviously  
> redundant initializers; the difference is that it can do this  
> reliably, since it has knowledge of where safe points might occur.

Yep!

> I need to tweak the collector infrastructure slightly, but that's  
> okay; it's definitely a stronger spec if I comply with it in this  
> manner, since:
>
>  1. The semantics of alloca are entirely preserved by the  
> llvm.gcroot annotation.
>  2. The user program's interaction with the collector is even more  
> robust than before.

Excellent,

-Chris