<div dir="ltr">Thank you for all responses. I did as suggested and everything works as I wanted to.<br><br>There is however one small performance issue I've spotted. To check if a function has been JITed and is already in memory I need to use getFunctionAddress, and it does section relocations every time (via finalizeLoadedModules()). I would like to use getSymbolAddress from MCJIT but is not accessible by ExecutionEngine interface. </div><br><div class="gmail_quote">On Sun, Jan 4, 2015 at 9:11 PM mahesh ravishankar <<a href="mailto:mahesh.ravishankar@gmail.com">mahesh.ravishankar@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My response would be similar to some of the previous replies. In my experience with MCJIT, the best way is to have one instance of the ExecutionEngine. Everytime you create a new llvm IR Module, add to the MCJIT ExectionEngine using addModule . It would be a good idea to create unique function names everytime you create a new llvm IR Module (I dont know what happens if there is a clash).<div>With respect to hashing, I would implement hashing from your high-level code to the function generated outside of the MCJIT Execution Engine. Once you get the function name from your hash function you can get the function address using getFunctionAddress.</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 10:36 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div>
    <br>
    <div>On 12/29/2014 05:23 AM, Paweł Bylica
      wrote:<br>
    </div>
    <blockquote type="cite">Hello everyone,
      <div><br>
      </div>
      <div>I need some advises about (re)using ExecutionEngine with
        MCJIT as a driver. I'm developing a service that receives a
        piece of high-level code, compiles it into LLVM IR function
        "main" and uses MCJIT to execute the function.</div>
      <div><br>
      </div>
      <div>It can happen that the same piece of code is sent to the
        service many times. I would like to cache the results (keep
        generated machine code alive) and do just the execution step.
        But I'm having problems with that.</div>
      <div><br>
      </div>
      <div>My first attempt was to cache ExecutionEngine instance and
        function address (from getFunctionAddress() method). Executing
        cached function second time crashes the process.</div>
      <div><br>
      </div>
      <div>I noticed that doing getFunctionAddress() each time helps a
        bit. There is no crash but results produced by executed function
        are incorrect and there are probably some memory access
        violations going on.</div>
      <div><br>
      </div>
      <div>Using the same function name for each code is probably a bad
        idea in case of MCJIT, so I changed the names to some random
        value. However, it did not help in any of previous problems.</div>
      <div><br>
      </div>
      <div>I thinking about using single instance of ExecutionEngine or
        share Memory Manager. Can I get any advice on that?</div>
    </blockquote></div></div>
    My suggestion would be to use a single long lived instance of EE and
    MM.  Use some hashing mechanism to map your high level requests to a
    unique key.  If you've already generated it, just reuse the existing
    code.  Otherwise, create a new module, add it to the EE, and
    compile.  <br>
    <br>
    This will cause you to "leak" memory for code that isn't being
    reused.  I don't know of a good solution to that within the
    framework of MCJIT, but you can get something reasonable by simply
    recreating your EE and MM instances every N (10000?) compiles. 
    Until you have something like that working, I won't worry about
    trying to improve the memory caching strategy.<br>
    <br>
    p.s. You can also look at using the on-disk cache capabilities.  I
    have never used that and have no idea how useful it is.  <br>
    <blockquote type="cite"><span>
      <div>Happy New Year,</div>
      <div>Paweł Bylica</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><span><pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div><div dir="ltr">Mahesh</div></div>
</div></blockquote></div>