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

Add #[optimize(none)] #128657

Merged
merged 3 commits into from
Jan 25, 2025
Merged

Add #[optimize(none)] #128657

merged 3 commits into from
Jan 25, 2025

Conversation

clubby789
Copy link
Contributor

cc #54882

This extends the optimize attribute to add none, which corresponds to the LLVM OptimizeNone attribute.

Not sure if an MCP is required for this, happy to file one if so.

@rustbot
Copy link
Collaborator

rustbot commented Aug 4, 2024

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 Aug 4, 2024
@clubby789
Copy link
Contributor Author

clubby789 commented Aug 4, 2024

While writing a codegen test, looks like there's some extra work to do -

pub fn none() -> i32 {
    2 + 2
}

emits overflow checks in opt-level=0 but not =1. It looks like with overflow checks disabled this is constant folded to 4, even in opt-level=0

@cjgillot
Copy link
Contributor

cjgillot commented Aug 4, 2024

You may need to skip mir opts too.

@clubby789
Copy link
Contributor Author

clubby789 commented Aug 4, 2024

I've turned off MIR opts in the tests for now, but I think ideally we'd want to skip running them for #[optimize(none)] functions - will look into that
While we could enable overflow checks (to match opt-level=0), I feel like if the main goal of opt-none is to make debugging easier then leaving them off is probably best.

@rust-log-analyzer

This comment has been minimized.

@clubby789
Copy link
Contributor Author

clubby789 commented Aug 4, 2024

Unhelpfully, LLVM doesn't seem to fully account for optnone: https://godbolt.org/z/8hs17bc44 - the constant is propogated from the inner function despite optnone: https://groups.google.com/g/llvm-dev/c/lqgPRW_akSU

@rustbot
Copy link
Collaborator

rustbot commented Aug 4, 2024

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@@ -554,6 +554,10 @@ fn run_runtime_cleanup_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
}

fn run_optimization_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
if body.optimization_disabled {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think this is actually correct - some of these should run in debug mode. Not sure how best to decide which passes should be omitted

Copy link
Member

Choose a reason for hiding this comment

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

This is indeed incorrect. There are required passes that must be run on every MIR for soundness IIRC.

@rust-lang/wg-mir-opt: Anyone willing to provide assistance to how to disable MIR optimizations while only keeping the required passes?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe check it against the opt level of the pass. If it runs on opt level 0, then don't disable it

Copy link
Contributor

Choose a reason for hiding this comment

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

From a brief look, there are 3 or 4 passes that need keeping, including marking the mir phase.
The easiest way would be to compute the list of passes based on the opt level, or tweak the pass manager to compare default opt level with this flag.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

compiler/rustc_attr/src/builtin.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_build/src/build/mod.rs Outdated Show resolved Hide resolved
@@ -554,6 +554,10 @@ fn run_runtime_cleanup_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
}

fn run_optimization_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
if body.optimization_disabled {
Copy link
Member

Choose a reason for hiding this comment

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

This is indeed incorrect. There are required passes that must be run on every MIR for soundness IIRC.

@rust-lang/wg-mir-opt: Anyone willing to provide assistance to how to disable MIR optimizations while only keeping the required passes?

@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 Aug 6, 2024
compiler/rustc_middle/src/mir/mod.rs Outdated Show resolved Hide resolved
@@ -554,6 +554,10 @@ fn run_runtime_cleanup_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
}

fn run_optimization_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
if body.optimization_disabled {
Copy link
Contributor

Choose a reason for hiding this comment

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

From a brief look, there are 3 or 4 passes that need keeping, including marking the mir phase.
The easiest way would be to compute the list of passes based on the opt level, or tweak the pass manager to compare default opt level with this flag.

@clubby789
Copy link
Contributor Author

Pushed an approach which adds a min_mir_opt_level to the pass trait, then removes any which are > 1 before running opts - this does seem a bit invasive

@cjgillot
Copy link
Contributor

@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 Aug 10, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 10, 2024
Add `#[optimize(none)]`

cc rust-lang#54882

This extends the `optimize` attribute to add `none`, which corresponds to the LLVM `OptimizeNone` attribute.

Not sure if an MCP is required for this, happy to file one if so.
@bors
Copy link
Contributor

bors commented Aug 10, 2024

⌛ Trying commit 4408092 with merge 334c324...

@bors
Copy link
Contributor

bors commented Aug 10, 2024

☀️ Try build successful - checks-actions
Build commit: 334c324 (334c3248c902c016532b42926eaa3defca560875)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (334c324): comparison URL.

Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.4%, secondary 3.6%)

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)
3.6% [3.6%, 3.6%] 1
Improvements ✅
(primary)
-0.4% [-0.4%, -0.4%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.4% [-0.4%, -0.4%] 1

Cycles

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

Binary size

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

Bootstrap: 762.637s -> 762.18s (-0.06%)
Artifact size: 339.23 MiB -> 339.29 MiB (0.02%)

@fee1-dead
Copy link
Member

Sorry for the late review.

r=me after addressing the nit and a rebase (if there are no changes to be reviewed additionally after the rebase)

@clubby789
Copy link
Contributor Author

My one concern is that #134082 added can_be_overridden to all MIR passes for forcing inlining, which is similar in description but only requires ForceInline, whereas is_required is true for many passes.
cc @davidtwco - do you think can_be_overridden can be replaced with the more granular is_required here?

Copy link
Member

@WaffleLapkin WaffleLapkin left a comment

Choose a reason for hiding this comment

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

nitpicks

compiler/rustc_mir_transform/src/pass_manager.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_transform/src/pass_manager.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_transform/src/pass_manager.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_transform/src/lib.rs Outdated Show resolved Hide resolved
@clubby789 clubby789 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 23, 2025
@WaffleLapkin
Copy link
Member

@bors r=fee1-dead,WaffleLapkin

@bors
Copy link
Contributor

bors commented Jan 24, 2025

📌 Commit 5ac95a5 has been approved by fee1-dead,WaffleLapkin

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 Jan 24, 2025
@bors
Copy link
Contributor

bors commented Jan 25, 2025

⌛ Testing commit 5ac95a5 with merge 6365178...

@bors
Copy link
Contributor

bors commented Jan 25, 2025

☀️ Test successful - checks-actions
Approved by: fee1-dead,WaffleLapkin
Pushing 6365178 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 25, 2025
@bors bors merged commit 6365178 into rust-lang:master Jan 25, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Jan 25, 2025
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (6365178): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.3% [0.3%, 0.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

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

Cycles

Results (primary 1.2%, secondary 1.7%)

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)
1.2% [1.0%, 1.4%] 2
Regressions ❌
(secondary)
1.7% [1.7%, 1.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.2% [1.0%, 1.4%] 2

Binary size

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

Bootstrap: 772.322s -> 771.261s (-0.14%)
Artifact size: 325.82 MiB -> 325.82 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

10 participants