Collect statistics about MIR optimizations

[tmiasko]

For example -Zmir-opt-level=3 -Zmir-opt-stats:

 141639 const_prop Number of const propagations 54 const_prop Number of validation errors during const propagation 530284 dest_prop Number of destination propagations 389 dest_prop Number of functions with too many blocks to optimize 184 dest_prop Number of functions with too many locals to optimize 237034 inline Number of functions inlined 1542 instcombine Number of array length operations simplified 16396 instcombine Number of derer-refs operations simplified 15932 instcombine Number of equality comparisons with a const bool simplified 364113 instcombine Number of ref-derefs operations simplified 16452 match_branches Number of similar basic blocks merged together 51978 multiple_return_terminators Number of goto terminators replaced with a return 860 nrvo Number of functions eligible for named return value optimization 2137 remove_noop_landing_pads Number of no-op jumps folded 482515 remove_noop_landing_pads Number of no-op landing pads removed 10732 remove_unneeded_drops Number of unnecessary drop terminators removed 9 simplify Maximum number of iterations of control-flow-graph simplifier 4 simplify Maximum number of iterations of locals simplifier 792860 simplify Number of basic blocks merged with their only predecessor 2066039 simplify Number of dead basic blocks removed 39601 simplify Number of switch int terminators with identical successors replaced with a goto 961242 simplify Number of unused locals removed 156604 simplify_branches Number of false edges simplified to a goto 5397 simplify_branches Number of false unwinds simplified to a goto 2111 simplify_branches Number of true assertions simplified to a goto 3864 simplify_comparison_integral Number of switches on a result of integer comparison simplified to switches on integers 60 simplify_try Number of switches with equivalent targets replaced with a goto to the first target 26785 unreachable_prop Number of blocks with some of targets removed 

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[bjorn3]

This should be part of Session or TyCtxt. There may be multiple rustc sessions running in a single process. (for example when using RLS)

[tmiasko]

I experimented with different implementation approaches:

1. Statistics definitions are in the context together with their values.
2. Statistics definitions are in MIR passes, their values are stored in the context.
3. Statistics definitions and values are stored together with MIR passes.

I strongly prefer variants that put statistics definitions together with MIR passes that uses them. In that approach, adding and removing counters is trivial, additionally any unused counters are detected as such during compilation.

Values can be stored in the context if we want to support multiple rustc sessions in a single process, although it requires passing context to all those places where counters are used. But is there any real use-case? Why would you use rustc with debug-assertions and MIR optimizations counters inside the RLS?

[wesleywiser]

I agree with @bjorn3. We've tried pretty hard to move these sorts of things into Session and TyCtxt to allow running multiple sessions in the same process (both for RLS and eventually for one rustc process compiling multiple crates simultaneously).

Since this is essentially unstable, diagnostic data and doesn't effect the compilation artifacts, it may be worth bending that rule because, as you point out, having the counters defined in their MIR passes is quite nice. I don't personally feel comfortable approving that since this is a cross-cutting concern for the compiler as a whole and there may be others on the compiler team that have strong opinions about breaking that rule.

[petrochenkov]

r? @wesleywiser

[bors]

☔ The latest upstream changes (presumably #76659) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author 

[bors]

☔ The latest upstream changes (presumably #77430) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author 

[tmiasko]

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[bors]

☔ The latest upstream changes (presumably #77796) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author 

[bors]

☔ The latest upstream changes (presumably #77373) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author