-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rewrite lint_expectations in a single pass. #127313
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Rewrite lint_expectations in a single pass. This PR aims at reducing the perf regression from rust-lang#120924 (comment) with drive-by simplifications. Basically, instead of using the lint level builder, which is slow, this PR splits `lint_expectations` logic in 2: - listing the `LintExpectations` is done in `shallow_lint_levels_on`, on a per-owner basis; - building the unstable->stable expectation id map is done by iterating on attributes. r? ghost for perf
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (809e06b): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -5.5%, 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.
CyclesResults (primary 1.5%, secondary 1.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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 738.413s -> 735.235s (-0.43%) |
r? compiler |
Perf: the results are an improvement almost everywhere. The regressions ( |
cc @xFrednet |
66a9985
to
ff1fc68
Compare
r? compiler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this LGTM for the most part, but I'm not super sure about how the AttrId
<-> HirId
mapping is constructed.
// Some attributes appear multiple times in HIR, to ensure they are correctly taken | ||
// into account where they matter. This means we cannot just associate the AttrId to | ||
// the first HirId where we see it, but need to check it actually appears in a lint | ||
// level. | ||
// FIXME(cjgillot): Can this cause an attribute to appear in multiple expectation ids? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion: this seems a little suspicious to me, in that I would've expected AttrId
<-> HirId
to be a bijective map. "Some attributes appear multiple times in HIR, to ensure they are correctly taken into account where they matter" almost sounds like a bug to me?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This FIXME makes me sad too, and triggered the discussion here: #127884 (comment)
This map is not bijective, but it is well-defined in one direction. From a pair (HirId, attr_index)
, you'll get a single AttrId
, but the converse is not true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification, that discussion was enlightening. I feel like this will cause a bug somewhere but I also can't immediately come up with an example for. As I can't come up with an example, I'm inclined to merge this as-is and see what cases we run into in practice through fuzzing and whatnot. And see if we can come up with a scheme that is more robust.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Side remark: our lint infra and lint level computation is unfortunately incredibly convoluted)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with accepting the FIXME even if it may cause bugs, because the logic before the rework is also not exactly watertight. The perf change seems to be mixed leaning towards more improvements so I don't feel like it's blocking.
In any case, I think rewriting into a single pass also makes the logic clearer than before. @bors r+ |
@bors rollup=never (perf significant) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a48861a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.3%, secondary 0.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.
CyclesResults (primary -0.4%, 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 790.965s -> 787.22s (-0.47%) |
Many more improvements than regressions. @rustbot label: +perf-regression-triaged |
This PR aims at reducing the perf regression from #120924 (comment) with drive-by simplifications.
Basically, instead of using the lint level builder, which is slow, this PR splits
lint_expectations
logic in 2:LintExpectations
is done inshallow_lint_levels_on
, on a per-owner basis;r? ghost for perf