rustc built by MIR overflows its stack for crates with very deep ASTs.

[eddyb]

These examples have been found on crater:

• boiler (failure)
• procinfo (failure)
• marksman_escape (failure)

These reproduce with stage2 but not stage1, unless stage0 is passed -Z orbit, which means a compiler built by MIR trans will use more stack space than old trans did.

For procinfo, there are just over 1000 frames, usually in the NodeIdAssigner, my guess is that its AST has a depth 500-700 in places (it's using nom, which might cause such extreme nesting).

cc @rust-lang/compiler

[nikomatsakis]

triage: P-high

[eddyb]

May be fixed by #35764, we should do a crater run after that's merged.

[eddyb]

Actually, how are we going to do a crater run if we don't have an old trans switch?

I suppose before-after on that PR might suffice (and it would catch other problems wrt drop flags).
I'll start it now then, no point in waiting.

[nikomatsakis]

@eddyb well we can certainly just check the results for procinfo by hand, as well

[eddyb]

@nikomatsakis My manual check suggests it's fixed, but I want to see it on crater before closing.

[eddyb]

Crater report shows it didn't actually get fixed.

[nikomatsakis]

@eddyb were you able to observe it failing before?

[eddyb]

@nikomatsakis Yes, and a stage2 build of #35764 was the first time I saw it work again.

EDIT: Just tested again, stage1 overflows its stack (being built by beta), stage2 doesn't.

[eddyb]

@brson's beta crater runs reveals that @nagisa's marksman_escape also triggers a stack overflow.
(Local testing suggests the same thing as with procinfo, stage2 build on master is fixed.)

If it is the change to remove filling drop from syntax::ptr::P::map, we should backport it to beta.
However, crater doesn't agree that the stack overflows have been fixed on master, which is troubling.

[nagisa]

Its probably caused by the auto generated trie in
https://github.com/nagisa/marksman_escape/blob/master/src/unescape_named_gen.rs
.

We should really investigate that arbitrary sized initializers do not break
our compiler, likely by removing a great deal of recursion from
visitors'n'stuff.

On Aug 27, 2016 5:25 AM, "Eduard-Mihai Burtescu" notifications@github.com
wrote:

@brson https://github.com/brson's beta crater runs reveals that @nagisa
https://github.com/nagisa's marksman_escape
https://github.com/nagisa/marksman_escape/ also overflows the stack
(but not for me).
If it is the change to remove filling drop from syntax::ptr::P::map, we
should backport it to beta.
However, crater doesn't agree that the stack overflows have been fixed on
master, which is troubling.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35408 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AApc0tsp7xNOw2Q1hr8Qj_m-DkiREcyIks5qj6AzgaJpZM4JeLdY
.

[nagisa]

For all its worth I coud not reproduce the issue with nightly from 08-04, but could reproduce with stage2 build of rustc built from my i128 PR.

EDIT: the stack looks like this:

#0  0x00007ffff62a8048 in rustc_mir::build::expr::into::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::into_expr::hc42b8ada809f1035 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1  0x00007ffff62a7609 in rustc_mir::build::expr::as_temp::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_temp::hba345fa0021716b2 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#2  0x00007ffff629e400 in rustc_mir::build::expr::as_lvalue::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_lvalue::hfebf21c311b493a1 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#3  0x00007ffff629e601 in rustc_mir::build::expr::as_lvalue::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_lvalue::hfebf21c311b493a1 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#4  0x00007ffff62a2210 in rustc_mir::build::expr::as_rvalue::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_rvalue::hf57cd9d6c4fc893f ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#5  0x00007ffff62a804d in rustc_mir::build::expr::into::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::into_expr::hc42b8ada809f1035 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#6  0x00007ffff62a7609 in rustc_mir::build::expr::as_temp::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_temp::hba345fa0021716b2 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#7  0x00007ffff62a6ed9 in rustc_mir::build::expr::as_operand::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_operand::hd95ce91f21ae7fad ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#8  0x00007ffff62a7191 in rustc_mir::build::expr::as_operand::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_operand::hd95ce91f21ae7fad ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
<snip>
#1117 0x00007ffff6279686 in _$LT$core..option..Option$LT$T$GT$$GT$::map::h5970387ea4c5fee8 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1118 0x00007ffff6276e72 in _$LT$std..collections..hash..map..HashMap$LT$K$C$$u20$V$C$$u20$S$GT$$u20$as$u20$core..iter..traits..FromIterator$LT$$LP$K$C$$u20$V$RP$$GT$$GT$::from_iter::h6443816681f7ff1a ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1119 0x00007ffff62a1096 in rustc_mir::build::expr::as_rvalue::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::expr_as_rvalue::hf57cd9d6c4fc893f ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1120 0x00007ffff62a804d in rustc_mir::build::expr::into::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::into_expr::hc42b8ada809f1035 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1121 0x00007ffff62adfd7 in rustc_mir::build::into::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::into::h9246168aa4cad424 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1122 0x00007ffff62a7f93 in rustc_mir::build::expr::into::_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$::into_expr::hc42b8ada809f1035 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1123 0x00007ffff629bb33 in rustc_mir::build::construct_const::h74155ec175d112ec () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1124 0x00007ffff62d81b2 in _$LT$rustc_mir..mir_map..BuildMir$LT$$u27$a$C$$u20$$u27$tcx$GT$$u20$as$u20$rustc..hir..intravisit..Visitor$LT$$u27$tcx$GT$$GT$::visit_item::haaa92e27f3a6e7a2 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1125 0x00007ffff62d5baa in rustc_mir::mir_map::build_mir_for_crate::ha2aa65fcf43a1078 () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_mir-8c019922e235d620.so
#1126 0x00007ffff7b6861c in rustc_driver::driver::phase_3_run_analysis_passes::_$u7b$$u7b$closure$u7d$$u7d$::h922452a65734443a ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1127 0x00007ffff7ab816d in rustc::ty::context::TyCtxt::create_and_enter::h4062331123dddcae () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1128 0x00007ffff7b2abeb in rustc_driver::driver::compile_input::h23043149fd34f5f2 () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1129 0x00007ffff7b52458 in rustc_driver::run_compiler::h9354ce3c92088fa1 () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1130 0x00007ffff7a8d08e in std::panicking::try::do_call::hfa6bd405b4124555 () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1131 0x00007ffff778b8a7 in __rust_maybe_catch_panic () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-22eea4e7ebd6be05.so
#1132 0x00007ffff7aaaa1a in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h866ec516a20280b3 ()
   from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-4b8197d9ed53832d.so
#1133 0x00007ffff7777ac1 in std::sys::thread::Thread::new::thread_start::h14d720bd1f948c8e () from /home/nagisa/Documents/rust/rust/worktrees/more-cace/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-22eea4e7ebd6be05.so
#1134 0x00007ffff0a89454 in start_thread () from /usr/lib/libpthread.so.0
#1135 0x00007ffff73ac7df in clone () from /usr/lib/libc.so.6

[eddyb]

I've managed to get the IR from old and MIR trans for hir::lowering::LoweringContext::lower_expr, and looking for allocas with no llvm.lifetime.start calls: https://gist.github.com/eddyb/0b9afd3a5cc04fcc35643afb3aa00804

The [140 x i8] allocas are hir::Expr reduced to hir::Expr_ (+ 4 unused bytes AFAICT).
Just the [140 x i8] and hir::Expr_ allocas together add up to 9kB, about half of the frame size.
The original allocas (e.g. hir::lowering::LoweringContext::expr's node argument) have StorageLive and StorageDead as needed, but it looks like SROA may be stripping them in some cases.

I need to try to reproduce this outside of librustc though.

What a waste of time, old trans is missing llvm.lifetime.start only on these:

  %self = alloca %"hir::lowering::LoweringContext"*, align 8
  %e = alloca %"12.syntax::ast::Expr"*, align 8

While MIR trans... well, MIR trans has llvm.lifetime.start on every single alloca.
Although, this is with a change to add Storage{Live,Dead} around statement temps.

What I missed the first time was that getelementpointer can be used to get a i8* pointer to the start of the alloca, not just bitcast, so that's what was different with the allocas I found.

So the remaining theory is that there's just too many allocas and/or they have huge overlap ranges.
The frame size is for about 140 hir::Expr_, that's a lot of them for what the function is doing.
I wonder if @pcwalton's memcpy improvements would reduce that number significantly.

[eddyb]

Something I noticed while looking at #36023 which may be relevant: we seem to be emitting StorageDead for all bindings in all arms in the merge of a match instead of on each arm.
Not sure if anything better can be done here. Also, the StorageLive are in the appropriate arms, so perhaps this has no negative impact at all.

[nikomatsakis]

@eddyb do you think that having more lifetime-start calls would cause problems? I guess it's possible.

[kamalmarhubi]

Heads up, I got danburkert/procinfo-rs#15 merged with a workaround for this issue in procinfo. Passing crater on that crate won't mean it's fixed.

[brson]

@rust-lang/compiler @eddyb please retriage this one. When we made it P-medium it was because we thought it was fixed, but it is not.

[kamalmarhubi]

Note that it was fixed (or did not manifest on procinfo) and then regressed: #35408 (comment)

[eddyb]

@kamalmarhubi What value of RUST_MIN_STACK does it start working again at? Default should be 16000000 (~16MB) and IIRC 7000000 (~7MB) used to be enough, maybe we regressed somewhere else (the first dozen frames of a backtrace would be helpful).

[arielb1]

Something I noticed while looking at #36023 which may be relevant: we seem to be emitting StorageDead for all bindings in all arms in the merge of a match instead of on each arm.

Sure. The region hierarchy for match-expressions has the bindings destroyed only on the exit block of the match, so for example

fn example(ex: Box<Result<[u32; 64], [i32; 64]>>) {
    match *ex {
        Ok(a) => {},
        Err(b) => {}
    }
}

Translates to

fn example(_1: Box<std::result::Result<[u32; 64], [i32; 64]>>) -> () {
    let mut _0: ();                      // return pointer
    scope 1 {
        let _2: Box<std::result::Result<[u32; 64], [i32; 64]>>; // "ex" in scope 1 at <anon>:3:12: 3:14
        scope 2 {
            let _4: [u32; 64];           // "a" in scope 2 at <anon>:5:12: 5:13
        }
        scope 3 {
            let _5: [i32; 64];           // "b" in scope 3 at <anon>:6:13: 6:14
        }
    }
    let mut _3: ();

    bb0: {
        StorageLive(_2);                 // scope 0 at <anon>:3:12: 3:14
        _2 = _1;                         // scope 0 at <anon>:3:12: 3:14
        switch((*_2)) -> [Ok: bb3, Err: bb4]; // scope 1 at <anon>:5:9: 5:14
    }

    bb1: {
        resume;                          // scope 0 at <anon>:3:1: 8:2
    }

    bb2: {
        drop(_2) -> bb1;                 // scope 0 at <anon>:8:2: 8:2
    }

    bb3: {
        StorageLive(_4);                 // scope 1 at <anon>:5:12: 5:13
        _4 = (((*_2) as Ok).0: [u32; 64]); // scope 1 at <anon>:5:12: 5:13
        _0 = ();                         // scope 2 at <anon>:5:18: 5:20
        goto -> bb5;                     // scope 1 at <anon>:4:5: 7:6
    }

    bb4: {
        StorageLive(_5);                 // scope 1 at <anon>:6:13: 6:14
        _5 = (((*_2) as Err).0: [i32; 64]); // scope 1 at <anon>:6:13: 6:14
        _0 = ();                         // scope 3 at <anon>:6:19: 6:21
        goto -> bb5;                     // scope 1 at <anon>:4:5: 7:6
    }

    bb5: {
        StorageDead(_5);                 // scope 1 at <anon>:7:6: 7:6
        StorageDead(_4);                 // scope 1 at <anon>:7:6: 7:6
        drop(_1) -> [return: bb6, unwind: bb2]; // scope 0 at <anon>:8:2: 8:2
    }

    bb6: {
        drop(_2) -> bb7;                 // scope 0 at <anon>:8:2: 8:2
    }

    bb7: {
        StorageDead(_2);                 // scope 0 at <anon>:8:2: 8:2
        return;                          // scope 1 at <anon>:8:2: 8:2
    }
}

Here the live-ranges for a and b overlap - I suspect that this can lead to LLVM placing them in separate allocas.

[eddyb]

@arielb1 Last I looked the numbers seemed to fit the non-overlapping situation, but maybe I wasn't paying enough attention. It'd be great if we can get a win from changing that?

[nikomatsakis]

triage: P-high

We should at least figure out if something changed since the last time we looked, though the solution seems pretty unclear.

[arielb1]

All functions in librustc with with stack frames over 4kB:

$ objdump -d ./build/x86_64-unknown-linux-gnu/stage0/lib/librustc-62b3e239.so | grep -B10 'sub.*0x[1-9a-f][0-9a-f][0-9a-f][0-9a-f],%rsp' | grep ^000000
00000000000c3260 <_ZN56_$LT$syntax..ast..Expr$u20$as$u20$core..clone..Clone$GT$5clone17h0b9f5bdd0ef90b32E>:
0000000000121a30 <_ZN5rustc9dep_graph6thread4main17h8ba9da102f1e3585E>:
000000000013fe30 <_ZN143_$LT$rustc..hir..lowering..LoweringContext..lower_crate..ItemLowerer$LT$$u27$lcx$C$$u20$$u27$interner$GT$$u20$as$u20$syntax..visit..Visitor$GT$10visit_item17h129c67de0682c23dE>:
00000000001444b0 <_ZN5rustc3hir8lowering15LoweringContext10lower_item17h6c926aaa4dad761aE>:
0000000000147b80 <_ZN5rustc3hir8lowering15LoweringContext10lower_expr17h06dc253ad1c81fa2E>:
000000000017f570 <_ZN5rustc5infer15error_reporting87_$LT$impl$u20$rustc..infer..InferCtxt$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$20report_region_errors17h238676c09050d0a9E>:
0000000000184760 <_ZN5rustc5infer15error_reporting87_$LT$impl$u20$rustc..infer..InferCtxt$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$23report_concrete_failure17hb96357b0dcaa6fcdE>:
00000000001f3df0 <_ZN5rustc6middle8liveness8visit_fn17h2f36d9c5e4b23d1eE>:
000000000022a390 <_ZN5rustc7session6config21rustc_short_optgroups17h1dd178b6bc0868faE>:
000000000022f5e0 <_ZN5rustc7session6config38build_session_options_and_crate_config17hec8089707b9377d4E>:
0000000000239ec0 <_ZN5rustc7session14build_session_17h0115f416cfde5a00E>:
0000000000240620 <_ZN5rustc6traits15error_reporting87_$LT$impl$u20$rustc..infer..InferCtxt$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$22report_selection_error17h7adb94259b4617e9E>:
0000000000262320 <_ZN5rustc6traits6select16SelectionContext17confirm_candidate17h38a1154fd14f35b0E>:
0000000000269350 <_ZN5rustc6traits10specialize20specialization_graph5Graph6insert17h47b0f75b980067a8E>:

[arielb1]

And in librustc_mir:

$ objdump -d ./build/x86_64-unknown-linux-gnu/stage0/lib/librustc_mir-62b3e239.so | grep -B10 'sub.*0x[1-9a-f][0-9a-f][0-9a-f][0-9a-f],%rsp' | grep ^000000
0000000000049d40 <_ZN9rustc_mir5build4expr9as_rvalue89_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$14expr_as_rvalue17h0dd0e5275ecc6520E>:
000000000004e660 <_ZN9rustc_mir5build4expr9as_rvalue89_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$15build_binary_op17he2784c8a7fe205d0E>:
00000000000515c0 <_ZN9rustc_mir5build4expr4into89_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$9into_expr17h4593b1066fa67afaE>:
00000000000542f0 <_ZN9rustc_mir5build4expr4stmt89_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$9stmt_expr17h8b4bbc53caa2ededE>:
0000000000058630 <_ZN9rustc_mir5build7matches4test89_$LT$impl$u20$rustc_mir..build..Builder$LT$$u27$a$C$$u20$$u27$gcx$C$$u20$$u27$tcx$GT$$GT$12perform_test17h2c3e67e7a182cf74E>:
0000000000075450 <_ZN9rustc_mir7mir_map8BuildMir19build_const_integer17h73d205e0ccc5bfecE>:
0000000000076620 <_ZN126_$LT$rustc_mir..mir_map..BuildMir$LT$$u27$a$C$$u20$$u27$tcx$GT$$u20$as$u20$rustc..hir..intravisit..Visitor$LT$$u27$tcx$GT$$GT$10visit_item17hfdd565e96e1b3b12E>:
0000000000078f30 <_ZN126_$LT$rustc_mir..mir_map..BuildMir$LT$$u27$a$C$$u20$$u27$tcx$GT$$u20$as$u20$rustc..hir..intravisit..Visitor$LT$$u27$tcx$GT$$GT$16visit_trait_item17hed4decf6474376d5E>:
000000000007a350 <_ZN126_$LT$rustc_mir..mir_map..BuildMir$LT$$u27$a$C$$u20$$u27$tcx$GT$$u20$as$u20$rustc..hir..intravisit..Visitor$LT$$u27$tcx$GT$$GT$15visit_impl_item17h595951c1feb85398E>:
000000000007b740 <_ZN126_$LT$rustc_mir..mir_map..BuildMir$LT$$u27$a$C$$u20$$u27$tcx$GT$$u20$as$u20$rustc..hir..intravisit..Visitor$LT$$u27$tcx$GT$$GT$8visit_fn17hbbf343a5ae162072E>:
000000000008a420 <_ZN9rustc_mir9transform10type_check11TypeChecker16check_terminator17h7c541b550bedaad2E>:
000000000008f550 <_ZN110_$LT$rustc_mir..transform..type_check..TypeckMir$u20$as$u20$rustc..mir..transform..MirPass$LT$$u27$tcx$GT$$GT$8run_pass17h90921022119d9ee7E>:

[eddyb]

@arielb1 Nice! Could that be used on a stable release, prior to MIR trans being on by default?
At least we could see how much worse MIR codegen itself is compared to old trans, in frame sizes.

[danburkert]

procinfo 0.3.0 is the published version that was affected. An easy repro is:

cd /tmp
cargo new foo
cd foo
echo 'procinfo = "=0.3.0"' >> Cargo.toml
rustup run <toolchain> cargo build

Here are the results I get:

rustc	compile result
1.12.0	stack overflow
1.13.0	33 seconds
1.14.0-beta.2	segfault
1.15.0-nightly (ba872f2 2016-11-17)	47 seconds

So latest nightly is not reproing, but it looks like there has been a serious perf regression since 1.13. It also looks like 1.14 will have the issue if it isn't fixed before the release (which would be a regression from 1.13).

[brson]

cc @eddyb @nikomatsakis any updates? This is still tagged P-high so please circle back to it soon.

[brson]

No changes since 11/17. Still P-high. @nikomatsakis @eddyb please re-triage.

[nikomatsakis]

triage: P-medium

Still worthy of investigation -- and I hope to do so post-xmas -- but not a burning priority. More of a long-standing issue we need to improve bit by bit.

[pnkfelix]

There's been mucho activity investigating stack blowup issues on #40883. @arielb1 believes that the LLVM fixes linked from #40883 (comment) will be necessary to resolve these problems for us.

[arielb1]

I believe this should be fixed with the fix to #40883.

[jonas-schievink]

This can probably be closed now.