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

Owen Anderson resistor at mac.com
Mon May 13 10:27:25 PDT 2013

On May 13, 2013, at 7:12 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> 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.

You're going to get weird breakage doing that.  Types and constants are uniqued per-context, and optimization passes depend on that to perform shallow equality comparisons on them.  The only valid way to use multiple contexts is to have multiple completely independent copies of LLVM operating within the same address space.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130513/6a6487ad/attachment.html>

More information about the llvm-dev mailing list