summary refs log tree commit diff
path: root/compiler/rustc_monomorphize/src
AgeCommit message (Collapse)AuthorLines
2023-09-27Auto merge of #116163 - compiler-errors:lazyness, r=oli-obkbors-1/+1
Don't store lazyness in `DefKind::TyAlias` 1. Don't store lazyness of a type alias in its `DefKind`, but instead via a query. 2. This allows us to treat type aliases as lazy if `#[feature(lazy_type_alias)]` *OR* if the alias contains a TAIT, rather than having checks for both in separate parts of the codebase. r? `@oli-obk` cc `@fmease`
2023-09-26subst -> instantiatelcnr-4/+4
2023-09-26Don't store lazyness in DefKindMichael Goulet-1/+1
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-14/+14
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-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-14/+14
2023-09-19adjust constValue::Slice to work for arbitrary slice typesRalf Jung-1/+1
2023-09-19move ConstValue into mirRalf Jung-6/+7
this way we have mir::ConstValue and ty::ValTree as reasonably parallel
2023-09-14move required_consts check to general post-mono-check functionRalf Jung-2/+2
2023-09-14Auto merge of #115804 - RalfJung:valtree-to-const-val, r=oli-obkbors-33/+9
consistently pass ty::Const through valtrees Some drive-by things extracted from https://github.com/rust-lang/rust/pull/115748.
2023-09-14Auto merge of #115817 - fee1-dead-contrib:fix-codegen, r=oli-obkbors-3/+4
treat host effect params as erased in codegen This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`. r? `@oli-obk`
2023-09-14treat host effect params as erased generics in codegenDeadbeef-3/+4
This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`.
2023-09-14found another place where we can eval() a const, and go through valtreesRalf Jung-33/+9
2023-09-14cleanup op_to_const a bit; rename ConstValue::ByRef → IndirectRalf Jung-1/+1
2023-09-14use AllocId instead of Allocation in ConstValue::ByRefRalf Jung-2/+3
2023-09-05Rollup merge of #115492 - Enselic:large-box-move, r=oli-obkMatthias Krüger-10/+91
Allow `large_assignments` for Box/Arc/Rc initialization Does the `stop linting in box/arc initialization` task of #83518. r? `@oli-obk` who is E-mentor.
2023-09-05Rollup merge of #115353 - Enselic:no-optimized-mir, r=oli-obkMatthias Krüger-3/+15
Emit error instead of ICE when optimized MIR is missing Closes #51388
2023-09-03Allow `large_assignments` for Box/Arc/Rc initializationMartin Nordholts-10/+91
Does the `stop linting in box/arc initialization` task of 83518.
2023-08-30Emit error instead of ICE when optimized MIR is missingMartin Nordholts-3/+15
Closes 51388.
2023-08-28Auto merge of #114774 - Enselic:less-move-size-noise, r=oli-obkbors-35/+46
Avoid duplicate `large_assignments` lints By checking for overlapping spans. This PR does the "reduce noisiness" task in #83518. r? `@oli-obk` who added E-mentor and E-help-wanted and wrote the initial code. (The fix itself is in https://github.com/rust-lang/rust/pull/114774/commits/dc82736677a134a1b52def496db111681c053e82. The two commits before that are just small refactorings.)
2023-08-24when terminating during unwinding, show the reason whyRalf Jung-20/+12
2023-08-20give some unwind-related terminators a more clear nameRalf Jung-2/+2
2023-08-13Avoid duplicate `large_assignments` lintsMartin Nordholts-1/+10
By checking for overlapping spans.
2023-08-13rustc_monomorphize: Reduce check_move_size() indentationMartin Nordholts-27/+26
2023-08-13rustc_monomorphize: Add check_move_size() helperMartin Nordholts-34/+37
2023-08-07Store the laziness of type aliases in the DefKindLeón Orell Valerian Liehr-1/+1
2023-08-02avoid 'miri' when refering to the shared interpreterRalf Jung-7/+7
2023-07-27Rollup merge of #113872 - nnethercote:tweak-cgu-sorting, r=pnkfelixMatthias Krüger-1/+1
Tweak CGU sorting in a couple of places. In `base.rs`, tweak how the CGU size interleaving works. Since #113777, it's much more common to have multiple CGUs with identical sizes. With the existing code these same-sized items ended up in the opposite-to-desired order due to the stable sorting. The code now starts with a reverse sort (like is done in `partitioning.rs`) which gives the behaviour we want. This doesn't matter much for perf, but makes profiles in `samply` look more like what we expect. In `partitioning.rs`, we can use `sort_by_key` instead of `sort_by_cached_key` because `CGU::size_estimate()` is cheap. (There is an identical CGU sort earlier in that function that already uses `sort_by_key`.) r? `@pnkfelix`
2023-07-23more clippy::style fixes:Matthias Krüger-4/+1
get_first single_char_add_str unnecessary_mut_passed manual_map manual_is_ascii_check
2023-07-23fix some clippy::style findingsMatthias Krüger-5/+6
comparison_to_empty iter_nth_zero for_kv_map manual_next_back redundant_pattern
2023-07-20Tweak CGU sorting in a couple of places.Nicholas Nethercote-1/+1
In `base.rs`, tweak how the CGU size interleaving works. Since #113777, it's much more common to have multiple CGUs with identical sizes. With the existing code these same-sized items ended up in the opposite-to-desired order due to the stable sorting. The code now starts with a reverse sort (like is done in `partitioning.rs`) which gives the behaviour we want. This doesn't matter much for perf, but makes profiles in `samply` look more like what we expect. In `partitioning.rs`, we can use `sort_by_key` instead of `sort_by_cached_key` because `CGU::size_estimate()` is cheap. (There is an identical CGU sort earlier in that function that already uses `sort_by_key`.)
2023-07-19Change the primary CGU merging algorithm.Nicholas Nethercote-14/+66
Instead of repeatedly merging the two smallest CGUs, we now use a merging algorithm that aims to minimize the duplication of inlined functions. `exa-0.10.1` was one benchmark that saw particularly good results. The old CGU stats: ``` INTERNALIZE - unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined) - placed items: 3834 (1216 root + 2618 inlined), placed size: 154552 (77219 root + 77333 inlined) - placed/unique items ratio: 1.38, placed/unique size ratio: 1.27 - CGUs: 16, mean size: 9659.5, sizes: [11791, 11634, 11173, 10987, 10939, 10507, 9992, 9813, 9593, 9580, 9030, 8447, 7975, 7961, 7876, 7254] ``` The new CGU stats: ``` INTERNALIZE - unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined) - placed items: 3626 (1216 root + 2410 inlined), placed size: 147201 (77219 root + 69982 inlined) - placed/unique items ratio: 1.31, placed/unique size ratio: 1.21 - CGUs: 16, mean size: 9200.1, sizes: [11634, 10939, 10227, 9555, 9178, 9167, 8879, 8804, 8604, 8603 (x3), 8602 (x2), 8601, 8600] ``` The difference is in the number of inlined items. There are 1558 unique inlined items. With the old algorithm these were placed 2618 times, resulting in 1060 duplicates. With the new algorithm these were placed 2410 times, resulting in 852 duplicates. Also, the mean CGU size dropped from 9659.5 to 9200.1, and the CGU size distribution tightened, with the biggest one a little smaller and the smallest ones a little bigger.
2023-07-19Split the CGU merging loop.Nicholas Nethercote-20/+30
It has two conditions. This commit splits it in two, one per condition. The next commit will change the first loop.
2023-07-19Add `MonoItemData::inlined`.Nicholas Nethercote-17/+13
2023-07-17Ignore unreachable inlined items in `debug_dump`.Nicholas Nethercote-30/+18
They're quite rare, and ignoring them simplifies things quite a bit, and further reduces the number of calls to `MonoItem::size_estimate` to the number of placed items (one per root item, and one or more per reachable inlined item).
2023-07-17Store item size estimate in `MonoItemData`.Nicholas Nethercote-13/+16
This means we call `MonoItem::size_estimate` (which involves a query) less often: just once per mono item, and then once more per inline item placement. After that we can reuse the stored value as necessary. This means `CodegenUnit::compute_size_estimate` is cheaper.
2023-07-17Introduce `MonoItemData`.Nicholas Nethercote-10/+15
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the next commit will add another field.
2023-07-14refactor(rustc_middle): Substs -> GenericArgMahdi Dibaiee-36/+34
2023-07-08Replace RPITIT current impl with new strategy that lowers as a GATSantiago Pastorino-1/+0
2023-07-08Auto merge of #113484 - matthiaskrgr:rollup-goq2u0d, r=matthiaskrgrbors-24/+24
Rollup of 7 pull requests Successful merges: - #112931 (Enable zlib in LLVM on aarch64-apple-darwin) - #113158 (tests: unset `RUSTC_LOG_COLOR` in a test) - #113173 (CI: include workflow name in concurrency group) - #113335 (Reveal opaques in new solver) - #113390 (CGU formation tweaks) - #113399 (Structurally normalize again for byte string lit pat checking) - #113412 (Add basic types to SMIR) r? `@ghost` `@rustbot` modify labels: rollup
2023-07-08Rollup merge of #113390 - nnethercote:cgu-tweaks, r=wesleywiserMatthias Krüger-24/+24
CGU formation tweaks Minor improvements I found while trying out something bigger that didn't work out. r? ``@wesleywiser``
2023-07-07Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`Nilstrieb-4/+4
It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a some enum variants. Make it clear there these are only coercion to make it clear why only some pointer related "casts" are in the enum.
2023-07-06get rid of a bit more calls to poly_selectMichael Goulet-2/+2
2023-07-06Diagnose unsorted CGUs.Nicholas Nethercote-1/+7
An assertion failure was reported in #112946. This extra information will help diagnose the problem.
2023-07-06Minor comment fix.Nicholas Nethercote-3/+3
2023-07-06Remove the field name from `MonoItemPlacement::SingleCgu`.Nicholas Nethercote-4/+4
It's needless verbosity.
2023-07-06Use `iter()` instead of `iter_mut()` in one place.Nicholas Nethercote-1/+1
2023-07-06Make `UsageMap::get_user_items` infallible.Nicholas Nethercote-16/+16
It's nicer this way.
2023-06-26Tweak thread names for CGU processing.Nicholas Nethercote-0/+3
For non-incremental builds on Unix, currently all the thread names look like `opt regex.f10ba03eb5ec7975-cgu.0`. But they are truncated by `pthread_setname` to `opt regex.f10ba`, hiding the numeric suffix that distinguishes them. This is really annoying when using a profiler like Samply. This commit changes these thread names to a form like `opt cgu.0`, which is much better.
2023-06-26Improve ordering and naming of CGUs for non-incremental builds.Nicholas Nethercote-6/+27
Currently there are two problems. First, the CGUS don't end up in size order. The merging loop does sort by size on each iteration, but we don't sort after the final merge, so typically there is one CGU out of place. (And sometimes we don't enter the merging loop at all, in which case they end up in random order.) Second, we then assign names that differ only by a numeric suffix, and then we sort them lexicographically by name, giving us an order like this: regex.f10ba03eb5ec7975-cgu.1 regex.f10ba03eb5ec7975-cgu.10 regex.f10ba03eb5ec7975-cgu.11 regex.f10ba03eb5ec7975-cgu.12 regex.f10ba03eb5ec7975-cgu.13 regex.f10ba03eb5ec7975-cgu.14 regex.f10ba03eb5ec7975-cgu.15 regex.f10ba03eb5ec7975-cgu.2 regex.f10ba03eb5ec7975-cgu.3 regex.f10ba03eb5ec7975-cgu.4 regex.f10ba03eb5ec7975-cgu.5 regex.f10ba03eb5ec7975-cgu.6 regex.f10ba03eb5ec7975-cgu.7 regex.f10ba03eb5ec7975-cgu.8 regex.f10ba03eb5ec7975-cgu.9 These two problems are really annoying when debugging and profiling the CGUs. This commit ensures CGUs are sorted by name *and* reverse sorted by size. This involves (a) one extra sort by size operation, and (b) padding the numeric indices with zeroes, e.g. `regex.f10ba03eb5ec7975-cgu.01`. (Note that none of this applies for incremental builds, where a different hash-based CGU naming scheme is used.)
2023-06-22Tweak CGU size estimate code.Nicholas Nethercote-7/+8
- Rename `create_size_estimate` as `compute_size_estimate`, because that makes more sense for the second and subsequent calls for each CGU. - Change `CodegenUnit::size_estimate` from `Option<usize>` to `usize`. We can still assert that `compute_size_estimate` is called first. - Move the size estimation for `place_mono_items` inside the function, for consistency with `merge_codegen_units`.