Rollup of 8 pull requests #137371
Merged
Rollup of 8 pull requests #137371
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `Box::new(T::default())` implementation of `Box::default` only had two stack copies in debug mode, compared to the current version, which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing `T` directly to the `Box` pointer, the stack usage in debug mode remains the same as the old version.
``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue rust-lang#124535 <rust-lang#124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ```
Currently many of them exceed 100 chars, which makes them painful to read on a terminal that is 100 chars wide.
I found the dialect/phase distinction quite confusing when I first read these comments. This commit clarifies things a bit.
The only visible change is to the filenames produce by `-Zdump-mir`. E.g. before and after: ``` h.main.003-000.analysis-post-cleanup.after.mir h.main.2-2-000.analysis-post-cleanup.after.mir ``` It also fixes a FIXME comment.
Also minimize some visibilities in the destination file.
`Postorder` has a `C: Customization<'tcx>` parameter, that gives it flexibility about how it computes successors. But in practice, there are only two `impls` of `Customization`, and one is for the unit type. This commit simplifies things by removing the generic parameter and replacing it with an `Option`.
…cking drops in MIR typeck
It's a misleading name, because it's not interned.
It's a bit weird.
As `unwrap_crate_local`, because it follows exactly the standard form of an `unwrap` function.
Because it has the same fields, and avoids the need to deconstruct the latter to construct the former.
The comments didn't make much sense to me. I asked Matthew Jasper on Zulip about it and they said: > I think that at the time I wanted to replace all (or most of) this > with a reference to the HIR Id of the variable. I'll give this a look > to see if it's still a reasonable idea, but removing the comments is > fine. and then: > I don't think that changing this to an HirId would be better, > recovering the information from the HIR seems like too much effort in > exchange for making the MIR a little smaller.
It's a very small and simple type.
The target feature names are, right now, based on the llvm target feature names. These mostly line up well with the names of [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`. There are a number of implied target features between the vector facilities (based on the [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table): - 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode. - 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. - 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. - 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one. - 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one. - 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one. - 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one. And then there are a number of facilities without any implied target features - 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode. - 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one. - 133 The guarded-storage facility is installed in the z/Architecture architectural mode. - 150 The enhanced-sort facility is installed in the z/Architecture architectural mode. - 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode. The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](https://github.com/llvm/llvm-project/blob/d49a2d2bc9c65c787bfa04ac8ece614da48a8cd5/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`.
…rochenkov Specify scope in `out_of_scope_macro_calls` lint ``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue rust-lang#124535 <rust-lang#124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ``` r? ```@petrochenkov```
…r=Amanieu add more `s390x` target features Closes rust-lang#88937 tracking issue: rust-lang#130869 The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel (and `/proc/cpuinfo`) uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`. There are a number of implied target features between the vector facilities (based on the [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table): - 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode. - 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. - 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. - 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one. - 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one. - 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one. - 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one. The remaining facilities do not have any implied target features (that we provide): - 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode. - 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one. - 133 The guarded-storage facility is installed in the z/Architecture architectural mode. - 150 The enhanced-sort facility is installed in the z/Architecture architectural mode. - 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode. The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](https://github.com/llvm/llvm-project/blob/d49a2d2bc9c65c787bfa04ac8ece614da48a8cd5/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`. I'll also update the `is_s390x_feature_supported` macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features. ``@Amanieu`` you had some reservations about the `"vector"` target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the `neural-network-processing-assist` even LLVM thought that was a bit much and shortened it to `nnp-assist`. Also for `vector-packed-decimal-enhancement facility 1` the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation. r? ``@Amanieu`` cc ``@uweigand`` ``@taiki-e``
…sage, r=Amanieu Reduce `Box::default` stack copies in debug mode The `Box::new(T::default())` implementation of `Box::default` only had two stack copies in debug mode, compared to the current version, which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing `T` directly to the `Box` pointer, the stack usage in debug mode remains the same as the old version. Another option would be to mark `Box::write` as `#[inline(always)]`, and change it's implementation to to avoid calling `MaybeUninit::write` (which creates a `MaybeUninit<T>` on the stack) and to use `ptr::write` instead. Fixes: rust-lang#136043
…nd-phases, r=RalfJung Clarify MIR dialects and phases I found the existing code and docs hard to understand. r? `@Zalathar`
…tomization, r=compiler-errors Simplify `Postorder` customization. `Postorder` has a `C: Customization<'tcx>` parameter, that gives it flexibility about how it computes successors. But in practice, there are only two `impls` of `Customization`, and one is for the unit type. This commit simplifies things by removing the generic parameter and replacing it with an `Option`. r? ````@saethlin````
…, r=matthewjasper Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck Fixes rust-lang#137288. See the comment I left on the probe. I'm not totally sure why this depends on *both* an unconstrained type parameter in the impl and a type error for the self type, but I think the fix is at least theoretically well motivated. r? ```@matthewjasper```
Tweaks in and around `rustc_middle` A bunch of tiny improvements I found while working on bigger things. r? ```@lcnr```
…chenkov Some codegen_llvm cleanups Using some more safe wrappers and thus being able to remove a large unsafe block. As a next step we should probably look into safe extern fns
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 9f48dedc97 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (71e06b9): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 773.178s -> 773.873s (0.09%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
out_of_scope_macro_callslint #128080 (Specify scope inout_of_scope_macro_callslint)s390xtarget features #135630 (add mores390xtarget features)Box::defaultstack copies in debug mode #136089 (ReduceBox::defaultstack copies in debug mode)Postordercustomization. #137299 (SimplifyPostordercustomization.)rustc_middle#137305 (Tweaks in and aroundrustc_middle)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup