<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2016, at 10:24 AM, David Jones via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">I think a large part of the confusion comes from two conflicting ideas:<br class=""><br class=""></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 class=""></div></div></div></div></div></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">2. However, the LLVM API has several methods that return or require bare Module* pointers.<br class=""></div></div></div></div></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><br class=""></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 class=""><br class=""></div>In my case, I can create a Module in one of two ways:<br class=""><br class=""></div>a) By reading in bitcode:<br class=""><br class=""> ErrorOr<std::unique_ptr<llvm::<wbr class="">Module> > eom =<br class=""> parseBitcodeFile(mb-><wbr class="">getMemBufferRef(), context);<br class=""><br class=""> if (eom) {<br class=""> m_Module = std::move(eom.get());<br class=""><br class=""></div>b) By newing one:<br class=""><br class=""> std::unique_ptr<Module> upm(new Module(name, context));<br class=""><br class=""> m_Module = std::move(upm);<br class=""><br class=""></div><div class="">If I want to support a) then I am forced to store a unique_ptr<Module> in my own code.<br class=""><br class=""></div>But then if I want to pass a Module* into some other LLVM API, I need to:<br class=""><br class=""> Module &getModule() const { return *m_Module; }<br class=""><br class=""> m_Func = Function::Create(as_type, Function::ExternalLinkage, name, &getModule());<br class=""><br class=""></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 class=""><br class=""></div>Or am I totally missing the point? Is there a better way for me to organize this code?<br class=""></div></div></blockquote><div><br class=""></div><div><div><div>IMO, you’re expecting from unique_ptr something that it is not intended to, i.e. it is not expressing “an intention to make it difficult to have multiple copies”. It is just here to handle the ownership responsibility.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""></div></div></div></div></div></div></div></blockquote></div><div>This does not seem conflicting with API that takes raw pointers to me: raw pointers don’t imply ownership transfer.</div><div>(That said I prefer reference in APIs to make explicit what is/isn’t optional, but that’s an orthogonal issue).</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""></div></div></div></div></div></div></div></blockquote></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Sep 14, 2016 at 1:02 PM, Jonathan Roelofs via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
<br class="">
On 9/14/16 10:23 AM, Frank Winter via llvm-dev wrote:<br class="">
<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 class="">
builder's constructor and use the copy later on. It is confusing to<br class="">
require a unique_ptr.<br class="">
</blockquote>
<br class="">
It's (almost?) always a bad idea to make a copy of a std::unique_ptr.<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
Frank<br class="">
<br class="">
On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote:<br class="">
<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 class="">
<br class="">
llvm::SMDiagnostic Err;<br class="">
unique_ptr<Module> Mod = getLazyIRFileModule("f.ll", Err, TheContext);<br class="">
llvm::EngineBuilder engineBuilder(std::move(Mod));<br class="">
<br class="">
However, after moving the pointer to the constructor it is no longer<br class="">
retrievable from the unique_ptr object.<br class="">
</blockquote></blockquote>
<br class="">
Moving re-assigns ownership of the pointed-to memory to the EngineBuilder.<br class="">
<br class="">
<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 class="">
Mod.get()->dump(); // this segfaults after the move, but not before<br class="">
</blockquote></blockquote>
<br class="">
That is expected.<br class="">
<br class="">
<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 class="">
So I conclude that any type of operation on the module is no longer<br class="">
valid.<br class="">
</blockquote></blockquote>
<br class="">
Correction: any operation via the *moved* unique_ptr is no longer valid.<br class="">
<br class="">
<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 class="">
Am I constructing the engine builder as it is supposed to?<br class="">
<br class="">
Frank<br class="">
<br class="">
<br class="">
On 09/14/2016 10:59 AM, Frank Winter via llvm-dev wrote:<br class="">
<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 class="">
<br class="">
<br class="">
<br class="">
int main(int argc, char** argv)<br class="">
{<br class="">
llvm::InitializeNativeTarget()<wbr class="">;<br class="">
<br class="">
llvm::LLVMContext TheContext;<br class="">
unique_ptr<Module> Mod(new Module("A",TheContext));<br class="">
<br class="">
llvm::EngineBuilder engineBuilder(std::move(Mod));<br class="">
std::string mcjit_error;<br class="">
<br class="">
engineBuilder.setMCPU(llvm::sy<wbr class="">s::getHostCPUName());<br class="">
<br class="">
engineBuilder.setEngineKind(ll<wbr class="">vm::EngineKind::JIT);<br class="">
engineBuilder.setOptLevel(llvm<wbr class="">::CodeGenOpt::Aggressive);<br class="">
engineBuilder.setErrorStr(&mcj<wbr class="">it_error);<br class="">
<br class="">
llvm::TargetOptions targetOptions;<br class="">
targetOptions.AllowFPOpFusion = llvm::FPOpFusion::Fast;<br class="">
engineBuilder.setTargetOptions<wbr class="">( targetOptions );<br class="">
<br class="">
TargetMachine *targetMachine = engineBuilder.selectTarget();<br class="">
<br class="">
assert(targetMachine && "failed to create target machine");<br class="">
<br class="">
std::cout <<<br class="">
targetMachine->createDataLayou<wbr class="">t().getStringRepresentation() << "\n";<br class="">
<br class="">
Mod.get()->setDataLayout(<br class="">
targetMachine->createDataLayou<wbr class="">t().getStringRepresentation() ); //<br class="">
this segfaults<br class="">
Mod.get()->setDataLayout( targetMachine->createDataLayou<wbr class="">t() ); //<br class="">
as well as this<br class="">
}<br class="">
<br class="">
<br class="">
Backtrace:<br class="">
<br class="">
<br class="">
Using host libthread_db library<br class="">
"/lib/x86_64-linux-gnu/libthre<wbr class="">ad_db.so.1".<br class="">
e-m:e-i64:64-f80:128-n8:16:32:<wbr class="">64-S128<br class="">
<br class="">
Program received signal SIGSEGV, Segmentation fault.<br class="">
0x00007ffff5f65832 in llvm::SmallVectorTemplateCommo<wbr class="">n<unsigned char,<br class="">
void>::end (this=0x148) at<br class="">
/home/fwinter/svn/llvm-3.9/inc<wbr class="">lude/llvm/ADT/SmallVector.h:<wbr class="">117<br class="">
117 iterator end() { return (iterator)this->EndX; }<br class="">
(gdb) bt<br class="">
#0 0x00007ffff5f65832 in llvm::SmallVectorTemplateCommo<wbr class="">n<unsigned<br class="">
char, void>::end (this=0x148) at<br class="">
/home/fwinter/svn/llvm-3.9/inc<wbr class="">lude/llvm/ADT/SmallVector.h:<wbr class="">117<br class="">
#1 llvm::SmallVectorImpl<unsigned char>::clear (this=0x148) at<br class="">
/home/fwinter/svn/llvm-3.9/inc<wbr class="">lude/llvm/ADT/SmallVector.h:<wbr class="">345<br class="">
#2 0x00007ffff5fa13b5 in llvm::DataLayout::clear (this=0x138) at<br class="">
/home/fwinter/svn/llvm-3.9/lib<wbr class="">/IR/DataLayout.cpp:545<br class="">
#3 0x00007ffff5f9f561 in llvm::DataLayout::reset (this=0x138,<br class="">
Desc=...) at /home/fwinter/svn/llvm-3.9/lib<wbr class="">/IR/DataLayout.cpp:179<br class="">
#4 0x00007ffff60b25ca in llvm::Module::setDataLayout (this=0x0,<br class="">
Desc=...) at /home/fwinter/svn/llvm-3.9/lib<wbr class="">/IR/Module.cpp:377<br class="">
#5 0x0000000000406c46 in main (argc=1, argv=0x7fffffffde68) at<br class="">
<a href="http://main.cc:95" class="">main.cc:95</a><br class="">
<br class="">
<br class="">
Any idea?<br class="">
<br class="">
Frank<br class="">
<br class="">
<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote>
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote>
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><span class="HOEnZb"><font color="#888888" class=""><br class="">
</font></span></blockquote><span class="HOEnZb"><font color="#888888" class="">
<br class="">
-- <br class="">
Jon Roelofs<br class="">
<a href="mailto:jonathan@codesourcery.com" target="_blank" class="">jonathan@codesourcery.com</a><br class="">
CodeSourcery / Mentor Embedded<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</font></span></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>