Skip to content

Conversation

@scottmcm
Copy link
Member

@scottmcm scottmcm commented Mar 15, 2025

Having ALLOCs for these seems unhelpful, since it's extra stuff to keep track of, makes it harder for other passes to know what's in it (reversing a tag constant to a VariantIdx isn't trivial), and even in codegen it's arguably harder to get a None from a valtree than from seeing "oh, aggregate nothing with this VariantIdx".

Making constants for the discriminant(_n) is useful for putting in switchInts, and still happens with this PR. It's just for the full enum that we don't make consts (except for might-as-well-be-an-integer enums like Ordering, or ones that are actually ZSTs like const Option::<Infallible>::None).

This also adds a couple tests I've been using as I look at how we're doing enums in MIR. They're not really improved by this change materially, but they help motivate why I'm trying to tweak how the enums come out.

@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2025

r? @fmease

rustbot has assigned @fmease.
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 Mar 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Having `ALLOC`s for these seems quite unhelpful, since it's extra stuff to keep track of, makes it harder for other passes to know what's in it (reversing a tag constant to a `VariantIdx` isn't trivial), and in codegen it's arguably harder to get a `None` from a valtree than from seeing "oh, aggregate nothing with this `VariantIdx`".

Making constants for the `discriminant(_n)` is useful, and still happens.  Constants for primitives are helpful; for enums not so much.
@fmease
Copy link
Member

fmease commented Mar 15, 2025

r? compiler

@rustbot rustbot assigned SparrowLii and unassigned fmease Mar 15, 2025
@rust-log-analyzer

This comment has been minimized.

… *not* marking the issue as fixed, because it's really not.

(There MIR tests really need to be regressed with MIR tests, not with UI tests.)
@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 Mar 15, 2025
@bors
Copy link
Collaborator

bors commented Mar 15, 2025

⌛ Trying commit 41f6339 with merge e18ec78...

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 15, 2025
Stop making `const None` in GVN

Having `ALLOC`s for these seems unhelpful, since it's extra stuff to keep track of, makes it harder for other passes to know what's in it (reversing a tag constant to a `VariantIdx` isn't trivial), and even in codegen it's arguably harder to get a `None` from a valtree than from seeing "oh, aggregate nothing with this `VariantIdx`".

Making constants for the `discriminant(_n)` is useful for putting in `switchInt`s, and still happens with this PR.  It's just for the full enum that we don't make consts (except for might-as-well-be-an-integer enums like `Ordering`, or ones that are actually ZSTs like `const Option::<Infallible>::None`).

This also adds a couple tests I've been using as I look at how we're doing enums in MIR.  They're not really *improved* by this change materially, but they help motivate why I'm trying to tweak how the enums come out.
@bors
Copy link
Collaborator

bors commented Mar 15, 2025

☀️ Try build successful - checks-actions
Build commit: e18ec78 (e18ec7895190171d8837347d5500d58a4166c464)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (e18ec78): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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 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.3% [0.1%, 0.7%] 9
Regressions ❌
(secondary)
0.3% [0.2%, 0.7%] 16
Improvements ✅
(primary)
-0.3% [-0.4%, -0.3%] 2
Improvements ✅
(secondary)
-0.3% [-0.4%, -0.1%] 4
All ❌✅ (primary) 0.2% [-0.4%, 0.7%] 11

Max RSS (memory usage)

Results (primary -0.2%, secondary 3.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)
2.7% [0.9%, 5.2%] 4
Regressions ❌
(secondary)
5.1% [2.1%, 7.5%] 11
Improvements ✅
(primary)
-4.0% [-6.9%, -2.0%] 3
Improvements ✅
(secondary)
-4.5% [-6.4%, -3.2%] 3
All ❌✅ (primary) -0.2% [-6.9%, 5.2%] 7

Cycles

Results (primary 5.5%, secondary 2.8%)

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)
5.5% [1.3%, 12.7%] 17
Regressions ❌
(secondary)
2.8% [1.5%, 4.8%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 5.5% [1.3%, 12.7%] 17

Binary size

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

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.2% [0.0%, 0.8%] 28
Regressions ❌
(secondary)
0.1% [0.0%, 0.2%] 7
Improvements ✅
(primary)
-0.1% [-0.9%, -0.0%] 51
Improvements ✅
(secondary)
-0.1% [-0.4%, -0.0%] 21
All ❌✅ (primary) -0.0% [-0.9%, 0.8%] 79

Bootstrap: 774.866s -> 772.816s (-0.26%)
Artifact size: 365.06 MiB -> 365.10 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 Mar 15, 2025
@jieyouxu
Copy link
Member

r? mir-opt

@rustbot rustbot assigned saethlin and unassigned SparrowLii Mar 15, 2025
@scottmcm
Copy link
Member Author

nvm, looks like this is bad on its own and will need other things before it can be considered.

@scottmcm scottmcm closed this Mar 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

perf-regression Performance regression. 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants