-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve cgu naming and ordering #112946
Improve cgu naming and ordering #112946
Conversation
fecb794
to
d65ca60
Compare
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.)
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.
d65ca60
to
666b1b6
Compare
@bors r+ |
@bors rollup |
Rollup of 5 pull requests Successful merges: - rust-lang#112946 (Improve cgu naming and ordering) - rust-lang#113048 (Fix build on Solaris where fd-lock cannot be used.) - rust-lang#113100 (Fix display of long items in search results) - rust-lang#113107 (add check for ConstKind::Value(_) to in_operand()) - rust-lang#113119 (rustdoc: Reduce internal function visibility.) r? `@ghost` `@rustbot` modify labels: rollup
For some reason the fuchsia project's windows build of rustc started failing around the time of this PR with:
This PR seemed like the most likely candidate from the rollup. Any insight as to what would cause this? |
@ComputerDruid: yes, this PR is almost certainly the cause of that failure. Is it really Windows only? That would be pretty weird. There must be a wrinkle with the CGU naming I'm not aware of, but I looked over the code again and I can't see what it is. It seems like the kind of code where any problem should show up frequently on all platforms, not rarely and on a single platform. I see three possible paths forward.
What do you think? |
An assertion failure was reported in rust-lang#112946. This extra information will help diagnose the problem.
…, r=lqd Diagnose unsorted CGUs. An assertion failure was reported in rust-lang#112946. This extra information will help diagnose the problem. r? `@lqd`
I created #113402 for the third option mentioned above. |
Thanks for that! https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/rust-x64-windows/b8776317651163748305/overview is the first build with that PR and the error looks like:
The full output got somewhat interleaved, but here's 2 instances interleaved a bit:
|
Re: only happening on windows; yes, I've only seen this on our windows build. We don't actually use the windows build for anything right now (there's been some attempts to get fuchsia's developer tooling to build for windows, but as far as I know that work has not completed), so it's not really load-bearing like our linux build is. But it does show up on my build dashboard so I figured I'd raise the issue. You can actually see the config.toml we use, and the environment variables we set Comparing that to the config.toml from a working linux build the only difference I see that seems like it might be relevant is |
And when I tried switching |
Thanks for the updated info. This warrants its own issue, I have filed #113425, let's move the conversation there. |
PR rust-lang#112946 tweaked the naming of LLVM threads, but messed things up, resulting in threads on Windows having names like `optimize module {} regex.f10ba03eb5ec7975-cgu.0`. This commit removes the extraneous braces.
PR rust-lang#112946 tweaked the naming of LLVM threads, but messed things up slightly, resulting in threads on Windows having names like `optimize module {} regex.f10ba03eb5ec7975-cgu.0`. This commit removes the extraneous `{} `.
PR rust-lang#112946 tweaked the naming of LLVM threads, but messed things up slightly, resulting in threads on Windows having names like `optimize module {} regex.f10ba03eb5ec7975-cgu.0`. This commit removes the extraneous `{} `.
Some quality of life improvements when debugging and profiling CGU formation.
r? @wesleywiser