> 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 _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
