<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div>Thank you both for the feedback - this is very illuminating.</div><div>I am using my own custom JIT class based on what I learned from the Kaleidoscope demo.<br></div><div>I will follow your advice and follow up with questions if I have any.<br></div><div><br></div><div><br></div><div>This is what my JIT class looks like followed by the constructor:</div><div><a href="https://github.com/clasp-developers/clasp/blob/dev/include/clasp/llvmo/llvmoExpose.h#L4189">https://github.com/clasp-developers/clasp/blob/dev/include/clasp/llvmo/llvmoExpose.h#L4189</a><br></div><div><br></div><div><div><font face="monospace, monospace">ClaspJIT_O::ClaspJIT_O() : TM(EngineBuilder().selectTarget()),</font></div><div><font face="monospace, monospace">                           DL(TM->createDataLayout()),</font></div><div><font face="monospace, monospace">                           ObjectLayer([]() { return std::make_shared<ClaspSectionMemoryManager>(); },</font></div><div><font face="monospace, monospace">                                       [this](llvm::orc::RTDyldObjectLinkingLayer::ObjHandleT H,</font></div><div><font face="monospace, monospace">                                              const RTDyldObjectLinkingLayerBase::ObjectPtr& Obj,</font></div><div><font face="monospace, monospace">                                              const RuntimeDyld::LoadedObjectInfo &Info) {</font></div><div><font face="monospace, monospace">                                         this->GDBEventListener->NotifyObjectEmitted(*(Obj->getBinary()), Info);</font></div><div><font face="monospace, monospace">                                         save_symbol_info(*(Obj->getBinary()), Info);</font></div><div><font face="monospace, monospace">                                       }),</font></div><div><font face="monospace, monospace">                           CompileLayer(ObjectLayer, SimpleCompiler(*TM)),</font></div><div><font face="monospace, monospace">                           OptimizeLayer(CompileLayer,</font></div><div><font face="monospace, monospace">                                         [this](std::shared_ptr<Module> M) {</font></div><div><font face="monospace, monospace">                                           return optimizeModule(std::move(M));</font></div><div><font face="monospace, monospace">                                         }),</font></div><div><font face="monospace, monospace">                           GDBEventListener(JITEventListener::createGDBRegistrationListener()),</font></div><div><font face="monospace, monospace">                           ModuleHandles(_Nil<core::T_O>())</font></div><div><font face="monospace, monospace">{</font></div><div><font face="monospace, monospace">  llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr);</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 6:25 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Christian, Stefan,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">(1) How do I take ownership of the ObjectFile once the ORC JIT has created it?<br>    I'd like to take ownership of object files generated by the ORC JIT so that I can save them to disk and in later sessions reload them.</blockquote><div><br></div><div>It depends on whether you are writing a custom JIT class or using LLJIT.</div><div><br></div><div>If you are writing a custom JIT class: At the moment the best way to do this is with an ObjectCache attached to your IR compiler (see llvm/ExecutionEngine/Orc/CompileUtils.h). This makes it easy to build an association between an IR input file and a compiled object file. In the future I plan to add an additional notification callback to RTDyldObjectLinkingLayer which can be used to transfer ownership of loaded objects back to the client.</div><div><br></div><div>If you are using LLJIT: There is no way to do this yet, but I plan to add support for ObjectCaches. Let me know if you are using LLJIT and I can do this straight away (it is an easy change). </div><div><br></div><div>(2) How would I pass an ObjectFile saved in question#1 back to ORC so that it will relocate it and generate function pointers?</div><div><br></div><div>You can add an object file directly to the RTDyldObjectLinkingLayer of your JIT class using that class's add method.</div><div><br></div><div>If you are using an ObjectCache with LLJIT (once that is supported), and assuming the ObjectCache implements the getObject method, then the object will be loaded automatically when you attempt to compile the source IR for that object. If you wish to use the ObjectCache to save the object only and manage the caching outside the ObjectCache then you can use LLJIT::addObject to add the saved object.</div><div><br></div><div>(3) How do I get access to the relocated ObjectFile sections?</div><div>(4) For the "__llvm_stackmaps" section - will I need to do any relocation to obtain the function pointers?</div></div><div><br></div><div>Looks like you already figured this one out. :)</div><div><br></div><div>To confirm: You will want to call the base class finalizeMemory method. You can do that before or after running your code: finalizeMemory will not change section contents, but will generally apply memory protections. Since this is a data section it should remain readable either way.</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2):<br>/// Sending relocatable objects to the server (rather than fully relocated<br>/// bits) allows JIT'd code to be cached on the server side and re-used in<br>/// subsequent JIT sessions.</blockquote></div><div><br></div><div> Actually I want to kill off the RemoteObjectLayer (at least as it is currently implemented). There are better solutions to the Remote JITing problem in the new API. :)</div><div><br></div><div>-- Lang.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 12:19 PM Stefan Gränitz <<a href="mailto:stefan.graenitz@gmail.com" target="_blank">stefan.graenitz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    Hi Christian<br>
    <br>
    Your use case seems to have similar requirements as remote JITing in
    ORC. So far I haven't used that part myself and I am sure Lang can
    tell you much more about it. However, this comment on the
    RemoteObjectClientLayer class sounds promising for your questions
    (1) and (2):<br>
    <br>
    /// Sending relocatable objects to the server (rather than fully
    relocated<br>
    /// bits) allows JIT'd code to be cached on the server side and
    re-used in<br>
    /// subsequent JIT sessions.<br>
    <br>
    There are a few tests here that illustrate its usage:<br>
<a class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://github.com/llvm-mirror/llvm/blob/master/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp" target="_blank">https://github.com/llvm-mirror/llvm/blob/master/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp</a><br>
    <br>
    Note that it still uses LegacyJITSymbolResolver, so I guess it may
    change any time soon.<br>
    <br>
    Hope it helps for the time being.<br>
    Cheers, Stefan<br>
    <br>
    <div class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-cite-prefix">Am 05.11.18 um 19:44 schrieb Christian
      Schafmeister via llvm-dev:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">I think I found the answer to #3 and #4.
        <div>(a) I overloaded the
          SectionMemoryManager::finalizeMemory(...) method. </div>
        <div>(b) I first call the base classes method (maybe not
          necessary).</div>
        <div>(c) At this point the __llvm_stackmaps section that I saved
          in thread local memory when allocateDataSection was called
          appears to be fully set up and relocated.</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Mon, Nov 5, 2018 at 12:36 PM Christian
          Schafmeister <<a href="mailto:meister@temple.edu" target="_blank">meister@temple.edu</a>> wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">
            <div dir="ltr">
              <div>I have a few questions about the new ORC JIT.</div>
              <div><br>
              </div>
              <div>I saw Lang Hames (hi!) excellent talk at the llvm-dev
                meeting a few weeks ago. The ORC JIT is undergoing some
                API changes and I'd like/need to take advantage of them.</div>
              <div><br>
              </div>
              <div>(1) How do I take ownership of the ObjectFile once
                the ORC JIT has created it?</div>
              <div>    I'd like to take ownership of object files
                generated by the ORC JIT so that I can save them to disk
                and in later sessions reload them.</div>
              <div>(2) How would I pass an ObjectFile saved in
                question#1 back to ORC so that it will relocate it and
                generate function pointers?</div>
              <div>(3) How do I get access to the relocated ObjectFile
                sections?</div>
              <div>    Currently I subclass SectionMemoryManager and
                implement allocateDataSection(...)</div>
              <div>    I can get the memory for the "__llvm_stackmaps"
                section - but I don't know when/if the contents have
                been fully set up with relocated function pointers.</div>
              <div>(4) For the "__llvm_stackmaps" section - will I need
                to do any relocation to obtain the function pointers?</div>
              <div><br>
              </div>
              <div>Background:</div>
              <div>I'm using llvm.experimental.stackmaps to register one
                variable in each stack frame that contains spilled
                register arguments.</div>
              <div>I've figured out how to get access to the stackmaps
                for code that I load into my system from dynamic
                libraries that our compiler generates.</div>
              <div>The answers to questions above will help me get
                access to the stackmaps from ORC JITted code.</div>
              <div><br>
              </div>
              -- <br>
              <div dir="ltr" class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380m_5097034966196357672gmail_signature">
                <div dir="ltr">
                  <div style="font-size:small">Christian Schafmeister</div>
                  <div style="font-size:small">Professor, Chemistry
                    Department</div>
                  <div style="font-size:small">Temple University</div>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380gmail_signature">
        <div dir="ltr">
          <div style="font-size:small">Christian Schafmeister</div>
          <div style="font-size:small">Professor, Chemistry Department</div>
          <div style="font-size:small">Temple University</div>
        </div>
      </div>
      <br>
      <fieldset class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380mimeAttachmentHeader"></fieldset>
      <br>
      <pre>_______________________________________________
LLVM Developers mailing list
<a class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-signature" cols="72">-- 
<a class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/" target="_blank">https://weliveindetail.github.io/blog/</a>
<a class="m_-6072191314669725849m_6900262629572111906gmail-m_-2708247928901434380moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com" target="_blank">https://cryptup.org/pub/stefan.graenitz@gmail.com</a></pre>
  </div>

</blockquote></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-size:small">Christian Schafmeister</div><div style="font-size:small">Professor, Chemistry Department</div><div style="font-size:small">Temple University</div></div></div>