50-110% compilation time regressions due to miri

[oli-obk]

It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR.

Perf data: http://perf.rust-lang.org/compare.html?start=cdcca786468a71375584bb48e3093790c91084f7&end=c90f68224b069f5bb2a80e30e2737e4bb17c1466&stat=instructions:u

cc @nikomatsakis @michaelwoerister

Important regressions to investigate

• tuple-stress | avg: 35.0% | min: 9.8% | max: 109.4%
  • clean-incremental is a >100% hit! The rest are small.
• tuple-stress-opt | avg: 45.9% | min: 23.1% | max: 109.1%
  • same, clean-incremental is a >100% hit!
• encoding-opt | avg: 48.9% | min: 7.0% | max: 97.6%
  • clean incremental-opt
  • patched incremental: println-opt
• encoding | avg: 56.3% | min: 18.1% | max: 94.9%
  • clean is ~ 20%, as is baseline incremental
  • incremental cases are almost 100%
• coercions-opt | avg: 46.9% | min: 31.8% | max: 74.6%
  • pretty universally bad, though incremental hurts worse
• coercions | avg: 37.0% | min: 24.3% | max: 66.6%
  • pretty universally bad, though incremental hurts worse
• html5ever-opt | avg: 18.3% | min: 5.6% | max: 41.3%
  • incremental
• inflate | avg: 29.4% | min: 1.3% | max: 40.4%
  • universally bad, though incremental hurts worse
• regex-opt | avg: -0.2% | min: -18.0% | max: 4.7%
  • patched incremental: byte frequencies-opt
• script-servo-opt | avg: 4.8% | min: 0.7% | max: 12.1%
  • clean incremental-opt
• script-servo | avg: 6.0% | min: 1.7% | max: 11.6%
  • clean incremental
• inflate-opt | avg: 7.7% | min: 1.2% | max: 11.6%
  • incremental cases primarily

[michaelwoerister]

I'm going to start with encoding ...

[nikomatsakis]

It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.

[nikomatsakis]

I just updated the tracking issue with that information. Most of them are incremental cases.

[michaelwoerister]

OK, for encoding clean incremental it's pretty clear: 58% of the execution time are spent in TyCtxt::const_eval() called from monomorphize::collector::collect_const(). Does that ring a bell, @oli-obk? I haven't had time yet to really look at the code in question.

[oli-obk]

We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustc_mir::interpret::const_eval=debug to just get the entry points). I'll check tomorrow morning

[oli-obk]

Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix

[oli-obk]

Only the incremental regressions were fixed. I'll investigate the others, too

New perf data: https://perf.rust-lang.org/compare.html?start=2018-03-08&end=02094271f28e88e64b66014726f1d996bf7acae3&stat=instructions%3Au

[oli-obk]

There have been a lot of perf optimizations for const eval over the last year. I think we're good now