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 > > implemented. > > Unfortunately this won't really work. It might be reasonable to include > something like this in the front-end that you're working on, but including > this 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. Hmm, it felt nicer to mark raw LLVM pointers as roots and then transform them, since I then didn't have to see the overhead in my frontend :). Btw, how hard would it be to implement the system described in this paper[1], support for collection at every instruction? You would need to get the gc root information with you all the way down to machine code and register allocation. Just curious :). , Tobias [1] http://portal.acm.org/citation.cfm?id=301652&dl=ACM&coll=portal
On Thu, 22 Jul 2004, Tobias Nurmiranta wrote:> > Unfortunately this won't really work. It might be reasonable to include > > something like this in the front-end that you're working on, but including > > this 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 problem is that the pass subtly changes the semantics of the LLVM instruction, which is a bad thing for many reasons. What the pass really does is create a dialect of LLVM, one which is easier for you to produce in your front-end, and that is easily translatable to standard LLVM form.> Hmm, it felt nicer to mark raw LLVM pointers as roots and then transform > them, since I then didn't have to see the overhead in my frontend :).I'm not sure what overhead you mean. I understand that you basically have a single-assignment source language, so you don't need to deal with alloca's in the usual case, but every other front-end we have produces alloca instructions for EVERY user defined variable, regardless of whether it's a GC root. Obviously most of these get optimized away :)> Btw, how hard would it be to implement the system described in this > paper[1], support for collection at every instruction? You would need to > get the gc root information with you all the way down to machine code and > register allocation. Just curious :). > [1] http://portal.acm.org/citation.cfm?id=301652&dl=ACM&coll=portalI don't understand what the benefit of this would be. The problem is that once dynamically assigned, an SSA value cannot change its contents until it is redefined by the same definition. Tracking GC information at every instruction would not be able to address this fundamental problem. LLVM *does* have a way to represent something that can change like we want... I'm not sure why you're so afraid of it! :) :) -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
On Thu, 22 Jul 2004, Chris Lattner wrote:> On Thu, 22 Jul 2004, Tobias Nurmiranta wrote: > > Hmm, it felt nicer to mark raw LLVM pointers as roots and then transform > > them, since I then didn't have to see the overhead in my frontend :). > > I'm not sure what overhead you mean.I think I should have emphasized "felt", since it only would make me produce less code in the frontend :). But I think my transformation thing won't work, so I'll do as the other front-ends, but thanks for the feedback to my thoughts!> > Btw, how hard would it be to implement the system described in this > > paper[1], support for collection at every instruction? You would need to > > get the gc root information with you all the way down to machine code and > > register allocation. Just curious :). > > [1] http://portal.acm.org/citation.cfm?id=301652&dl=ACM&coll=portal > > I don't understand what the benefit of this would be. The problem is that > once dynamically assigned, an SSA value cannot change its contents until > it is redefined by the same definition. Tracking GC information at every > instruction would not be able to address this fundamental problem.This is regarding every machine instruction, not llvm-instruction, with the benefit that the threads don't have to fixed to gc-safe points at gc invocation. But maybe it's not worth the work. , Tobias