Skip to content
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

Accelerate GVN a little #126991

Merged
merged 7 commits into from
Jul 31, 2024
Merged

Accelerate GVN a little #126991

merged 7 commits into from
Jul 31, 2024

Conversation

cjgillot
Copy link
Contributor

This PR addresses a few inefficiencies I've seen in callgrind profiles.

Commits are independent.

Only the first commit introduces a change in behaviour: we stop substituting some constant pointers. But we keep propagating their contents that have no provenance, so we don't lose much.

r? @saethlin

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 26, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jun 26, 2024

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@cjgillot
Copy link
Contributor Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 26, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 26, 2024
Accelerate GVN a little

This PR addresses a few inefficiencies I've seen in callgrind profiles.

Commits are independent.

Only the first commit introduces a change in behaviour: we stop substituting some constant pointers. But we keep propagating their contents that have no provenance, so we don't lose much.

r? `@saethlin`
@bors
Copy link
Contributor

bors commented Jun 26, 2024

⌛ Trying commit c633384 with merge dfaffed...

@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk self-assigned this Jun 26, 2024
@bors
Copy link
Contributor

bors commented Jun 26, 2024

☀️ Try build successful - checks-actions
Build commit: dfaffed (dfaffedda67fd2f26a394763df8cda0a5e58d672)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (dfaffed): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.5% [0.4%, 0.8%] 3
Regressions ❌
(secondary)
2.4% [0.2%, 4.5%] 2
Improvements ✅
(primary)
-0.4% [-0.7%, -0.2%] 3
Improvements ✅
(secondary)
-0.5% [-0.8%, -0.2%] 7
All ❌✅ (primary) 0.1% [-0.7%, 0.8%] 6

Max RSS (memory usage)

Results (primary -0.6%, secondary 2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
6.1% [2.9%, 9.3%] 2
Regressions ❌
(secondary)
4.9% [3.3%, 5.9%] 7
Improvements ✅
(primary)
-4.0% [-7.0%, -2.0%] 4
Improvements ✅
(secondary)
-4.8% [-7.7%, -3.4%] 3
All ❌✅ (primary) -0.6% [-7.0%, 9.3%] 6

Cycles

Results (primary 2.4%, secondary 2.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.4% [2.0%, 2.7%] 4
Regressions ❌
(secondary)
3.0% [2.6%, 3.5%] 15
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.7% [-4.6%, -2.8%] 2
All ❌✅ (primary) 2.4% [2.0%, 2.7%] 4

Binary size

Results (primary -0.1%, secondary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 4
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.1% [-0.6%, -0.0%] 55
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.4%] 3
All ❌✅ (primary) -0.1% [-0.6%, 0.0%] 59

Bootstrap: 695.46s -> 692.615s (-0.41%)
Artifact size: 326.69 MiB -> 326.64 MiB (-0.01%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jun 26, 2024
@@ -264,21 +265,29 @@ struct VnState<'body, 'tcx> {
impl<'body, 'tcx> VnState<'body, 'tcx> {
fn new(
tcx: TyCtxt<'tcx>,
body: &Body<'tcx>,
param_env: ty::ParamEnv<'tcx>,
ssa: &'body SsaLocals,
dominators: &'body Dominators<BasicBlock>,
local_decls: &'body LocalDecls<'tcx>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I think you could get this from the passed-in body now, rather than needing the parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they have different lifetimes. The caller will want to mutate part of the body, so we can only keep a reference to the local decls.

@saethlin
Copy link
Member

Hm. I think the behavior change here is more significant to compile time than any of the optimizations. Is that expected?

I ran this to build the standard library and dump MIR with each of the toolchains in the perf run

RUSTFLAGS="--emit=mir -Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals" cargo +dfaffedda67fd2f26a394763df8cda0a5e58d672 b --release -Zbuild-std --target=x86_64-unknown-linux-gnu

Then did a git diff --no-index on the old core MIR and the new one and I get:

 .../x86_64-unknown-linux-gnu/release/deps/core-5d5f6913076bfe42.mir              | 17178 ++++++++++++-------------------------
 1 file changed, 5525 insertions(+), 11653 deletions(-)

Almost all the net deletion is due to the MIR dumps having less const allocations. That's surprising to me. I can tell from the commits that this is caused by normalizing less... but why does this even matter? If these consts can just be deleted from the MIR, shouldn't they have been deduplicated in the first place by some other mechanism?

+ _3 = const {ALLOC0<imm>: &[u32; 3]};
+ _2 = const {ALLOC0<imm>: &[u32; 3]} as &[u32] (PointerCoercion(Unsize));
+ _3 = _9;
+ _2 = _9 as &[u32] (PointerCoercion(Unsize));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saethlin this is this kind of pattern.
The constant is still there, named main::promoted[0]. It's "evaluated" form const {ALLOC0<imm>: &[u32; 3]} does not appear in the MIR dump, so the dump does not print ALLOC0. This does not mean that ALLOC0 was not evaluated, just that it's not put in MIR and not printed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So are you saying there consts that get their allocations dumped, and some consts that don't? That seems like an undesirable property of MIR dumps, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, Ideally promoteds would just be regular statics, but lazily created in the MIR opt pipeline. This is blocked on various works around DefId creation, most importantly #115613. I guess we could add a special case for showing promoteds like we show other allocations for now, but that seems orthogonal to this PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Statics can't be generic so IMO they should be regular consts.

@cjgillot
Copy link
Contributor Author

About perf:

  • the main regression is for deep-vector, on a check build, so I'd classify this as noise;
  • for other regressions (webrender, ripgrep), detailed results show GVN taking less time, and LLVM taking more.

I'm very much tempted to leave this as-is.

@cjgillot cjgillot added perf-regression-triaged The performance regression has been triaged. A-mir-opt Area: MIR optimizations labels Jun 27, 2024
@oli-obk
Copy link
Contributor

oli-obk commented Jul 25, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Jul 25, 2024

📌 Commit 8279989 has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 25, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2024
Accelerate GVN a little

This PR addresses a few inefficiencies I've seen in callgrind profiles.

Commits are independent.

Only the first commit introduces a change in behaviour: we stop substituting some constant pointers. But we keep propagating their contents that have no provenance, so we don't lose much.

r? `@saethlin`
@bors
Copy link
Contributor

bors commented Jul 25, 2024

⌛ Testing commit 8279989 with merge 4f32f47...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jul 25, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 25, 2024
@oli-obk
Copy link
Contributor

oli-obk commented Jul 31, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Jul 31, 2024

📌 Commit 4067795 has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 31, 2024
@bors
Copy link
Contributor

bors commented Jul 31, 2024

⌛ Testing commit 4067795 with merge 28a58f2...

@bors
Copy link
Contributor

bors commented Jul 31, 2024

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 28a58f2 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 31, 2024
@bors bors merged commit 28a58f2 into rust-lang:master Jul 31, 2024
7 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Jul 31, 2024
@cjgillot cjgillot deleted the gvn-prof branch August 1, 2024 18:00
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (28a58f2): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.3%, 0.3%] 1
Regressions ❌
(secondary)
2.1% [2.1%, 2.1%] 1
Improvements ✅
(primary)
-0.4% [-0.4%, -0.3%] 2
Improvements ✅
(secondary)
-0.7% [-1.0%, -0.4%] 6
All ❌✅ (primary) -0.2% [-0.4%, 0.3%] 3

Max RSS (memory usage)

Results (primary 4.1%, secondary 1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
4.1% [3.2%, 5.0%] 2
Regressions ❌
(secondary)
4.1% [3.4%, 4.8%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.8% [-3.8%, -3.8%] 1
All ❌✅ (primary) 4.1% [3.2%, 5.0%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary -0.1%, secondary -0.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.1%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.2% [-0.6%, -0.0%] 56
Improvements ✅
(secondary)
-0.5% [-0.5%, -0.4%] 3
All ❌✅ (primary) -0.1% [-0.6%, 0.1%] 59

Bootstrap: 755.782s -> 757.595s (0.24%)
Artifact size: 336.64 MiB -> 336.69 MiB (0.01%)

@nnethercote
Copy link
Contributor

Nice binary size reductions :)

@Kobzol
Copy link
Contributor

Kobzol commented Aug 6, 2024

More improvements than regressions, and also nice binary size regressions, as Nick said.

@rustbot label: +perf-regression-triaged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-mir-opt Area: MIR optimizations merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.