Tracking issue for MIR (RFC #1211)

[nikomatsakis]

Tracking issue for transition to MIR (rust-lang/rfcs#1211).

Relevant discuss thread: https://internals.rust-lang.org/t/transitioning-to-mir/2706

Regressions

These are cases where building MIR is causing existing crates to stop working.

• Stack overflow when compiling lots of macros #29466
• reduce memory usage for match Perf regression in nightly when compiling massive matches #29227

Refactorings

These are places where the design of MIR needs some tweaks. In some cases, the best course of action may be unclear or in active debate.

• Calls Mir: Refactor calls to permit calls that cannot panic and to better accommodate calls that always panic #29767
• Panics Mir: remove Panic terminator and instead just call suitable lang item #29573
• Scopes Mir: refactor how scopes are represented #29768
• Overflow Mir: introduce overflow operations #29769

Other work

• issues tagged with A-mir
• add overflow and division by zero checking
• constant propagation and hoisting
• port rvalue checking
• port dead-code pass
• port reachability
• port match checking to take place during MIR construction
• port effect checking
• port intrinsicck
• enable trans universally

[steveklabnik]

#27893

[nikomatsakis]

PR #28748 enables MIR construction unconditionally.

[bstrie]

@nikomatsakis I've heard reports that unconditional MIR construction is leading to OOM for certain people. Is MIR construction going to also be enabled for the stable and beta releases? I'd hate for compiler perf to regress for 1.5-stable...

[bstrie]

@nikomatsakis Not just memory regression, but perf regression too:

< Rym> Anyone know anything about the 'MIR Dump' pass and factors which might affect its speed?
<@bstrie> Rym: is it causing performance problems for you?
< Rym> bstrie: It's approximately 6 seconds of a 12second no-trans build (effectively doubling the time compared to a beta compiler, where it took <0.01s)

To reiterate my question, is it safe to assume that we won't be turning on MIR construction unconditionally for 1.5-beta, even if we leave it on for 1.6-nightly?

[Ryman]

crate/commit in question for the above: nickel-org/nickel.rs@197aac3
rustc: rustc 1.5.0-nightly (1210fb9bc 2015-10-23)

It's still repro on latest nightly: rustc 1.5.0-nightly (c3db627cb 2015-10-26).
Same compiler has <0.2s 'MIR dump' for hyper, so I'm wondering if we're doing something particularly bad within nickel? Seems to bounce around between 4-6seconds.

[nikomatsakis]

@bstrie Good question. I was actually just debating now whether to land a PR disabling construction without some sort of flag for that reason, since I haven't had time to investigate and fix those regressions (which was of course my preferred solution).

[nikomatsakis]

@Ryman the existing issue had to do with match translation, do you know if you have any match statements that have large sets of constants (or lots and lots of patterns)? For example:

match foo {
    1 | 2 | ... | 32767 => ...
    ...
}

[Ryman]

@nikomatsakis Ah, yeah we do, this expands into two decent sized matches. If I extracted that to another crate and re-exported the type I guess we'd lose the hit?

[nikomatsakis]

@Ryman well ideally we'll just fix the codegen issue :) I'm not sure if
exporting it to another crate would help, except that you would only do it
once I guess. Anyway, I've just about got a PR that disables MIR on
beta/stable for now.

On Mon, Oct 26, 2015 at 2:57 PM, Ryman notifications@github.com wrote:

@nikomatsakis https://github.com/nikomatsakis Ah, yeah we do
https://github.com/nickel-org/nickel.rs/blob/master/src/mimes.rs, this
expands into two decent sized matches. If I extracted that to another crate
and re-exported the type I guess we'd lose the hit?

—
Reply to this email directly or view it on GitHub
#27840 (comment).

[nikomatsakis]

@Ryman still that match doesn't quite fit the pattern I was expecting, I'll
have to investigate more deeply.

On Mon, Oct 26, 2015 at 3:07 PM, Nicholas Matsakis nmatsakis@mozilla.com
wrote:

@Ryman well ideally we'll just fix the codegen issue :) I'm not sure if
exporting it to another crate would help, except that you would only do it
once I guess. Anyway, I've just about got a PR that disables MIR on
beta/stable for now.

On Mon, Oct 26, 2015 at 2:57 PM, Ryman notifications@github.com wrote:

@nikomatsakis https://github.com/nikomatsakis Ah, yeah we do
https://github.com/nickel-org/nickel.rs/blob/master/src/mimes.rs, this
expands into two decent sized matches. If I extracted that to another crate
and re-exported the type I guess we'd lose the hit?

—
Reply to this email directly or view it on GitHub
#27840 (comment).

[Ryman]

@nikomatsakis it looks like each of the derivings for that enum also result in huge matches against single tuple refs, e.g. (&Foo,) => { .. }. Would that fit the pattern more?

[nikomatsakis]

@Ryman I was more thinking of matches against integer literals or other
non-enum types.

On Mon, Oct 26, 2015 at 4:58 PM, Ryman notifications@github.com wrote:

@nikomatsakis https://github.com/nikomatsakis it looks like each of the
derivings for that enum also result in huge matches against single tuple
refs, e.g. (&Foo,) => { .. }. Would that fit the pattern more?

—
Reply to this email directly or view it on GitHub
#27840 (comment).