[LLVM 6.0] flt2dec / dec2flt cause assertion failed: Wrong topological sorting

[shepmaster]

This is with my recently-rebased branch based on upstream Rust 190a6c. I've added the patch from #99 locally.

Case 1

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

; Function Attrs: uwtable
define align 1 void @core__num__flt2dec__strategy__dragon__mul_pow() unnamed_addr  {
start:
  %ret.i = alloca [40 x i32], align 1
  %0 = zext i32 undef to i64
  %1 = add nuw nsw i16 0, 11
  br label %bb19.i105.11

bb19.i105.11:                                     ; preds = %start
  %2 = getelementptr inbounds [40 x i32], [40 x i32]* %ret.i, i16 0, i16 %1
  %3 = load i32, i32* %2, align 1
  %4 = mul nuw i64 %0, 2788392729
  %5 = zext i32 %3 to i64
  %6 = add nuw nsw i64 0, %5
  %7 = add i64 %6, %4
  %8 = trunc i64 %7 to i32
  store i32 %8, i32* %2, align 1
  unreachable
}

Case 2

; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "bugpoint-output-95356ba.bc"
target datalayout = "e-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
target triple = "avr-unknown-unknown"

%"num::bignum::Big32x40" = type { [0 x i8], i16, [0 x i8], [40 x i32], [0 x i8] }

; Function Attrs: uwtable
define void @"core::num::dec2flt::num::digits_to_big"() unnamed_addr {
start:
  %_7.sroa.0.0..sroa_idx.i = getelementptr inbounds %"num::bignum::Big32x40", %"num::bignum::Big32x40"* undef, i16 0, i32 3, i16 0
  switch i2 undef, label %bb5.i10 [
    i2 0, label %bb2.i
    i2 1, label %bb3.i
    i2 -2, label %bb4.i
  ]

bb2.i:                                            ; preds = %start
  ret void

bb3.i:                                            ; preds = %start
  %0 = add i8 0, -48
  %1 = zext i8 %0 to i32
  %2 = load i32, i32* %_7.sroa.0.0..sroa_idx.i, align 1
  %3 = call { i32, i1 } @llvm.uadd.with.overflow.i32(i32 %2, i32 %1)
  %4 = extractvalue { i32, i1 } %3, 0
  store i32 %4, i32* %_7.sroa.0.0..sroa_idx.i, align 1
  unreachable

bb4.i:                                            ; preds = %start
  unreachable

bb5.i10:                                          ; preds = %start
  unreachable
}

; Function Attrs: nounwind readnone speculatable
declare { i32, i1 } @llvm.uadd.with.overflow.i32(i32, i32)

Error

Assertion failed: (Node2Index[SU.NodeNum] > Node2Index[PD.getSUnit()->NodeNum] && "Wrong topological sorting"), function InitDAGTopologicalSorting, file /Users/shep/Projects/avr-rust/src/llvm/lib/CodeGen/ScheduleDAG.cpp, line 518.

[shepmaster]

/cc @brainlag

[jhwgh1968]

Since I got my bugpoint setup working and fixed all my paths, I can now report a new cra-- oh. 😄

One piece of addition information: I did not apply #99 and I still got this crash in exactly the same place.

[TimNN]

I've been looking into this issue a bit (with a slightly different repro since I'm using a newer LLVM version). The issue appears to be that whatever data is passed to ScheduleDAGTopologicalSort, is not a DAG. The example where the assertion happens contains a cycle.

Note that this seems to be related to optimizations. Compiling with llc -O0 is fine, llc -O1 is not.

[TimNN]

In case that helps anyone, here is what I believe is the relevant part of the -debug output: https://gist.github.com/620098d70297404f3d02a8555363b916

The "LLVM ERROR: out of memory" seems easily explainable to me: LLVM apparently wants to compute the depth of the "DAG" for debug printing. Since the DAG contains a cycle, we get an infinite loop.

[brainlag]

If you compile llvm with asserts you will hit that and don't run into OOM error.
I debugged this in the past and IIRC the problem is because 2 nodes in the DAG are glued together which lead to the cycle. If these 2 nodes would not glued together it would be fine.

[TimNN]

the problem is because 2 nodes in the DAG are glued together

I'm not quite sure what you mean with "glued together". In my case there is a cycle between three nodes (2, 3 and 6 in the Graph below).

Graph