MIR graphviz prettification

[solson]

r? @nikomatsakis

cc @eddyb @nagisa

This PR changes most of the MIR graphviz debug output, making it smaller and more consistent. Also, it changes all fonts to monospace and adds a graph label containing the type of the fn the MIR is for and all the values (arguments, named bindings, and compiler temporaries).

I chose to re-write the graphviz output code instead of using the existing libgraphviz API because I found it much easier to prototype usage of various graphviz features when I had full control of the text output. It also makes the code simpler, I think.

Below are a bunch of example functions and links to their output images on the current nightly vs. this PR. File names starting with numbers (e.g. 80-factorial_fold-new.png) are for closures. There's still a bunch of low hanging fruit to make it even better, particularly around aggregates and references.

I also imagine the textual output for MIR will be able to closely match the graphviz output. The list of statements should look identical and the terminators will be the same except that the text form will have a list of target blocks (potentially using the same edge labels as the graphviz does). I can PR a simple text output right after this PR.

This is my first large change to the compiler, so if anything should be reorganized/renamed/etc, let me know! Also, feel free to bikeshed the details of the output, though any minor changes can come in future PRs.

#[rustc_mir(graphviz = "empty.dot")]
fn empty() {}

http://vps.solson.me/mir-graphviz/empty-new.png
http://vps.solson.me/mir-graphviz/empty-old.png

#[rustc_mir(graphviz = "constant.dot")]
fn constant() -> i32 {
    42
}

http://vps.solson.me/mir-graphviz/constant-new.png
http://vps.solson.me/mir-graphviz/constant-old.png

#[rustc_mir(graphviz = "increment.dot")]
fn increment(x: i32) -> i32 {
    x + 1
}

http://vps.solson.me/mir-graphviz/increment-new.png
http://vps.solson.me/mir-graphviz/increment-old.png

#[rustc_mir(graphviz = "factorial_recursive.dot")]
fn factorial_recursive(n: usize) -> usize {
    if n == 0 {
        1
    } else {
        n * factorial_recursive(n - 1)
    }
}

http://vps.solson.me/mir-graphviz/factorial_recursive-new.png
http://vps.solson.me/mir-graphviz/factorial_recursive-old.png

#[rustc_mir(graphviz = "factorial_iterative.dot")]
fn factorial_iterative(n: usize) -> usize {
    let mut prod = 1;
    for x in 1..n {
        prod *= x;
    }
    prod
}

http://vps.solson.me/mir-graphviz/factorial_iterative-new.png
http://vps.solson.me/mir-graphviz/factorial_iterative-old.png

#[rustc_mir(graphviz = "factorial_fold.dot")]
fn factorial_fold(n: usize) -> usize {
    (1..n).fold(1, |prod, x| prod * x)
}

http://vps.solson.me/mir-graphviz/factorial_fold-new.png
http://vps.solson.me/mir-graphviz/factorial_fold-old.png
http://vps.solson.me/mir-graphviz/80-factorial_fold-new.png
http://vps.solson.me/mir-graphviz/80-factorial_fold-old.png

#[rustc_mir(graphviz = "collatz.dot")]
fn collatz(mut n: usize) {
    while n != 1 {
        if n % 2 == 0 {
            n /= 2;
        } else {
            n = 3 * n + 1;
        }
    }
}

http://vps.solson.me/mir-graphviz/collatz-new.png
http://vps.solson.me/mir-graphviz/collatz-old.png

#[rustc_mir(graphviz = "multi_switch.dot")]
fn multi_switch(n: usize) -> usize {
    match n {
        5 | 10 | 15 => 3,
        20 | 30 => 2,
        _ => 1,
    }
}

http://vps.solson.me/mir-graphviz/multi_switch-new.png
http://vps.solson.me/mir-graphviz/multi_switch-old.png

[michaelwoerister]

@tsion Very nice! I'd have to take a closer look if any vital information is missing now that was shown before, but from a first glance I like the new output a lot better. Much more readable :)

[nagisa]

Looks pretty good to me (both code and output). I have a minor concern that spelling out every branch (true/false/return/unwind) might introduce too much visual clutter, but I think it is fine to leave it as is for now and wait to see if it ends up being an issue.

I’d argue it still would be better to name Lvalues arg0, var0 and tmp0, so they are more self-documenting.

[nagisa]

Ah, also, I believe Adt, Tuple and Vec aggregates can easily be “prettified” as well. Adt is a struct or variant, and thus could be displayed as

Aggregate<StructPath { field1: value, field2: value2 }>,
Aggregate<EnumPath::Variant { field1: value, field2: value }>

and so on.

EDIT: note that it doesn’t really matter whether it is a struct or enum variant, what matters is the kind of Adt, i.e. is it struct-like (Path {…}), unit-like (Option::<T>::None) or tuple-like (Option::<T>::Some(t)). Tuple-like things cannot end up as Adt (currently) so you only need to handle struct-like and unit-like variants.

[eddyb]

The <> on Aggregate are a bit jarring, StructPath { field1: value, field2: value2 }, optionally prefixed by ADT or data would be fine, I think.

[luqmana]

👍 Nice! Looks great.

[solson]

@nagisa I think I agree about arg0, var0, and tmp0. I'm finding it hard to tell a0, v0, and t0 apart when quickly scanning some MIR, and the longer names are much more visually distinct.

For aggregates, I was planning to drop the whole Aggregate<> thing and pretty print every type of aggregate in its own way, but I left that for another PR.

[nagisa]

For aggregates, I was planning to drop the whole Aggregate<> thing and pretty print every type of aggregate in its own way, but I left that for another PR.

Sure, SGTM.

[huonw]

Maybe there should be (choosable) levels of verbosity in the output, e.g. I imagine the spans are usually not needed at all (except for closures, maybe).

[eddyb]

Ah, @huonw, that's a great idea - would be useful for types, i.e. being able to see them everywhere, like in LLVM IR, when you need that.
Even better if we could toggle the verbosity in SVG with CSS, but, alas, don't think graphviz is that sophisticated.

[solson]

@huonw Yeah, that's a good idea. I was mainly aiming to remove irrelevant details, e.g. between constant-old and constant-new, but we could have flags for adding spans and/or types back in.

[solson]

Another thought: we could show all integer constants with their type suffixes (e.g. 42i32), so showing all types would be necessary less often.

[solson]

I made the change from a/v/t to arg/var/tmp and updated the linked images.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 56343cd has been approved by nikomatsakis

[nikomatsakis]

pretty. :)

[bors]

⌛️ Testing commit 56343cd with merge badc23b...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt