<div dir="rtl"><div dir="ltr">The changes you are making make sense. Return valid ready-to-run function address rather than depend upon the user calling finalize is right.</div><div dir="ltr"><br></div><div dir="ltr">The issue is with scalability of the current implementation. Let's take your Kaliedoscope example (which was very helpful) as the use-case but every REPL will do the same.</div>
<div dir="ltr"><br></div><div dir="ltr">After adding a new module it and only it needs to be finalized to run the new code. But finalizeLoadedModules loops over all modules to see which one should be finalized. It's not efficient. </div>
<div dir="ltr"><br></div><div dir="ltr">I initially thought using finalizeModule would be the solution, calling it after creating a module, saving the loop.</div><div dir="ltr"><br></div><div dir="ltr">However this goes deeper and finalizeModule isn't the solution. As you say getFunctionAddress calls finalizeLoadedModules() if a symbol found. finalizeLoadedModules always loops on all modules so it's wasteful. In an extreme case, we may know that all modules are already finalized but can't prevent the needless loop on module.</div>
<div dir="ltr"><br></div><div dir="ltr">The solution would be other data structures. </div><div dir="ltr">Simplified case, instead of looping on all modules and checking module states MCJIT could have a vector of un-finalized modules and a vector of finalized modules. New modules enter the un-finalized vector and finalizeLoadedModules() loops over the un-finalized vector, finalize every module, appends them to finalized vector and clears the unfinalized vector. <br>
</div><div dir="ltr"><br></div><div dir="ltr">This is simplified since there are more ModuleStates so maybe other data structures should be used. I have not looked in depth the ModuleStates.<br><br>Regarding getFunctionAddress, runFunction() does not use it but calls the older getPointerToFunction, so either runFunction() should be changed to the newer API or we still need to manually finalize modules.<br>
<br>Yaron<br><br><br></div><div class="gmail_extra" dir="ltr"><br><br><div class="gmail_quote"><div>2013/10/18 Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi Yaron,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">What do you see as the use case for adding this? I was thinking about removing finalizeObject() from the interface -- it’s mostly there to support code that
was written when it was necessary. It was probably a misstep to introduce finalizeObject in the EE interface in the first place. It’s a case of leaking an implementation detail into the interface.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">With the current trunk implementation of MCJIT, calling getFunctionAddress will implicitly finalize the module that contains the function (as well as any other
modules that have been loaded). The idea is that the address you get back is immediately useful (which was not true of the older getPointerToFunction method).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Also note that within MCJIT calling finalizeModule has the effect of finalizing all loaded modules. In fact, I plan to update the implementation of finalizeModule
to call finalizeLoadedModules soon.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-Andy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Yaron Keren [mailto:<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, October 17, 2013 2:32 PM<br>
<b>To:</b> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>; Kaylor, Andrew<br>
<b>Subject:</b> ExecutionEngine::finalizeModule()<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Make finalizeModule() accessible for MCJIT created through ExecutionEngine.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Maybe it would make sense to expose finalizeLoadedModules() as well.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br></div></div>