<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Talin,<div> how about having the front-end generate an llvm.safe.point() intrinsic call at</div><div>the desired safe points, and having the addresses of the GC roots (at that point,</div><div>can vary from call to call) be the parameters (with noescape attribute) to the intrinsic,</div><div><br></div><div>IIUC currently the GC roots are tagged, and all analysis and transform optimizations</div><div>have to special case these tagged objects, but if instead their addresses were taken at</div><div>the safe points no special casing would have to be done -- all analysis and transform</div><div>optimizations already know how to deal with objects whose address is taken,</div><div><br></div><div>and since llvm does already have a "noescape" (not sure that's the correct name?)</div><div>attribute for parameters, these addresses won't be misinterpreted by any alias</div><div>analysis either, and llvm is free to go ahead and keep these values in registers</div><div>between safe points -- you can stop asking how to allow GC roots as SSA values,</div><div>any traditional load-store optimization pass will do it for you for free.</div><div><br></div><div>*** without you having to insert explicit load and store instructions, and having to</div><div>somehow mark them as non-delete-able, or always omit optimization passes that</div><div>you would otherwise like to have enabled ***</div><div><br></div><div>and also without you having to store NULL into a safe point to end its lifetime.</div><div>and I would suggest eliminating the gcroot() intrinsic as it's information content</div><div>would be redundant.</div><div><br></div><div><br></div><div>thoughts, comments ???</div><div><br></div><div><br></div><div>-Peter Lawrence.</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Jul 18, 2011, at 10:53 PM, Talin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Jul 18, 2011 at 11:00 AM, Peter Lawrence <span dir="ltr"><<a href="mailto:peterl95124@sbcglobal.net">peterl95124@sbcglobal.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Talin,<br> do you identify safe-points in the current or proposed llvm scheme, and if so how,<br> or are they implicit as being at all call sites (which begs the question what about leaves<br> in the call tree, how does GC get started at all in that case).<br><font color="#888888"> <br></font></blockquote><div>The LLVM linker has a feature where you can specify what kind of safe points your collector requires - the options are Loop, Return, PreCall and PostCall. You can also override this behavior and examine each instruction and return a boolean indicating whether it is or isn't a safe point.</div> <div><br></div><div>Currently I only have function calls as safe points, although I may eventually enable loops as well. As far as leaf functions go, consider that the call to allocate memory is also a safe point - and if a function doesn't allocate any memory then we don't care if the GC is involved or not.</div> <div><br></div><div>One complication with the current scheme is that the frontend has to have a sense of where the safe points are going to be. Because the current scheme requires the frontend to insert additional loads and stores around safe points (for spilling register values to memory so they can be traced), the frontend has to be able to guess which function call might be a safe point - but it can't know for sure due to the fact that optimization and inlining (which happens much later) may cause the removal of the actual call instruction. The safe but inefficient approach is to insert the extra loads and stores around every call instruction.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"> Peter Lawrence.<br> </font></blockquote></div><br>-- <br>-- Talin<br></blockquote></div><br></div></body></html>