[LLVMdev] Doubt in PHI node elimination

[Evan Cheng]

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.

Evan

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