Skip to content

Emit fewer assumes now that we have range metadata on parameters #135610

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

Closed
wants to merge 2 commits into from

Conversation

scottmcm
Copy link
Member

@scottmcm scottmcm commented Jan 17, 2025

We still need the assume for the target type's range, but we no longer need it for the source type's range.

The first stab at this regressed a test, but thanks to good advice in llvm/llvm-project#123278 (comment) the second commit here changes how we emit these range assertions to the form that LLVM apparently likes better (and, conveniently, is easier to emit too) which got that test passing again 🎉

Hopefully this means less crud for LLVM to churn through in opt builds...

@rustbot
Copy link
Collaborator

rustbot commented Jan 17, 2025

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Jan 17, 2025
@scottmcm
Copy link
Member 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 Jan 17, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 17, 2025
Emit fewer `assume`s now that we have `range` metadata on parameters

We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range.

Admittedly there's one test not properly handled by LLVM today, but it's synthetic, so I'd still be fine doing this and just updating the test once LLVM fixes the bug (llvm/llvm-project#123278).  All the other optimization tests still pass.

Hopefully this means less crud for LLVM to churn through in `opt` builds...
@bors
Copy link
Collaborator

bors commented Jan 17, 2025

⌛ Trying commit 959fd5f with merge f0c078e...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Jan 17, 2025

☀️ Try build successful - checks-actions
Build commit: f0c078e (f0c078eba80206e6a26efad8143155ffd3c02ba8)

@rust-timer

This comment has been minimized.

@rust-timer

This comment was marked as outdated.

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 17, 2025
@rust-log-analyzer

This comment has been minimized.

@scottmcm
Copy link
Member 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 Jan 17, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 17, 2025
Emit fewer `assume`s now that we have `range` metadata on parameters

We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range.

The first stab at this regressed a test, but thanks to good advice in llvm/llvm-project#123278 (comment) the second commit here changes how we emit these range assertions to the form that LLVM apparently likes better (and, conveniently, is easier to emit too) which got that test passing again 🎉

Hopefully this means less crud for LLVM to churn through in `opt` builds...
@bors
Copy link
Collaborator

bors commented Jan 17, 2025

⌛ Trying commit 8ab474a with merge 28bc505...

We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range.

Admittedly there's one test not properly handled by LLVM today, but it's synthetic, so I'd still be fine doing this and just updating the test once LLVM fixes the bug.  All the other optimization tests still pass.

Hopefully this means less crud for LLVM to churn through in `opt` builds...
Thank you dtcxzyw in LLVM 123278 for pointing out that we were doing this in a suboptimal way.
@bors
Copy link
Collaborator

bors commented Jan 17, 2025

☀️ Try build successful - checks-actions
Build commit: 28bc505 (28bc5054392a5de43833561ce0416a1f8cfdf227)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (28bc505): comparison URL.

Overall result: ❌ regressions - no 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.

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

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.8% [0.4%, 1.7%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -4.5%, secondary -1.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)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-4.5% [-4.5%, -4.5%] 1
Improvements ✅
(secondary)
-1.0% [-1.0%, -1.0%] 1
All ❌✅ (primary) -4.5% [-4.5%, -4.5%] 1

Cycles

Results (secondary -2.3%)

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
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.2%] 2
All ❌✅ (primary) - - 0

Binary size

Results (primary -0.0%, secondary 0.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)
0.0% [0.0%, 0.0%] 1
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 15
Improvements ✅
(primary)
-0.1% [-0.1%, -0.1%] 3
Improvements ✅
(secondary)
-0.0% [-0.0%, -0.0%] 1
All ❌✅ (primary) -0.0% [-0.1%, 0.0%] 4

Bootstrap: 763.784s -> 764.347s (0.07%)
Artifact size: 326.10 MiB -> 326.07 MiB (-0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 17, 2025
@scottmcm
Copy link
Member Author

Well, ok, then, I guess I'm leaving in the assumes :/

@scottmcm scottmcm marked this pull request as draft January 17, 2025 23:28
@scottmcm
Copy link
Member Author

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 17, 2025
@scottmcm scottmcm closed this Jan 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

6 participants