<div dir="ltr"><div><div><div><div><div><div><div><div><div>I think a large part of the confusion comes from two conflicting ideas:<br><br></div>1. Things that create modules return a unique_ptr<Module>, which indicates an intention to make it difficult to have multiple copies of a module "pointer".<br></div>2. However, the LLVM API has several methods that return or require bare Module* pointers.<br><br></div>The result is that you pretty much have to "smash" the unique_ptr<Module> to get a raw pointer out to get any work done, which is potentially dangerous.<br><br></div>In my case, I can create a Module in one of two ways:<br><br></div>a) By reading in bitcode:<br><br>        ErrorOr<std::unique_ptr<llvm::<wbr>Module> > eom =<br>            parseBitcodeFile(mb-><wbr>getMemBufferRef(), context);<br><br>        if (eom) {<br>            m_Module = std::move(eom.get());<br><br></div>b) By newing one:<br><br>        std::unique_ptr<Module> upm(new Module(name, context));<br><br>        m_Module = std::move(upm);<br><br></div><div>If I want to support a) then I am forced to store a unique_ptr<Module> in my own code.<br><br></div>But then if I want to pass a Module* into some other LLVM API, I need to:<br><br>    Module                      &getModule() const { return *m_Module; }<br><br>    m_Func = Function::Create(as_type, Function::ExternalLinkage, name, &getModule());<br><br></div>All of this seems quite stilted. On the one hand, we have a strong effort to ensure that there are no dangling pointers to Modules, but on the other, we have to jump through hoops to get values required for arguments to other API calls, and in doing so, undo the "guarantees" we get from using unique_ptr in the first place.<br><br></div>Or am I totally missing the point?  Is there a better way for me to organize this code?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 14, 2016 at 1:02 PM, Jonathan Roelofs via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 9/14/16 10:23 AM, Frank Winter via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok. I can make a copy of the unique_ptr before moving it into the<br>
builder's constructor and use the copy later on. It is confusing to<br>
require a unique_ptr.<br>
</blockquote>
<br>
It's (almost?) always a bad idea to make a copy of a std::unique_ptr.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Frank<br>
<br>
On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am constructing the engine builder in the following way:<br>
<br>
llvm::SMDiagnostic Err;<br>
unique_ptr<Module> Mod = getLazyIRFileModule("f.ll", Err, TheContext);<br>
llvm::EngineBuilder engineBuilder(std::move(Mod));<br>
<br>
However, after moving the pointer to the constructor it is no longer<br>
retrievable from the unique_ptr object.<br>
</blockquote></blockquote>
<br>
Moving re-assigns ownership of the pointed-to memory to the EngineBuilder.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Mod.get()->dump();   // this segfaults after the move, but not before<br>
</blockquote></blockquote>
<br>
That is expected.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I conclude that any type of operation on the module is no longer<br>
valid.<br>
</blockquote></blockquote>
<br>
Correction: any operation via the *moved* unique_ptr is no longer valid.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am I constructing the engine builder as it is supposed to?<br>
<br>
Frank<br>
<br>
<br>
On 09/14/2016 10:59 AM, Frank Winter via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I get a segfault with this code when setting the data layout:<br>
<br>
<br>
<br>
int main(int argc, char** argv)<br>
{<br>
  llvm::InitializeNativeTarget()<wbr>;<br>
<br>
  llvm::LLVMContext TheContext;<br>
  unique_ptr<Module> Mod(new Module("A",TheContext));<br>
<br>
  llvm::EngineBuilder engineBuilder(std::move(Mod));<br>
  std::string mcjit_error;<br>
<br>
  engineBuilder.setMCPU(llvm::sy<wbr>s::getHostCPUName());<br>
<br>
  engineBuilder.setEngineKind(ll<wbr>vm::EngineKind::JIT);<br>
  engineBuilder.setOptLevel(llvm<wbr>::CodeGenOpt::Aggressive);<br>
  engineBuilder.setErrorStr(&mcj<wbr>it_error);<br>
<br>
  llvm::TargetOptions targetOptions;<br>
  targetOptions.AllowFPOpFusion = llvm::FPOpFusion::Fast;<br>
  engineBuilder.setTargetOptions<wbr>( targetOptions );<br>
<br>
  TargetMachine *targetMachine = engineBuilder.selectTarget();<br>
<br>
  assert(targetMachine && "failed to create target machine");<br>
<br>
  std::cout <<<br>
targetMachine->createDataLayou<wbr>t().getStringRepresentation() << "\n";<br>
<br>
  Mod.get()->setDataLayout(<br>
targetMachine->createDataLayou<wbr>t().getStringRepresentation() ); //<br>
this segfaults<br>
  Mod.get()->setDataLayout( targetMachine->createDataLayou<wbr>t()  ); //<br>
as well as this<br>
}<br>
<br>
<br>
Backtrace:<br>
<br>
<br>
Using host libthread_db library<br>
"/lib/x86_64-linux-gnu/libthre<wbr>ad_db.so.1".<br>
e-m:e-i64:64-f80:128-n8:16:32:<wbr>64-S128<br>
<br>
Program received signal SIGSEGV, Segmentation fault.<br>
0x00007ffff5f65832 in llvm::SmallVectorTemplateCommo<wbr>n<unsigned char,<br>
void>::end (this=0x148) at<br>
/home/fwinter/svn/llvm-3.9/inc<wbr>lude/llvm/ADT/SmallVector.h:<wbr>117<br>
117      iterator end() { return (iterator)this->EndX; }<br>
(gdb) bt<br>
#0  0x00007ffff5f65832 in llvm::SmallVectorTemplateCommo<wbr>n<unsigned<br>
char, void>::end (this=0x148) at<br>
/home/fwinter/svn/llvm-3.9/inc<wbr>lude/llvm/ADT/SmallVector.h:<wbr>117<br>
#1  llvm::SmallVectorImpl<unsigned char>::clear (this=0x148) at<br>
/home/fwinter/svn/llvm-3.9/inc<wbr>lude/llvm/ADT/SmallVector.h:<wbr>345<br>
#2  0x00007ffff5fa13b5 in llvm::DataLayout::clear (this=0x138) at<br>
/home/fwinter/svn/llvm-3.9/lib<wbr>/IR/DataLayout.cpp:545<br>
#3  0x00007ffff5f9f561 in llvm::DataLayout::reset (this=0x138,<br>
Desc=...) at /home/fwinter/svn/llvm-3.9/lib<wbr>/IR/DataLayout.cpp:179<br>
#4  0x00007ffff60b25ca in llvm::Module::setDataLayout (this=0x0,<br>
Desc=...) at /home/fwinter/svn/llvm-3.9/lib<wbr>/IR/Module.cpp:377<br>
#5  0x0000000000406c46 in main (argc=1, argv=0x7fffffffde68) at<br>
main.cc:95<br>
<br>
<br>
Any idea?<br>
<br>
Frank<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</font></span></blockquote></div><br></div>