[LLVMdev] difficulty in replicating a sequence of instructions + inserting at a different location -- "instruction doesn't dominate all uses"

[John Criswell]

On 5/2/11 11:59 AM, Chuck Zhao wrote:
> I am having difficulty in replicating a sequence of instructions (2+, 
> with def-use dependencies within) and inserting them at a different 
> location.
>
> I have tried a few different approaches (IRBuilder, new Instruction(), 
> I->clone(), insertBefore/insertAfter,etc.), all leading to the same 
> error msg:
> "Instruction doesn't dominate all uses"

In LLVM IR, an instruction must dominate all of its uses.  What this 
means is that an instruction must be inserted into a basic block that 
dominates the basic blocks of all instructions that use the inserted 
instruction's result.  In other words, it must be the case that the 
inserted instruction is always executed once before any instruction that 
uses its result.

I'm not sure what you are doing wrong that is causing the above problem 
to occur.  It might be that you're not adjusting the def-use chains 
after replication or you might be inserting instructions in the wrong 
order in a basic block (defs must come before uses).

The above error comes from the verifier pass, so you can disable the 
verifier pass, save the bitcode, and disassemble it to see what IR 
you're building that is incorrect.  Alternatively, you can have your 
transform dump the new instructions to stdout or stderr to see what IR 
it is generating.

-- John T.

>
> The DevList has a few previous discussions on this, but not much of 
> hints I can get from there.
>
> Could somebody point me a code template or an existing LLVM source 
> file that does similar things?
>
>
> Thank you very much
>
> Chuck
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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