https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.66.1 2022-10-23T21:18:09+00:00 2022-10-23T21:18:09+00:00 Jakob Degen jakob.e.degen@gmail.com 2022-09-27T01:43:35+00:00 urn:sha1:be2401b8bfc824026b477f11b876b5611cb204c0 2022-10-21T09:33:15+00:00 Patrick Walton pcwalton@fb.com 2022-10-18T02:42:15+00:00 urn:sha1:da630ac79d03d12b12b73843e9fb92528db79eb3 indirect immutable freeze by-value function parameters. Right now, `rustc` only examines function signatures and the platform ABI when determining the LLVM attributes to apply to parameters. This results in missed optimizations, because there are some attributes that can be determined via analysis of the MIR making up the function body. In particular, `readonly` could be applied to most indirectly-passed by-value function arguments (specifically, those that are freeze and are observed not to be mutated), but it currently is not. This patch introduces the machinery that allows `rustc` to determine those attributes. It consists of a query, `deduced_param_attrs`, that, when evaluated, analyzes the MIR of the function to determine supplementary attributes. The results of this query for each function are written into the crate metadata so that the deduced parameter attributes can be applied to cross-crate functions. In this patch, we simply check the parameter for mutations to determine whether the `readonly` attribute should be applied to parameters that are indirect immutable freeze by-value. More attributes could conceivably be deduced in the future: `nocapture` and `noalias` come to mind. Adding `readonly` to indirect function parameters where applicable enables some potential optimizations in LLVM that are discussed in [issue 103103] and [PR 103070] around avoiding stack-to-stack memory copies that appear in functions like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These functions pass a large structure unchanged by value to a subfunction that also doesn't mutate it. Since the structure in this case is passed as an indirect parameter, it's a pointer from LLVM's perspective. As a result, the intermediate copy of the structure that our codegen emits could be optimized away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly nocapture noalias` in both the caller and callee. We already pass `nocapture noalias`, but we're missing `readonly`, as we can't determine whether a by-value parameter is mutated by examining the signature in Rust. I didn't have much success with having LLVM infer the `readonly` attribute, even with fat LTO; it seems that deducing it at the MIR level is necessary. No large benefits should be expected from this optimization *now*; LLVM needs some changes (discussed in [PR 103070]) to more aggressively use the `noalias nocapture readonly` combination in its alias analysis. I have some LLVM patches for these optimizations and have had them looked over. With all the patches applied locally, I enabled LLVM to remove all the `memcpy`s from the following code: ```rust fn main() { println!("Hello {}", 3); } ``` which is a significant codegen improvement over the status quo. I expect that if this optimization kicks in in multiple places even for such a simple program, then it will apply to Rust code all over the place. [issue 103103]: https://github.com/rust-lang/rust/issues/103103 [PR 103070]: https://github.com/rust-lang/rust/pull/103070 2022-09-26T08:14:45+00:00 Pietro Albini pietro.albini@ferrous-systems.com 2022-09-20T13:41:42+00:00 urn:sha1:3975d55d9888392cd738708b914442de9ac2bff5 2022-09-15T19:06:45+00:00 est31 MTest31@outlook.com 2022-02-27T06:07:36+00:00 urn:sha1:173eb6f407438dff732b1636b5134ff220da3f5b On later stages, the feature is already stable. Result of running: rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#" 2022-09-04T12:35:23+00:00 Deadbeef ent3rm4n@gmail.com 2022-08-31T13:28:55+00:00 urn:sha1:58c8823e3183611160207a47c9914bcbf84f9eb1 2022-09-04T12:35:23+00:00 Deadbeef ent3rm4n@gmail.com 2022-08-23T00:07:26+00:00 urn:sha1:075084f772abbc53263fc946c047a01e0dd65f80 2022-08-30T23:43:33+00:00 bors bors@rust-lang.org 2022-08-30T23:43:33+00:00 urn:sha1:f07d6e8c0a90a6b03dcf96366d0462c7c25962bd Rework definition of MIR phases to more closely reflect semantic concerns Implements most of rust-lang/compiler-team#522 . I tried my best to restrict this PR to the "core" parts of the MCP. In other words, this includes just enough changes to make the new definition of `MirPhase` make sense. That means there are a couple of FIXMEs lying around. Depending on what reviewers prefer, I can either fix them in this PR or send follow up PRs. There are also a couple other refactorings of the `rustc_mir_transform/src/lib.rs` file that I want to do in follow ups that I didn't leave explicit FIXMEs for. 2022-08-30T08:40:14+00:00 Jakob Degen jakob.e.degen@gmail.com 2022-07-10T01:04:38+00:00 urn:sha1:aad14c701e3fec7cde0db105774bb14d7f5d7582 2022-08-29T17:34:11+00:00 Nilstrieb 48135649+Nilstrieb@users.noreply.github.com 2022-08-20T18:40:08+00:00 urn:sha1:d1ef8180f956c9f1a7267e32491d65188f0aefd7 This reverts commit 326646074940222d602f3683d0559088690830f4. This is the revert against master, the beta revert was already done in #100538. 2022-08-12T20:28:15+00:00 Mark Rousskov mark.simulacrum@gmail.com 2022-08-09T13:56:13+00:00 urn:sha1:154a09dd913edc7db698b8a7230c720a8f0baa74