<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 8:44 AM, 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 class="im"><blockquote type="cite"><div><div dir="ltr"><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><div>Yes. </div><div class="im"><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>
<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></blockquote><div><br></div><div>I really, *really* don't like this.</div>
<div><br></div><div>I do *not* want parallelizing LLVM to require careful locking protocols to be followed. Instead, I want the design to naturally arrange for different threads to operate on different constructs and for the interconnecting interfaces to be thread safe. The best system we have yet devised for this is based around function passes not digging into tho bodies of other functions. Instead we rely on attributes to propagate information about the body of another function to a caller.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><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><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><div class="im"></div></blockquote></div><br>At this point, you are essentially proposing that these functions are a similar but not quite the same IR... They will have the same concepts but subtly different constraints or "expectations".</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'm not yet sure how I feel about this. It could work really well, or it could end up looking a lot like ConstantExpr and being a pain for us going forward. I'm going to keep thinking about this though and see if I can contribute a more positive comment. =]</div>
</div>