Assertion failed: (!SplitVirtReg->empty() && "expecting non-empty interval"), function allocatePhysRegs

[shepmaster]

I commented out all the bignum / dec2flt / flt2dec / diyfloat modules and got to this error.

; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "bugpoint-output-9da0630.bc"
target datalayout = "e-p:16:16:16-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-n8"
target triple = "avr"

; Function Attrs: uwtable
define fastcc void @_ZN4core3num14from_str_radix17h52611b1bf2950c2eE(i8* noalias nonnull readonly, i16, i32) unnamed_addr #0 {
start:
  %not. = icmp ugt i32 undef, 34
  br i1 %not., label %bb5, label %bb6

bb5:                                              ; preds = %start
  unreachable

bb6:                                              ; preds = %start
  %3 = load i8, i8* %0, align 1
  switch i8 %3, label %SliceAlpha [
    i8 43, label %bb23
    i8 45, label %SliceIndexAlpha
  ]

bb13.loopexit:                                    ; preds = %bb12.i49
  unreachable

bb13.loopexit150:                                 ; preds = %bb61, %bb57, %bb12.i
  %.sink121.ph151 = phi i8 [ 3, %bb61 ], [ 3, %bb57 ], [ 1, %bb12.i ]
  store i8 %.sink121.ph151, i8* undef, align 1
  unreachable

SliceAlpha:                                       ; preds = %bb6
  unreachable

SliceIndexAlpha:                                  ; preds = %bb6
  br label %bb23

bb23:                                             ; preds = %SliceIndexAlpha, %bb6
  %.sink15 = phi i1 [ false, %SliceIndexAlpha ], [ true, %bb6 ]
  %.sink12 = getelementptr inbounds i8, i8* %0, i16 1
  br label %bb28

bb28:                                             ; preds = %bb23
  br i1 %.sink15, label %SliceBeta, label %SliceGamma

SliceBeta:                                        ; preds = %bb28
  %4 = load i8, i8* %.sink12, align 1
  %5 = zext i8 %4 to i32
  br label %bb12.i49

SliceGamma:                                       ; preds = %bb28
  %.ptr136 = getelementptr inbounds i8, i8* %0, i16 %1
  br label %SliceTheta

bb12.i49:                                         ; preds = %SliceBeta
  %6 = add nsw i32 -48, %5
  %7 = icmp ult i32 %6, %2
  br i1 %7, label %bb40, label %bb13.loopexit

bb40:                                             ; preds = %bb12.i49
  unreachable

SliceTheta:                                       ; preds = %bb65, %SliceGamma
  %result.1134 = phi i128 [ %17, %bb65 ], [ 0, %SliceGamma ]
  %iter1.sroa.0.0.in133 = phi i8* [ %8, %bb65 ], [ %.sink12, %SliceGamma ]
  %8 = getelementptr inbounds i8, i8* %iter1.sroa.0.0.in133, i16 1
  br label %bb12.i

bb12.i:                                           ; preds = %SliceTheta
  %9 = add nsw i32 undef, undef
  %10 = icmp ult i32 %9, %2
  br i1 %10, label %bb57, label %bb13.loopexit150

bb57:                                             ; preds = %bb12.i
  %11 = tail call { i128, i1 } @llvm.smul.with.overflow.i128(i128 %result.1134, i128 undef) #2
  %12 = extractvalue { i128, i1 } %11, 1
  br i1 %12, label %bb13.loopexit150, label %bb61

bb61:                                             ; preds = %bb57
  %13 = extractvalue { i128, i1 } %11, 0
  %14 = zext i32 %9 to i128
  %15 = tail call { i128, i1 } @llvm.ssub.with.overflow.i128(i128 %13, i128 %14) #2
  %16 = extractvalue { i128, i1 } %15, 1
  br i1 %16, label %bb13.loopexit150, label %bb65

bb65:                                             ; preds = %bb61
  %17 = extractvalue { i128, i1 } %15, 0
  %18 = icmp eq i8* %8, %.ptr136
  br i1 %18, label %bb66.loopexit152, label %SliceTheta

bb66.loopexit152:                                 ; preds = %bb65
  unreachable
}

; Function Attrs: nounwind readnone
declare { i128, i1 } @llvm.ssub.with.overflow.i128(i128, i128) #1

; Function Attrs: nounwind readnone
declare { i128, i1 } @llvm.smul.with.overflow.i128(i128, i128) #1

attributes #0 = { uwtable }
attributes #1 = { nounwind readnone }
attributes #2 = { nounwind }

[shepmaster]

I do note that there are i128 values being used up in here.

[dylanmckay]

It looks like even AVR-GCC only supports up to 64-bits.

I wonder what the i128 support is like in AVR - I haven't written (nor have ever seen) any explicit 128bit support, but we don't even have to write code for 32-bit or 64-bit integers as LLVM transparently lowers them to many 16-bit operations.

Does libcore use i128 much @shepmaster?

[gergoerdi]

FWIW I've just now got the same assertion failure with no i128 or u128 in sight in the LLVM IR. Is that something that would be helpful if I attached here? (it's not reduced at all; comes in at ~2000 lines of LLVM IR).

[dylanmckay]

FWIW I've just now got the same assertion failure with no i128 or u128 in sight in the LLVM IR. Is that something that would be helpful if I attached here?

I don't think it's worth it - if you've got the same assertion without i128, then it means that the size of the int is unrelated and it's something else.

[gergoerdi]

I was able to work around this in my code by inlining a lot of functions; however, this workaround then fails at linking time because the generated functions are suddenly too large.

[dylanmckay]

I can't reproduce this on current LLVM master, I think

[shepmaster]

That would be exciting! I could totally see LLVM lower i128 to lots and lots of i8 which might massively bloat the code...

[dylanmckay]

This seems to be fixed in LLVM 5.0, but not in avr-rust/llvm

It should get fixed in our next LLVM update.

[dylanmckay]

I think this might be the one

llvm-mirror/llvm@5340452

Not sure though

[dylanmckay]

Gergo has tried cherry-picking that commit and it is still broken