about summary refs log tree commit diff
path: root/compiler/rustc_mir_transform
AgeCommit message (Collapse)AuthorLines
2023-10-05Replace LocationExtended with DefLocation in SsaLocalsTomasz Miąsko-27/+11
2023-10-05Remove small dominators optimization from SsaLocalsTomasz Miąsko-41/+23
The optimization is now part of the general implementation.
2023-10-05move subtyper change reveal_allouz-a-3/+9
2023-10-04Remove mir::LocalDecl::internal.Camille GILLOT-11/+7
2023-10-03Auto merge of #115301 - Zalathar:regions-vec, r=davidtwcobors-112/+115
coverage: Allow each coverage statement to have multiple code regions The original implementation of coverage instrumentation was built around the assumption that a coverage counter/expression would be associated with *up to one* code region. When it was discovered that *multiple* regions would sometimes need to share a counter, a workaround was found: for the remaining regions, the instrumentor would create a fresh expression that adds zero to the existing counter/expression. That got the job done, but resulted in some awkward code, and produces unnecessarily complicated coverage maps in the final binary. --- This PR removes that tension by changing `StatementKind::Coverage`'s code region field from `Option<CodeRegion>` to `Vec<CodeRegion>`. The changes on the codegen side are fairly straightforward. As long as each `CoverageKind::Counter` only injects one `llvm.instrprof.increment`, the rest of coverage codegen is happy to handle multiple regions mapped to the same counter/expression, with only minor option-to-vec adjustments. On the instrumentor/mir-transform side, we can get rid of the code that creates extra (x + 0) expressions. Instead we gather all of the code regions associated with a single BCB, and inject them all into one coverage statement. --- There are several patches here but they can be divided in to three phases: - Preparatory work - Actually switching over to multiple regions per coverage statement - Cleaning up So viewing the patches individually may be easier.
2023-10-03coverage: Remove `next_id` methods from counter/expression IDsZalathar-2/+2
When these methods were originally written, I wasn't aware that `newtype_index!` already supports addition with ordinary numbers, without needing to unwrap and re-wrap.
2023-10-03coverage: Remove code for making expression copies of BCB countersZalathar-14/+2
Now that coverage statements can have multiple code regions attached to them, this code is never used.
2023-10-03coverage: Store each BCB's code regions in one coverage statementZalathar-21/+28
If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-10-03coverage: Let each coverage statement hold a vector of code regionsZalathar-18/+17
This makes it possible for a `StatementKind::Coverage` to hold more than one code region, but that capability is not yet used.
2023-10-03coverage: Update comments/logs that referred to `CoverageSpan`Zalathar-20/+20
The concrete type `CoverageSpan` is no longer used outside of the `spans` module. This is a separate patch to avoid noise in the preceding patch that actually encapsulates coverage spans.
2023-10-03coverage: Encapsulate coverage spansZalathar-54/+63
By encapsulating the coverage spans in a struct, we can change the internal representation without disturbing existing call sites. This will be useful for grouping coverage spans by BCB. This patch includes some changes that were originally in #115912, which avoid the need for a particular test to deal with coverage spans at all. (Comments/logs referring to `CoverageSpan` are updated in a subsequent patch.)
2023-10-02have better explanation for `relate_types`ouz-a-7/+14
2023-10-02change is_subtype to relate_typesouz-a-3/+21
2023-10-02Add docs, remove code, change subtyper codeouz-a-9/+12
2023-10-02subtyping_projectionsouz-a-0/+59
2023-10-01Remove outdated comment.Camille GILLOT-2/+0
2023-10-01Rename lint pass.Camille GILLOT-7/+7
2023-10-01Do not check for impossible predicates in const-prop lint.Camille GILLOT-37/+0
2023-10-01Use DefKind to check for generator.Camille GILLOT-4/+4
2023-09-29Auto merge of #115759 - oli-obk:open_drop_from_non-ADT, r=lcnrbors-10/+25
Reveal opaque types before drop elaboration fixes https://github.com/rust-lang/rust/issues/113594 r? `@cjgillot` cc `@JakobDegen` This pass was introduced in https://github.com/rust-lang/rust/pull/110714 I moved it before drop elaboration (which only cares about the hidden types of things, not the opaque TAIT or RPIT type) and set it to run unconditionally (instead of depending on the optimization level and whether the inliner is active)
2023-09-28Only visit reachable nodes in SsaLocals.Camille GILLOT-8/+4
2023-09-28Skip reinterning if nothing changedOli Scherer-0/+4
2023-09-28Strip `OpaqueCast` during `RevealAll`.Oli Scherer-0/+19
2023-09-28Remove unnecessary generator-check, which also fixes the issue within async ↵Oli Scherer-5/+0
functions
2023-09-28Unconditionally run `RevealAll` pass and run it earlierOli Scherer-5/+1
2023-09-28Some tracing cleanupsOli Scherer-0/+1
2023-09-28Rollup merge of #116211 - matthiaskrgr:clippy3, r=compiler-errorsMatthias Krüger-6/+3
more clippy complextity fixes redundant_guards, useless_format, clone_on_copy
2023-09-27fix clippy::{redundant_guards, useless_format}Matthias Krüger-6/+3
2023-09-27Auto merge of #109597 - cjgillot:gvn, r=oli-obkbors-2/+578
Implement a global value numbering MIR optimization The aim of this pass is to avoid repeated computations by reusing past assignments. It is based on an analysis of SSA locals, in order to perform a restricted form of common subexpression elimination. By opportunity, this pass allows for some simplifications by combining assignments. For instance, this pass could be able to see through projections of aggregates to directly reuse the aggregate field (not in this PR). We handle references by assigning a different "provenance" index to each `Ref`/`AddressOf` rvalue. This ensure that we do not spuriously merge borrows that should not be merged. Meanwhile, we consider all the derefs of an immutable reference to a freeze type to give the same value: ```rust _a = *_b // _b is &Freeze _c = *_b // replaced by _c = _a ```
2023-09-27Auto merge of #116166 - Zalathar:unreachable, r=cjgillotbors-1/+5
Skip MIR pass `UnreachablePropagation` when coverage is enabled When coverage instrumentation and MIR opts are both enabled, coverage relies on two assumptions: - MIR opts that would delete `StatementKind::Coverage` statements instead move them into bb0 and change them to `CoverageKind::Unreachable`. - MIR opts won't delete all `CoverageKind::Counter` statements from an instrumented function. Most MIR opts naturally satisfy the second assumption, because they won't remove coverage statements from bb0, but `UnreachablePropagation` can do so if it finds that bb0 is unreachable. If this happens, LLVM thinks the function isn't instrumented, and it vanishes from coverage reports. A proper solution won't be possible until after per-function coverage info lands in #116046, but for now we can avoid the problem by turning off this particular pass when coverage instrumentation is enabled. --- cc `@cjgillot` since I found this while investigating coverage problems encountered by #113970 `@rustbot` label +A-code-coverage +A-mir-opt
2023-09-26Auto merge of #116144 - lcnr:subst-less, r=oli-obkbors-10/+13
subst -> instantiate continues #110793, there are still quite a few uses of `subst` and `substitute`, but changing them all in the same PR was a bit too much, so I've stopped here for now.
2023-09-26Explicit simplify_place.Camille GILLOT-8/+19
2023-09-26const-eval: make misalignment a hard errorRalf Jung-32/+6
2023-09-26Skip MIR pass `UnreachablePropagation` when coverage is enabledZalathar-1/+5
When coverage instrumentation and MIR opts are both enabled, coverage relies on two assumptions: - MIR opts that would delete `StatementKind::Coverage` statements instead move them into bb0 and change them to `CoverageKind::Unreachable`. - MIR opts won't delete all `CoverageKind::Counter` statements from an instrumented function. Most MIR opts naturally satisfy the second assumption, because they won't remove coverage statements from bb0, but `UnreachablePropagation` can do so if it finds that bb0 is unreachable. If this happens, LLVM thinks the function isn't instrumented, and it vanishes from coverage reports. A proper solution won't be possible until after per-function coverage info lands in #116046, but for now we can avoid the problem by turning off this particular pass when coverage instrumentation is enabled.
2023-09-26subst -> instantiatelcnr-10/+13
2023-09-25Use Vec::retain in remove_dead_blocks.Camille GILLOT-19/+24
2023-09-24Do not clone valtree and slice constants.Camille GILLOT-0/+31
2023-09-24Embed simplification into VnState.Camille GILLOT-77/+112
2023-09-24Workaround issue 112651.Camille GILLOT-1/+5
2023-09-24Add a paragraph about the assume bitwise equal.Camille GILLOT-0/+25
2023-09-24Do not check copiability.Camille GILLOT-12/+7
2023-09-24Add documentation.Camille GILLOT-1/+43
2023-09-24Add global value numbering pass.Camille GILLOT-2/+435
2023-09-23Enable drop_tracking_mir by default.Camille GILLOT-93/+18
2023-09-23Do not construct def_path_str for MustNotSuspend.Camille GILLOT-8/+29
2023-09-21Auto merge of #116010 - RalfJung:more-typed-immediates, r=oli-obkbors-11/+19
interpret: more consistently use ImmTy in operators and casts The diff in src/tools/miri/src/shims/x86/sse2.rs should hopefully suffice to explain why this is nicer. :)
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-90/+84
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
2023-09-21Prevent promotion of const fn calls in inline constsOli Scherer-1/+1
2023-09-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-89/+83
2023-09-21try to avoid some layout_of callsRalf Jung-2/+8
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 12:13:23 +0000