<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><span style="background-color: rgba(255, 255, 255, 0);">Hi Riyaz,</span><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">The state of Module/Context ownership is very muddled in the codebase. As you have discovered: LLVMContext’s notionally own their modules (via raw pointers deleted upon destruction of the context), however in practice we always hold llvm Modules by unique_ptr. Since the Module destructor removes the raw pointer from the Context, this doesn’t usually blow up. It’s pretty broken though.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I would argue that you should use unique_ptr and ignore LLVMContext ownership.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">If you are feeling game, I would also recommend looking into ORCv2. The ORCv1 layers (including LegacyIRCompileLayer) are being deprecated in favor of new versions that support concurrent compilation. To make concurrent compilation safe and efficient, ORCv2 introduces a wrapper called ThreadSafeModule that owns a pair of a Module and a context. The easiest way to start using ORCv2 (and see an example of ThreadSafeModule usage) is via the LLJIT class. See llvm/examples/HowToUseLLJIT.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Cheers,</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Lang.</span></div><br><div id="AppleMailSignature" dir="ltr">Sent from my iPad</div><div dir="ltr"><br>On Jun 26, 2019, at 2:48 PM, Riyaz Puthiyapurayil via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:9.0pt;
font-family:"Courier New";}
p.CodeCxSpFirst, li.CodeCxSpFirst, div.CodeCxSpFirst
{mso-style-name:CodeCxSpFirst;
mso-style-link:"Code Char";
mso-style-type:export-only;
margin:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:9.0pt;
font-family:"Courier New";}
p.CodeCxSpMiddle, li.CodeCxSpMiddle, div.CodeCxSpMiddle
{mso-style-name:CodeCxSpMiddle;
mso-style-link:"Code Char";
mso-style-type:export-only;
margin:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:9.0pt;
font-family:"Courier New";}
p.CodeCxSpLast, li.CodeCxSpLast, div.CodeCxSpLast
{mso-style-name:CodeCxSpLast;
mso-style-link:"Code Char";
mso-style-type:export-only;
margin:0in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:9.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt">I am trying to convert some very old code based on LLVM 3.4.2 to LLVM 7. So I want to replace some old LLVM JIT code with OrcJIT. I am new to this stuff and when I study the Kaleidoscope example, I started
wondering about this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">LLVMContext stores raw pointers to Module and will destroy the Module when the context is destroyed. But in the example, the module’s ownership is transferred to IRCompileLayer (which in trunk seems to be
now LegacyIRCompileLayer) which will destroy the module after eagerly compiling it using SimpleCompiler. Wouldn’t that leave the pointer to the same Module held in LLVMContext’s OwnedModules dangling?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">AFAIK, LLVMContext always owns the modules with which it is constructed (it holds them as Module*) unless it is explicitly removed from the Context. So it is not clear how std::unique_ptr can be used on the
same pointer.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Specifically, the problem is in this line:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"> </span><span style="font-size:14.0pt;font-family:"Courier New"">TheModule = llvm::make_unique<Module>("my cool jit", TheContext);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">TheModule owns the new module but so does TheContext (though not explicitly via unique_ptr).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">And then later we have:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Courier New"">TheJIT->addModule(std::move(TheModule));<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">The ownership is transferred but TheContext is still pointing to Module.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Note my question is not specifically about Kaleidoscope example but more about orc::LegacyIRCompileLayer::addModule expecting the caller to transfer ownership of a module.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Am I missing something here? TIA.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">/Riyaz<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
</div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></span><br><span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><br></div></blockquote></body></html>