On Wed, Jul 6, 2011 at 3:51 PM, Kenneth Uildriks <span dir="ltr"><<a href="mailto:kennethuil@gmail.com">kennethuil@gmail.com</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;">

<div class="im">On Wed, Jul 6, 2011 at 5:24 PM, Talin <<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>> wrote:<br>
<br>
> One approach would be to extend the current scheme to work with SSA values,<br>
> possibly using a new intrinsic. This is somewhat problematic because you<br>
> can't really have a 'do-nothing' function on SSA values - the result of the<br>
> function is always going to be a copy of the value, not the original value<br>
> that was passed in.<br>
<br>
</div>That doesn't seem like a huge problem.  In the common case, the<br>
"marked" SSA value and the "unmarked" original wouldn't be live<br>
simultaneously.  Uses of the unmarked version reachable from the mark<br>
intrinsic can either be treated as a separate value or just left<br>
undefined.<br>
<br>
It makes sense to also add an "unmark" intrinsic to define when the<br>
SSA stack root goes out of scope<br>
</blockquote></div><div><br></div>That's an interesting suggestion.<div><br></div><div>I realized, however, that there's another advantage to using type-based marking rather than an intrinsic - it allows you to declare function parameters as stack roots. Depending on the calling convention, some of the parameters to a function will be located on the stack while others will be passed in registers. The ones already in memory ought to be able to be traced right where they are, but unfortunately there's no way to mark them as roots with the intrinsic method - which means that the frontend has to copy the parameters into an alloca and then mark that as a root.</div>

<div><br>-- <br>-- Talin<br>
</div>