[LLVMdev] Doubt in PHI node elimination

Evan Cheng evan.cheng at apple.com
Mon Jul 6 22:24:44 PDT 2009

On Jul 3, 2009, at 4:01 AM, Sanjiv Gupta wrote:

> Sachin.Punyani at microchip.com wrote:
>> Hi,
>> In PHI node elimination pass to insert the copy in the predecessor
>> block, there is a check if terminator is not an invoke instruction
>> then place the copy there only. However for invoke terminator
>> instruction a safe position is located for copy insertion.
>> My doubt is why is this safe location search done only for invoke
>> instruction and not for other terminators such as branch.
>> For my target terminator is branch instruction and it uses the
>> implicit def (STATUS reg) from its predecessor instruction. PHI
>> elimination pass inserts the copy just between the branch and its
>> predecessor. Copy instruction on my target affects the same implicit
>> def (STATUS reg), hence giving improper information to branch.  If
>> safe location search for copy insertion is done for branch  
>> instruction
>> also then this dependency does not break.
> The code in question here is:MachineBasicBlock::iterator
> PNE::FindCopyInsertPoint(MachineBasicBlock &MBB,
>                                                     unsigned SrcReg) {
>  // Handle the trivial case trivially.
>  if (MBB.empty())
>    return MBB.begin();
>  // If this basic block does not contain an invoke, then control flow
> always
>  // reaches the end of it, so place the copy there.  The logic below
> works in
>  // this case too, but is more expensive.
>  if (!isa<InvokeInst>(MBB.getBasicBlock()->getTerminator()))
>    return MBB.getFirstTerminator();
> If the copy insn affects the status flags, then it should not be
> inserted between the cmp (which also affects the status flags) and the
> branch insn.
> So the above piece of code looks incorrect.

Ok, there are many places in llvm codegen that insert copies. The  
implicit assumption is a copy would not alter any register or state  
information. If your target cannot insert a copy which doesn't modify  
the status flag then a lot of things might not work.


> - Sanjiv
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list