<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Nov 8, 2013, at 1:13 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo <span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank" class="cremed">fpizlo@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1xj" style="overflow:hidden">NEW PROPOSAL<br>
<br>
The solution is to introduce meta-data that is explicit about how the safe-to-execute condition ought to be evaluated. Instead of an SSA use, we can have meta-data that says:<br>
<br>
%v = load %p !notrap !{ @f, <args> }<br>
<br>
where @f is a function in the current module and this function returns i1, and <args> is zero or more arguments to pass to @f. As with any meta-data, this doesn’t imply anything different if you wanted to just execute the code: executing the load doesn’t imply calling @f; indeed if you dropped the meta-data the execution of this would still be the same.</div>
</blockquote></div></div><br><div>So, first a clarifying question:</div><div><br></div><div>Is the expectation that to utilize this metadata an optimization pass would have to inspect the body of @f and reason about its behavior given <args>?</div></div></div></blockquote><div><br></div><div>Yes. </div><br><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>If so, then I think this is pretty bad. If we ever want to parallelize function passes, then they can't inspect the innards of other functions. </div></div></div></blockquote><div><br></div><div>I must be missing something. Can't you do some simple locking? Lock a function if it's being transformed, or if you want to inspect it...</div><br><blockquote type="cite"><div><div dir="ltr"><div>So this would significantly constrain the utility here.</div></div></div></blockquote><div><br></div><div>I think we can engineer around this problem. For example, the function @f is meant to contain basically hand-written IR; it ought not be necessary to optimize it in order to make use of it for safe-to-execute. It's also reasonable to expect these to be small. </div><div><br></div><div>Hence you can imagine freezing a copy of those functions that are used in this meta-data. </div><br><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>Also, this would create uses of the arguments that were "ephemeral" uses. </div></div></div></blockquote><div><br></div><div>I think they're ephemeral in a very different sense than the previous !notrap; for example here the used continue to be meaningful even after replaceAllUsesWith. </div><br><blockquote type="cite"><div><div dir="ltr"><div>It's not clear how that is better than any of the other proposals to represent constraint systems in the IR via "ephemeral" uses.</div>
</div>
</div></blockquote></body></html>