<div dir="ltr">From <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2011_11_llvm-2D30-2Dtype-2Dsystem-2Drewrite.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=iWurlie6RLJLpRMrYPb6gWQ5wDQ2SfLg9XeGJKwZFBo&s=iT5bnlpB7XALXnzn-hk7SFkqZk3CqB1ignXIikWh90A&e=">http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html</a>:<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As in LLVM 2.9, type names are not really designed to be used as semantic information in IR: we expect everything to continue working if the -strip pass is used to remove all extraneous names from the IR. However, for research and other purposes, it can sometimes be a convenient hack to propagate information from a front-end into LLVM IR by using type names. This will work reliably in LLVM 3.0 (so long as you don't run the strip pass or something equivalent) because identified types aren't uniqued. However, be aware that the suffix can be added and write your code to tolerate it.<br>A more robust way to be able to identify a specific type in the optimizer (or some other point after the frontend has run) is to use a named metadata node to find the type. For example, if you want to find the %foo type, you could generate IR that looks like this:<br><font face="monospace, monospace">  %foo = type { ... }<br></font><font face="monospace, monospace">  ...<br></font><font face="monospace, monospace">  !magic.types = !{ %foo zeroinitializer }</font><br>Then to find the "foo" type, you'd just look up the "magic.types" named metadata, and get the type of the first element. Even if type names are stripped or types get auto-renamed, the type of the first element will always be correct and stable.</blockquote><div><br></div><div>-Jason Koenig </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 19, 2015 at 3:48 AM, DeadMG <span dir="ltr"><<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>I've got some code using the LLVM linker. When I link one module into another, the linker fails to correctly represent all the aspects of the source module. Specifically, I've observed that types whch are structurally equivalent get merged together, even though they're explicitly named types and not unnamed structural types.<br><br></div>Here's my reproducing case. I have the source and the output IR.<br><br><div>#pragma warning(push, 0)</div>
<div>#include <llvm/ExecutionEngine/GenericValue.h></div>
<div>#include <llvm/ExecutionEngine/MCJIT.h></div>
<div>#include <llvm/ExecutionEngine/ExecutionEngine.h></div>
<div>#include <llvm/Support/Program.h></div>
<div>#include <llvm/Support/FileSystem.h></div>
<div>#include <llvm/Support/DynamicLibrary.h></div>
<div>#include <llvm/IR/Verifier.h></div>
<div>#include <llvm/IR/Type.h></div>
<div>#include <llvm/IR/DerivedTypes.h></div>
<div>#include <llvm/IR/IRBuilder.h></div>
<div>#include <llvm/Transforms/Utils/Cloning.h></div>
<div>#include <llvm/Linker/Linker.h></div>
<div>#include <llvm/Support/raw_ostream.h></div>
<div>#pragma warning(pop)</div>
<div> </div>
<div>std::string printModule(llvm::Module& module) {</div>
<div>    std::string mod_ir;</div>
<div>    llvm::raw_string_ostream stream(mod_ir);</div>
<div>    module.print(stream, nullptr);</div>
<div>    stream.flush();</div>
<div>    return mod_ir;</div>
<div>}</div>
<div>int main() {</div>
<div>    llvm::LLVMContext con;</div>
<div>    llvm::Module src("in", con);</div>
<div>    llvm::Module dest("out", con);</div>
<div>    auto srcb1 = llvm::StructType::create(con, std::vector<llvm::Type*>{ llvm::PointerType::getInt8PtrTy(con) }, "srcb1");</div>
<div>    auto srcb2 = llvm::StructType::create(con, std::vector<llvm::Type*>{ llvm::PointerType::getInt8PtrTy(con) }, "srcb2");</div>
<div>    auto srcty = llvm::StructType::create(con, std::vector<llvm::Type*>{ srcb1, srcb2 }, "srcty");</div>
<div>    auto func = 
llvm::Function::Create(llvm::FunctionType::get(srcty, {}, false), 
llvm::GlobalValue::LinkageTypes::ExternalLinkage, "srcfunc", &src);</div>
<div>    llvm::BasicBlock* entries = llvm::BasicBlock::Create(func->getParent()->getContext(), "entry", func);</div>
<div>    llvm::IRBuilder<> allocabuilder(entries);</div>
<div>    auto insert = 
allocabuilder.CreateInsertValue(llvm::ConstantAggregateZero::get(srcty),
 llvm::ConstantAggregateZero::get(srcb1), { 0 });</div>
<div>    allocabuilder.CreateRet(insert);</div>
<div>    </div>
<div>    auto before = printModule(src);</div>
<div>    auto clone = std::unique_ptr<llvm::Module>(llvm::CloneModule(&src));</div>
<div>    llvm::Linker::LinkModules(&dest, clone.get());</div>
<div>    auto after = printModule(dest);</div>
<div>    if (before != after)</div>
<div>        __debugbreak();</div>
<div>}</div>
<div> </div>
<div>// Before:</div>
<div> </div>
<div>; ModuleID = 'in'</div>
<div> </div>
<div>%srcty = type { %srcb1, %srcb2 }</div>
<div>%srcb1 = type { i8* }</div>
<div>%srcb2 = type { i8* }</div>
<div> </div>
<div>define %srcty @srcfunc() {</div>
<div>entry:</div>
<div>  ret %srcty zeroinitializer</div>
<div>}</div>
<div> </div>
<div>// After:</div>
<div> </div>
<div>; ModuleID = 'out'</div>
<div> </div>
<div>%srcty = type { %srcb1, %srcb1 }</div>
<div>%srcb1 = type { i8* }</div>
<div> </div>
<div>define %srcty @srcfunc() {</div>
<div>entry:</div>
<div>  ret %srcty zeroinitializer</div>
}<br><br></div>You can see in before and after that the two structurally equivalent but distinct named types, srcb1 and srcb2, were merged. After a bit of discussion on #llvm, it was suggested that this is intended behaviour. If so, this is terribly broken. <br><br>For one thing, my code depends on looking up types from the module by name. So far it just so happens that I don't have any test cases that look up structurally equivalent types after linking by name, but it certainly could occur for some user inputs for my compiler.<br><br></div>Secondly, it's much more difficult for me to determine what is going on in this IR. In my compiler then I strictly generate one LLVM type for various types in the source code. If the compiler is broken for any reason, and I look at the IR output, then I expect to see this. If I don't see this, then I think the compiler is broken. I just spent three days trying to figure out why on earth my compiler was not generating the types correctly, when it was all along. And it's much more difficult to interpret the outcome when the IR no longer distinguishes between the two logically completely distinct types that just happen to have the same IR representation.<br><br></div>Fundamentally, LLVM should never mutate the contents of the module unless it's explicitly requested, because the programmer depends on properties of the IR that are more than just binary equivalence. Moving the contents of one module into another module is no exception.<br></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>