[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,

> Also, I really want to know where the above mentioned copy copies  
> from. But I haven't found the time to look at it.

it seems that this comes from the way the selection DAG is built:
the EH_LABEL and the copying out of the invoke result are both
operands of a TokenFactor.  As such, neither is required to come
before the other and in this example it seems the EH_LABEL was
output first:

  0x2e49f60: i32,ch = call 0x2e4a058, 0x2e27778
        0x2e26c08: <multiple use>
        0x2e49d70: i32 = Register  #1027
        0x2e49f60: <multiple use>
      0x2e4a248: ch = CopyToReg 0x2e26c08, 0x2e49d70, 0x2e49f60
        0x2e49f60: <multiple use>
      0x2e49e68: ch = eh_label 0x2e49f60:1
    0x2e272a0: ch = TokenFactor 0x2e4a248, 0x2e49e68

... becomes ...

        CALLpcrel32 <ga:g>, %EAX<imp-def>, %ECX<imp-def>, %EDX<imp-def>, %FP0<imp-def>, %FP1<imp-def>, %FP2<imp-def>, %FP3<imp-def>, %FP4<imp-def>, %FP5<imp-def>, %FP6<imp-def>, %ST0<imp-def>, %MM0<imp-def>, %MM1<imp-def>, %MM2<imp-def>, %MM3<imp-def>, %MM4<imp-def>, %MM5<imp-def>, %MM6<imp-def>, %MM7<imp-def>, %XMM0<imp-def>, %XMM1<imp-def>, %XMM2<imp-def>, %XMM3<imp-def>, %XMM4<imp-def>, %XMM5<imp-def>, %XMM6<imp-def>, %XMM7<imp-def>, %XMM8<imp-def>, %XMM9<imp-def>, %XMM10<imp-def>, %XMM11<imp-def>, %XMM12<imp-def>, %XMM13<imp-def>, %XMM14<imp-def>, %XMM15<imp-def>, %EFLAGS<imp-def>, %ESP<imp-use>
        ADJCALLSTACKUP32 0, 0, %ESP<imp-def>, %EFLAGS<imp-def>, %ESP<imp-use>
        %reg1033<def> = MOV32rr %EAX
        EH_LABEL 4
        %reg1027<def> = MOV32rr %reg1033

The code that constructs the EH_LABEL that precedes the invoke
call makes sure that any loads or stores are flushed before the
EH_LABEL:

    (void)getRoot();
    DAG.setRoot(DAG.getLabel(ISD::EH_LABEL, getCurDebugLoc(),
                             getControlRoot(), BeginLabel));

However no such precautions are taken for the EH_LABEL coming
after the call.  That makes sense, because it doesn't matter
where the final label is as long as it is after the call itself
(which is enforced by having the label use the chain produced
by the call).  So I don't think anything is wrong here.

Ciao,

Duncan.