Remove storage markers if they won't be used during code generation

[tmiasko]

The storage markers constitute a substantial portion of all MIR
statements. At the same time, for builds without any optimizations,
the storage markers have no further use during and after MIR
optimization phase.

If storage markers are not necessary for code generation, remove them.

[rust-highfive]

r? @estebank

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

[jonas-schievink]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 638ae965adce2470ddf9937dc0674af9b490622e with merge 2cb5cb2ebd84701a032939c589afbc536d832a40...

[tmiasko]

Thanks for perf-run. At this point it is mostly an experiment.

r? @ghost

[bors]

☀️ Try build successful - checks-actions
Build commit: 2cb5cb2ebd84701a032939c589afbc536d832a40 (2cb5cb2ebd84701a032939c589afbc536d832a40)

[rust-timer]

Queued 2cb5cb2ebd84701a032939c589afbc536d832a40 with parent f392479, future comparison URL.

[rust-timer]

Finished benchmarking try commit (2cb5cb2ebd84701a032939c589afbc536d832a40): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[tmiasko]

An improvement for full and incremental builds of larger benchmarks. A minor regression for very small benchmarks.

• full: style-servo-debug -1.2%, cranelift-codegen-debug -1.0%, cargo-debug -0.4%.
• incr-unchanged: style-servo-debug -1.4%, cranelift-codegen-debug -2.5%, cargo-debug: -1.5%
• a big regression in incr-patched for clap-rs-debug +33.9% as a result of an additional codegen unit (size estimates used for partitioning are based on the total number of statements, which are changed by this PR).

[tmiasko]

This a simple transformation removing storage markers at opt-level=0 where they won't have any further use. The CTFE having its own dedicated MIR will be unaffected.

r? @wesleywiser

[estebank]

Should do a perf run for the new code then?

[tmiasko]

A new perf run would be nice to have. Thanks.

[estebank]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

[bors]

⌛ Trying commit 5bc26c8ece9b697078c730fff254e297afacba6b with merge 07d546cab150e55802417ec8b182be1a5522ad45...

[bors]

☀️ Try build successful - checks-actions
Build commit: 07d546cab150e55802417ec8b182be1a5522ad45 (07d546cab150e55802417ec8b182be1a5522ad45)

[bors]

⌛ Testing commit 31c01be3f262afb19a28fe79d0889905171f3e9f with merge 01bf843c8bba585821820c45b7605889f914a9e5...

[bors]

💔 Test failed - checks-actions

[tmiasko]

Rebased and added -O flag to a try_identity codegen test that requires storage markers so that MIR optimization applies.

[oli-obk]

@bors r=wesleywiser,oli-obk

[bors]

📌 Commit 57de468 has been approved by wesleywiser,oli-obk

[bors]

⌛ Testing commit 57de468 with merge 09db057...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser,oli-obk
Pushing 09db057 to master...

[RalfJung]

Storage markers are also used by Miri, and this caused some really strange test failures where we fail to detect some UB with optimizations enabled. I am not sure what is going on...

FWIW, would be good to ping @rust-lang/miri for MIR optimization changes that could affect UB detection. This is the second time in a week that I had to dig through rustc PR history to figure out why a test suddenly fails.^^