kavon / ghc-llvm

improvements to llvm to support functional-language compilers, e.g., ghc
Other
4 stars 0 forks source link

Failing Assertion: undef'd register "should be live-in to block" #16

Open kavon opened 7 years ago

kavon commented 7 years ago

"The register %R14 needs to be live in to BB#1, but is missing from the live-in list. LLVM ERROR: Invalid global physical register"

When compiling x2n1.

From LiveRangeCalc::findReachingDefs on the given code.

176B  BB#1: derived from LLVM BB %c71x
      Predecessors according to CFG: BB#0
192B    ADJCALLSTACKDOWN64 0, 0, 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use>
208B    %XMM0<def> = COPY %vreg252; FR64:%vreg252
224B    CALL64pcrel32 <ga:@rintDouble>, <regmask %BH %BL %BP %BPL %BX %EBP %EBX %RBP %RBX %R12 %R13 %R14 %R15 %R12B %R13B %R14B %R15B %R12D %R13D %R14D %R15D %R12W %R13W %R14W %R15W>, %RSP<imp-use>, %XMM0<imp-use,kill>, %RSP<imp-def>, %XMM0<imp-def>
240B    ADJCALLSTACKUP64 0, 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use>
256B    %vreg255<def> = COPY %XMM0<kill>; FR64:%vreg255
288B    %vreg256<def,tied1> = ADD64ri8 %vreg256<tied0>, -8, %EFLAGS<imp-def,dead>; GR64:%vreg256
304B    ADJCALLSTACKDOWN64 0, 0, 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use>
320B    %R13<def> = COPY %vreg242; GR64:%vreg242
336B    %RBP<def> = COPY %vreg256; GR64:%vreg256
352B    %R12<def> = COPY %vreg244; GR64:%vreg244
368B    %RBX<def> = COPY %vreg245; GR64:%vreg245
384B    %R15<def> = COPY %vreg251; GR64:%vreg251
400B    %XMM1<def> = COPY %vreg255; FR64:%vreg255
416B    ADJCALLSTACKUP64 0, 0, %RSP<imp-def>, %EFLAGS<imp-def,dead>, %RSP<imp-use>
432B    %vreg508<def> = LEA64r %RIP, 1, %noreg, <MCSym=L7133701809754892656_0>, %noreg; GR64:%vreg508
448B    MOV64mr %RBP, 1, %noreg, 0, %noreg, %vreg508; GR64:%vreg508
464B    TCRETURNdi64 <ga:@integerzmgmp_GHCziIntegerziType_decodeDoubleInteger_info>, 0, %RSP<imp-use>, %R13<imp-use>, %RBP<imp-use>, %R12<imp-use>, %RBX<imp-use>, %R14<imp-use,undef>, %RSI<imp-use,undef>, %RDI<imp-use,undef>, %R8<imp-use,undef>, %R9<imp-use,undef>, %R15<imp-use>, %XMM1<imp-use>
      Successors according to CFG: BB#2(?%)

480B  BB#2: ADDRESS TAKEN
      Live Ins: %R13 %RBP %R12 %RBX %R14 %RSI %RDI %R8 %R9 %R15 %XMM1 %XMM2 %XMM3 %XMM4 %XMM5 %XMM6 %XMM8 %XMM9 %XMM10 %XMM11 %XMM12 %XMM13
      Predecessors according to CFG: BB#1
496B    %vreg22<def> = COPY %R13; GR64:%vreg22
512B    %vreg376<def> = COPY %RBP; GR64:%vreg376
528B    %vreg24<def> = COPY %R12; GR64:%vreg24
544B    %vreg25<def> = COPY %RBX; GR64:%vreg25
560B    %vreg26<def> = COPY %R14<kill>; GR64:%vreg26
576B    %vreg27<def> = COPY %R15; GR64:%vreg27
      Successors according to CFG: BB#3(0x80000000 / 0x80000000 = 100.00%)
kavon commented 7 years ago

This bug only appeared once I replaced marking the return point of a CPS call as an EHPad with ContPoint. The current workaround is to continue saying that the block is an EHPad... why??

kavon commented 7 years ago

Marking as question just to remind myself to consider this again when cleaning up the implementation.