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

shepmaster · 2017-04-28T04:10:59Z

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 · 2017-04-28T04:11:23Z

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

dylanmckay · 2017-05-01T09:09:27Z

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 · 2017-05-01T09:13:48Z

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 · 2017-05-01T09:16:19Z

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 · 2017-05-01T10:07:35Z

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 · 2017-07-11T09:56:13Z

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

shepmaster · 2017-07-11T15:10:16Z

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

dylanmckay · 2017-08-23T13:50:21Z

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 · 2017-08-24T15:25:27Z

I think this might be the one

llvm-mirror/llvm@5340452

Not sure though

dylanmckay · 2017-09-27T22:01:12Z

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

gergoerdi · 2017-09-27T22:02:47Z

The linked commit is already in the https://github.com/avr-rust/llvm/tree/avr-rust-2017-10-24 branch of LLVM, but I am still getting the error message when compiling chip8-avr with rust as of 55a75c2 and libcore-mini as of avr-rust/libcore@e661b41

gergoerdi · 2017-09-28T13:03:13Z

Bisection implicates llvm-mirror/llvm@2a303c708 as the commit that fixed this. Unfortunately, that commit cannot be cleanly cherry-picked on its own.

gergoerdi · 2017-09-28T13:17:02Z

I am now building a version of avr-rust-2017-10-24 with the following commits cherry-picked:

4f5f4e9
8c6e660
38eae0c
0a65c23
2a303c7
bb2a4cb
b162af3
0c0aece
d40c764
88d2075

gergoerdi · 2017-09-28T13:30:29Z

Nope; even with all these commits, LLVM fails to build with

llvm/lib/Analysis/BranchProbabilityInfo.cpp: In member function ‘bool llvm::BranchProbabilityInfo::calcUnreachableHeuristics(const llvm::BasicBlock*)’:
llvm/lib/Analysis/BranchProbabilityInfo.cpp:204:52: error: no match for ‘operator*’ (operand types are ‘const llvm::BranchProbability’ and ‘llvm::SmallVectorTemplateCommon<unsigned int, void>::size_type {aka long unsigned int}’)
       (BranchProbability::getOne() - UR_TAKEN_PROB * UnreachableEdges.size()) /
                                      ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from llvm/include/llvm/Analysis/BranchProbabilityInfo.h:25:0,
                 from /home/cactus/prog/rust/rust-avr/llvm/lib/Analysis/BranchProbabilityInfo.cpp:14:
llvm/include/llvm/Support/BranchProbability.h:133:21: note: candidate: llvm::BranchProbability llvm::BranchProbability::operator*(llvm::BranchProbability) const
   BranchProbability operator*(BranchProbability RHS) const {
                     ^~~~~~~~
llvm/include/llvm/Support/BranchProbability.h:133:21: note:   no known conversion for argument 1 from ‘llvm::SmallVectorTemplateCommon<unsigned int, void>::size_type {aka long unsigned int}’ to ‘llvm::BranchProbability’

So it seems we won't easily be getting this fix from LLVM until we migrate fully over to LLVM 5.0.

dylanmckay · 2017-09-28T14:31:55Z

Nice try, looked promising, hopefully the merge won't be too far away

brainlag · 2018-02-18T14:03:39Z

Since rust moved to LLVM 6 this can be marked as fixed.

dylanmckay · 2018-02-19T07:53:11Z

Good point @brainlag

Raised #90 to track rebasing to LLVM 6.0.

This issue is still a problem, but once #90 is fixed, this will also be fixed.

shepmaster · 2018-11-03T01:20:49Z

We've recently upgraded to LLVM 8 🎉 I'm going to close any bug that is reported against an older version of LLVM. If you are still having this issue with the LLVM-8 based code, please ping me and I can reopen the issue!

shepmaster added A-libcore Affects compiling the core library A-llvm Affects the LLVM AVR backend has-reduced-testcase A small LLVM IR file exists that demonstrates the problem labels Apr 28, 2017

gergoerdi mentioned this issue May 1, 2017

"Relocation truncated to fit" from branches in long functions #44

Closed

dylanmckay added this to the Compile stock libcore without errors milestone Aug 23, 2017

est31 mentioned this issue Jan 30, 2018

Tracking issue for 128-bit integer support (RFC 1504) rust-lang/rust#35118

Closed

5 tasks

shepmaster closed this as completed Nov 3, 2018

shepmaster added the has-llvm-commit This issue should be fixed in upstream LLVM label Nov 3, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

shepmaster commented Apr 28, 2017 •

edited

Loading

shepmaster commented Apr 28, 2017

dylanmckay commented May 1, 2017

gergoerdi commented May 1, 2017 •

edited

Loading

dylanmckay commented May 1, 2017

gergoerdi commented May 1, 2017

dylanmckay commented Jul 11, 2017

shepmaster commented Jul 11, 2017

dylanmckay commented Aug 23, 2017

dylanmckay commented Aug 24, 2017

dylanmckay commented Sep 27, 2017

gergoerdi commented Sep 27, 2017 •

edited

Loading

gergoerdi commented Sep 28, 2017 •

edited

Loading

gergoerdi commented Sep 28, 2017

gergoerdi commented Sep 28, 2017 •

edited

Loading

dylanmckay commented Sep 28, 2017

brainlag commented Feb 18, 2018

dylanmckay commented Feb 19, 2018

shepmaster commented Nov 3, 2018

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

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

Comments

shepmaster commented Apr 28, 2017 • edited Loading

shepmaster commented Apr 28, 2017

dylanmckay commented May 1, 2017

gergoerdi commented May 1, 2017 • edited Loading

dylanmckay commented May 1, 2017

gergoerdi commented May 1, 2017

dylanmckay commented Jul 11, 2017

shepmaster commented Jul 11, 2017

dylanmckay commented Aug 23, 2017

dylanmckay commented Aug 24, 2017

dylanmckay commented Sep 27, 2017

gergoerdi commented Sep 27, 2017 • edited Loading

gergoerdi commented Sep 28, 2017 • edited Loading

gergoerdi commented Sep 28, 2017

gergoerdi commented Sep 28, 2017 • edited Loading

dylanmckay commented Sep 28, 2017

brainlag commented Feb 18, 2018

dylanmckay commented Feb 19, 2018

shepmaster commented Nov 3, 2018

shepmaster commented Apr 28, 2017 •

edited

Loading

gergoerdi commented May 1, 2017 •

edited

Loading

gergoerdi commented Sep 27, 2017 •

edited

Loading

gergoerdi commented Sep 28, 2017 •

edited

Loading

gergoerdi commented Sep 28, 2017 •

edited

Loading