Implement a generic Destination Propagation optimization on MIR
This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954, and then explored by me in https://github.com/rust-lang/rust/pull/71003, and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed).
The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default, some followup work on it is still needed:
* Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress`, which caused trouble in my last attempt, but didn't go much in depth here.
* We can also enable the pass only at `opt-level=2` and higher, if it is too slow to run in debug mode, but fine when optimizations run anyways.
* Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this.
* Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine, or if not, merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622).
Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.
Rollup of 14 pull requests
Successful merges:
- #73963 (deny(unsafe_op_in_unsafe_fn) in libstd/path.rs)
- #75099 (lint/ty: move fns to avoid abstraction violation)
- #75502 (Use implicit (not explicit) rules for promotability by default in `const fn`)
- #75580 (Add test for checking duplicated branch or-patterns)
- #76310 (Add `[T; N]: TryFrom<Vec<T>>` (insta-stable))
- #76400 (Clean up vec benches bench_in_place style)
- #76434 (do not inline black_box when building for Miri)
- #76492 (Add associated constant `BITS` to all integer types)
- #76525 (Add as_str() to string::Drain.)
- #76636 (assert ScalarMaybeUninit size)
- #76749 (give *even better* suggestion when matching a const range)
- #76757 (don't convert types to the same type with try_into (clippy::useless_conversion))
- #76796 (Give a better error message when x.py uses the wrong stage for CI)
- #76798 (Build fixes for RISC-V 32-bit Linux support)
Failed merges:
r? `@ghost`
give *even better* suggestion when matching a const range
notice that the err already has "constant defined here"
so this is now *exceedingly clear*
extension to #76222
r? @estebank
assert ScalarMaybeUninit size
I noticed most low-level Miri types have such an assert but `ScalarMaybeUninit` does not, so let's add that. Good t see that the `Option`-like optimization kicks in and this is no bigger than `Scalar`. :)
r? @oli-obk
Add associated constant `BITS` to all integer types
Recently I've regularly come across this snippet (in a few different crates, including `core` and `std`):
```rust
std::mem::size_of<usize>() * 8
```
I think it's time for a `usize::BITS`.
lint/ty: move fns to avoid abstraction violation
This PR moves `transparent_newtype_field` and `is_zst` to `LateContext` where they are used, rather than being on the `VariantDef` and `TyS` types, hopefully addressing @eddyb's concern [from this comment](https://github.com/rust-lang/rust/pull/74340#discussion_r456534910).
Wrap recursive predicate evaluation with `ensure_sufficient_stack`
I haven't been able to come up with a minimized test case for #76770,
but this fixes a stack overflow in rustc as well.
Dogfood new_uninit and maybe_uninit_slice in rustc_arena
Dogfoods a few cool `MaybeUninit` related features in the compiler's rustc_arena crate.
Split off from #76821
r? `@oli-obk`
Some MIR statements and terminators have an (undocumented...) invariant
that some of their input and outputs must not overlap. This records
conflicts between locals used in these positions.
compare generic constants using `AbstractConst`s
This is a MVP of rust-lang/compiler-team#340. The changes in this PR should only be relevant if `feature(const_evaluatable_checked)` is enabled.
~~currently based on top of #76559, so blocked on that.~~
r? `@oli-obk` cc `@varkor` `@eddyb`
Issue 72408 nested closures exponential
This fixes#72408.
Nested closures were resulting in exponential compilation time.
This PR is enhancing asymptotic complexity, but also increasing the constant, so I would love to see perf run results.
[mir-opt] Disable the `ConsideredEqual` logic in SimplifyBranchSame opt
The logic is currently broken and we need to disable it to fix a beta
regression (see #76803)
r? `@oli-obk`
Mostly to fix ui/issues/issue-37311-type-length-limit/issue-37311.rs.
Most parts of the compiler can handle deeply nested types with a lot
of duplicates just fine, but some parts still attempt to naively
traverse type tree.
Before such problems were caught by type length limit check,
but now these places will have to be changed to handle
duplicated types gracefully.
