Reimplement ConstProp using DataflowConstProp

[cjgillot]

This PR attempts to remove the current ConstProp optimization, and replace it by an implementation based on DataflowConstProp.

The current ConstProp twists the MIR interpreter to do things it is not designed to do, including manipulating generic types. Meanwhile, @jachris has implemented a new DataflowConstProp pass that only uses a few chosen methods for arithmetic.

The main change concerns how propagatable places and operations are tracked. In the current ConstProp, all places are tracked and all operations executed, and we removed wrong or non-propagatable results. This new implementation does the opposite : place tracking is opt-in, and we only propagate supported operations. I believe this approach to be less risky from a soundness point of view.

As a consequence, this new implementation is more restricted. The main limitation is that we stop propagating inside a basic block, and only propagate SSA locals. This makes the implementation simpler, and is more consistent with this "opt-in" logic.

Some operations are added inside this PR (transmutes, algebraic simplifications, Len operations). The handling of statics and non-scalar consts are left to a follow-up PR.

This PR does not remove the const-prop lints (arithmetic overflow and unconditional panic), as I need to design a way to pass more span information around.

There has been quite a few perf runs below. Marking as ready for review, since I removed the massive regressions on diesel/keccak/serde. Kept as waiting-on-author until I bless CI.

Regressed optimizations:

• array indexing;
• non-scalar constants;
• assignment of immutable statics;
• creating rvalues with non-scalar types;
• integer-to-pointer transmutes.

Based on #110728, #110732, #110820

[bors]

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

[bors]

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

[cjgillot]

@Zalathar This commit blesses the coverage map. However, I have no idea how to check that it is still correct. What do you recommend?

[Zalathar]

As a rule of thumb, any PR that doesn't touch coverage-specific code should feel free to just re-bless these.

(They're unfortunately quite sensitive to changes in MIR lowering/optimization, in a way that tends to result in different but equivalent mappings.)

[Zalathar]

In particular, as long as the run-coverage tests still pass, then any changes to the mappings are probably just noise.

(Those tests only run if the profiler runtime is enabled in config.toml, so they don't run by default in dev builds or on PRs, but they do run in the full CI before merging.)

[Zalathar]

Looking at the actual diff, it seems like some MIR statements that were previously being optimized out are no longer being optimized out. Nothing to worry about from a coverage perspective.

[bors]

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

[cjgillot]

I'd like to close this PR and pursue another direction for ConstProp.

#109597 creates a general framework for value analyses. I believe that implementing constant-folding in this pass can achieve the same level as what this PR proposes, while being more flexible:

• we'd only use the interpreter arithmetic API, like dataflow const-prop does, and allow removing ConstPropNonsense;
• that pass would only propagate whole values, simplifying state storage, and leaving the per-place to the dataflow version;
• that pass would leverage arithmetic identities over unknown values, which const-prop cannot do;
• that pass may be able to avoid duplicating constant allocations.

[oli-obk]

That makes sense

[RalfJung]

that pass would leverage arithmetic identities over unknown values, which const-prop cannot do;

const-prop can simplify some things here, right, like x*0 -> 0 or x+0 -> x?

[cjgillot]

Yes, but it cannot do x - x = 0, which #116012 could (in #111344).