[llvm-commits] [llvm] r66976 - in /llvm/trunk: lib/CodeGen/PHIElimination.cpp lib/Transforms/Scalar/CodeGenPrepare.cpp test/CodeGen/X86/2009-03-13-PHIElimBug.ll test/CodeGen/X86/split-eh-lpad-edges.ll

[Duncan Sands]

Hi Evan,

> >        %reg1031<def> = MOV32rr %EAX
> >        EH_LABEL 2
> >        %reg1025<def> = MOV32rr %reg1031  <= Invoke result, not an  
> > EH_LABEL
> >        JMP mbb<entry.cont_crit_edge,0xa11af90>
> >
> > So in this case the logic bails out, putting the copy at the end of  
> > the BB,
> > even though it might still need to be before the invoke.
> 
> Something seems wrong with this. Who inserted the copy? The copy from  
> EAX to reg1031 is the copy lowered by isel. Is PHI elimination  
> inserting the copy from reg1031 to reg1025? Then it should have done  
> the right thing.

I'm not sure where it's coming from (see testcase below).  By the way, what
do you think of the patch I sent?  It's more efficient in the common case of
an invoke with one def/use of SrcReg in the basic block, but less efficient
when there is more than one def/use because it has to walk more of the basic
block.

Ciao,

Duncan.

Run: llc -march=x86 -f phi.bc

If I break on WalkPassEHTryRange, then the first time I hit the breakpoint
I see such a register copy after the EH_LABEL.  This is the MBB for "cont",
and it is trying to find a place to put the copy for the phi node in the
landing pad.

declare i32 @f()

declare i32 @g()

define i32 @phi() {
entry:
	%a = call i32 @f()		; <i32> [#uses=1]
	%b = invoke i32 @g()
			to label %cont unwind label %lpad		; <i32> [#uses=1]

cont:		; preds = %entry
	%x = phi i32 [ %b, %entry ]		; <i32> [#uses=0]
	%aa = call i32 @f()		; <i32> [#uses=1]
	%bb = invoke i32 @g()
			to label %cont2 unwind label %lpad		; <i32> [#uses=1]

cont2:		; preds = %cont
	%xx = phi i32 [ %bb, %cont ]		; <i32> [#uses=1]
	ret i32 %xx

lpad:		; preds = %cont, %entry
	%y = phi i32 [ %a, %entry ], [ %aa, %cont ]		; <i32> [#uses=1]
	ret i32 %y
}