<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 11:57 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":4bz">   At build time the user may say I know this, this and this. Those get compiled in. They then use the built thing for a while and are free to set at runtime any of the other many options that were not compiled in.<br>
</div></blockquote><div><br></div><div style>How would they specify what they want to use? Hopefully using the options database.</div><div style><br></div><div style>Inlining could then be thought of as an extreme case of profile-guided optimization, in the sense that you run an instrumented instance of the code to determine which decisions have been made, then recompile (mostly just fusing the right things) and </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":4bz">
<div class="im"><br>
> Or are you just JITing and caching the result of the JIT pass in a "library" that you'll keep around for a while (maybe several separate runs) before it gets gc'd?<br>
<br>
</div>  So yes it is JIT like, if you will. The point is that conceptually "JIT" is/can be a spectrum of possibilities and should be treated that way. Developers shouldn't need a different process or mindset because it is "JIT" or not.</div>
</blockquote></div><br>You're going to have to annotate/teach/declare what should be jitted. My JIT-based suggestion is mostly about using a special mechanism for assigning and calling those chaseable pointers, so that they could be resolved later using the JIT.</div>
</div>