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