<div dir="ltr"><div><div><div>Ah, I found the root cause of my problem with contexts. It seems I was accidentally creating all BasicBlocks in the default context, hence why changing GVN to use the context of an instruction instead of a block fixed my symptoms.<br>

<br></div>I'm building a front end for an existing interpreted OO language. I've got a pre-built runtime module that defines some commonly used structures and method prototypes.<br>As I compile other modules, the first thing I do is load this pre-built module from disk and link it in. <br>
Then I'll compile some methods, getting the type of these identified structures by name when needed, and write out the new module to disk and delete it from memory. <br>But the context still knows these identified structures, and for some reason the next time I load the same pre-built runtime module from disk and link it these structures are renamed in all the pre-built method prototypes.<br>
</div><br>I could keep this pre-built module loaded in memory, but I'm calling into 
llvm through a limited set of language bindings I've written and I 
haven't added a link mode argument yet. This repeated reloading is an 
issue I'll probably tackle soon for improved efficiency anyway.<br></div>And I could replace these named structures with unnamed ones. Again I mainly gave them names so I didn't have to write a language binding to define them at compile time, but I've built that interface now so there's nothing stopping me from changing that behaviour.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 4:53 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">Jeremy Lakeman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A: When the types are created in different contexts.<br>
<br>
I've been running into a module validation error related to phi nodes<br>
produced by the GVN pass, where the types of the incoming values aren't<br>
the same instance of IntegerType i1.<br>
<br>
I'm not certain I've found the root cause of the problem yet, it's<br>
probably due to my handling of LLVMContext & Module life cycles, and<br>
this is my first real look at llvm's source.<br>
<br>
This patch at least makes my problem go away;<br>
<br>
@@ -2195,11 +2200,11 @@ bool GVN::processInstruction(<u></u>Instruction *I) {<br>
      BasicBlock *Parent = BI->getParent();<br>
      bool Changed = false;<br>
<br>
-    Value *TrueVal = ConstantInt::getTrue(TrueSucc-<u></u>>getContext());<br>
+    Value *TrueVal = ConstantInt::getTrue(<u></u>BranchCond->getContext());<br>
      BasicBlockEdge TrueE(Parent, TrueSucc);<br>
      Changed |= propagateEquality(BranchCond, TrueVal, TrueE);<br>
<br>
-    Value *FalseVal = ConstantInt::getFalse(<u></u>FalseSucc->getContext());<br>
+    Value *FalseVal = ConstantInt::getFalse(<u></u>BranchCond->getContext());<br>
      BasicBlockEdge FalseE(Parent, FalseSucc);<br>
      Changed |= propagateEquality(BranchCond, FalseVal, FalseE);<br>
<br>
Any other ideas about where I should look for the root problem? Is there<br>
any better documentation on how to deal with multiple LLVMContext instances?<br>
<br>
I'm primarily creating multiple contexts to make sure my named<br>
structures aren't renamed during linking.<br>
</blockquote>
<br></div></div>
The purpose of LLVM contexts is to keep two separate users of LLVM entirely separate within the process space. Consider a program that uses an OpenGL library which uses LLVM under the hood, and also uses a sound library which uses LLVM under the hood. Those two libraries should each have their own LLVMContext in order to ensure that they don't interfere with each other.<br>

<br>
If you've created IR with two different contexts, they are not allowed to comingle in any way whatsoever.<br>
<br>
Could you elaborate on the named structures problem? If you link two modules containing identified structures, they shouldn't get renamed unless their contents are different (where inner identified structs with the same name are again considered equal).<span class="HOEnZb"><font color="#888888"><br>

<br>
Nick<br>
</font></span></blockquote></div><br></div>