Prepare ConstVal for constant propagators and reduce `eval_const_expr` in MIR

[oli-obk]

rebased eager const eval over @eddyb 's MIR-constants PR #33130

fixes #29928
fixes #33252

1. MIR creation now only calls eval_const_expr on literals and negated literals
   • previously all const/static definitions were attempted to be translated, but could fail due to the fact that eval_const_expr can't eval all kinds of constants
   • since "unevaluable" constants are translated from MIR now, there was no reason to keep evaluating constants that aren't needed for array lengths or patterns
   • a next step would be to convert literals manually to MIR constants instead of using eval_const_expr_partial
2. ConstVal contains owned versions of struct fields, tuple fields, array elements and the repeat value
   • this will allow a hypothetical const propagator to munch an Rvalue::Aggregate into a constant
   • MIR construction can now generate constant aggregates in https://github.com/rust-lang/rust/blob/master/src/librustc_mir/build/scope.rs#L544-L546 and https://github.com/rust-lang/rust/blob/master/src/librustc_mir/build/scope.rs#L586-L588
3. drive-by fixes for #33252, #33031, #31384 + tests

r? @eddyb

[eddyb]

@oli-obk I disagree with putting MIR constant aggregates in ConstVal.
Constant propagation on MIR can use special structures to express arbitrary knowledge beyond what constant evaluation needs to understand, and I think it's better to just have a cheap ConstVal that can be passed around (in miri I believe this is PrimVal, @tsion correct me if I'm wrong).

[oli-obk]

I'm not sure I understand. ConstVal is pretty cheap to pass around. It went from 32 bytes to 48 in my changes, and once we can merge the Struct variant into the Tuple by removing the names, it'll be back to 32 bytes. And the size isn't really relevant as it's never cloned. (for reference: PrimVal has 24 bytes).

We can refactor ConstVal into multiple Literal variants in MIR. One for PrimVal and one for aggregates, but we can do that when there's need. Right now we already have a structure that's holding our constants.

[eddyb]

@oli-obk Yes, but you can't copy the ConstVal around which is more useful IMO than representing MIR rvalues in a redundant way.
I don't think we need aggregate literals in the MIR.
They're rvalues because that keeps things simple, and again, Vec<ConstVal> isn't going to help constant propagation, which would need to use something like Vec<MaybeConstant>.

[oli-obk]

I don't think we need aggregate literals in the MIR. They're rvalues because that keeps things simple,

When I suggested that on #rust-internals, I was told that we should end up merging aggregates that consist solely of constants into a constant aggregate.

and again, Vec isn't going to help constant propagation, which would need to use something like Vec.

Ah, we're talking about different structures. The fact that constprop exists should not change the MIR. The MIR should represent the code as is. All constant propagation can do is manipulate that code.

The constant propagation pass can have internal datastructures that store additional info about certain temp/var decls. This way the const prop pass can propagate more than constants (it can do move-skips like a -> b -> c to a -> c where a is not a constant)

[eddyb]

@oli-obk Ah, do you have a link to that discussion?
Maybe they were onto something I'm not immediately seeing.
Either way, I want more opinions on this before we proceed.
cc @rust-lang/compiler @nagisa

[oli-obk]

https://botbot.me/mozilla/rust-internals/2016-02-04/?msg=59352908&page=3

[bors]

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

[bors]

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

[oli-obk]

@eddyb any update on the design decision?

+rebased

[eddyb]

@rust-lang/compiler, do we want to discuss this PR today?
I'm worried about recursive ConstVal since I'd only use ConstVal for leaves in the MIR.

[nikomatsakis]

@eddyb

do we want to discuss this PR today?

let's discuss tomorrow, along with a bit more about constants in general

[oli-obk]

Did the discussion yield any results wrt aggregate constants?

[nikomatsakis]

We never did talk about it :(

[bors]

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

[oli-obk]

since my original notion was to not have aggregates in MIR, and @eddyb feels that way, too, I'll close this.