[LLVMdev] Q: When is a boolean not a boolean?

[Nick Lewycky]

Jeremy Lakeman wrote:
> A: When the types are created in different contexts.
>
> I've been running into a module validation error related to phi nodes
> produced by the GVN pass, where the types of the incoming values aren't
> the same instance of IntegerType i1.
>
> I'm not certain I've found the root cause of the problem yet, it's
> probably due to my handling of LLVMContext & Module life cycles, and
> this is my first real look at llvm's source.
>
> This patch at least makes my problem go away;
>
> @@ -2195,11 +2200,11 @@ bool GVN::processInstruction(Instruction *I) {
>       BasicBlock *Parent = BI->getParent();
>       bool Changed = false;
>
> -    Value *TrueVal = ConstantInt::getTrue(TrueSucc->getContext());
> +    Value *TrueVal = ConstantInt::getTrue(BranchCond->getContext());
>       BasicBlockEdge TrueE(Parent, TrueSucc);
>       Changed |= propagateEquality(BranchCond, TrueVal, TrueE);
>
> -    Value *FalseVal = ConstantInt::getFalse(FalseSucc->getContext());
> +    Value *FalseVal = ConstantInt::getFalse(BranchCond->getContext());
>       BasicBlockEdge FalseE(Parent, FalseSucc);
>       Changed |= propagateEquality(BranchCond, FalseVal, FalseE);
>
> Any other ideas about where I should look for the root problem? Is there
> any better documentation on how to deal with multiple LLVMContext instances?
>
> I'm primarily creating multiple contexts to make sure my named
> structures aren't renamed during linking.

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.

If you've created IR with two different contexts, they are not allowed 
to comingle in any way whatsoever.

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).

Nick