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 query to check for impossible predicates, use it to skip NoopMethodCall and Inline #95398

Closed

Conversation

compiler-errors
Copy link
Member

Fix a few cases where impossible founds can be found and can cause ICEs in codegen/linting.

Fixes #94999
Fixes #94680
Actually fixes #93008 this time

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 28, 2022
@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 28, 2022
@bors
Copy link
Contributor

bors commented Mar 31, 2022

☔ The latest upstream changes (presumably #95436) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

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

The query you created makes it seem like having impossible predicates is a property of an item. Should this check be done earlier, ie. at the beginning of typeck, in order to skip all the work of type checking and MIR building?

// parameters (e.g. `<T as Foo>::MyItem`). This can confuse
// the normalization code (leading to cycle errors), since
// it's usually never invoked in this way.
query check_impossible_predicates_for_item(key: DefId) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you rename the query to make the bool more explicit?
Something like item_has_impossible_predicates?

// This branch will never be taken for any normal function.
// However, it's possible to `#!feature(trivial_bounds)]` to write
// a function with impossible to satisfy clauses, e.g.:
// `fn foo() where String: Copy {}`
Copy link
Contributor

Choose a reason for hiding this comment

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

This paragraph is outdated.

@compiler-errors
Copy link
Member Author

@cjgillot:

The query you created makes it seem like having impossible predicates is a property of an item. Should this check be done earlier, ie. at the beginning of typeck, in order to skip all the work of type checking and MIR building?

Yes, I agree that it's a property of the where clause on an item. However, they are allowed on the item with feature(trivial_bounds) and even in some cases without that feature (which, as a side note, I am probably going to put up a PR to warn on the latter cases).

The current behavior is to typecheck the items as if these predicates are true. I think we should at least continue to typecheck the items given the false predicates -- though I wouldn't be opposed to skipping mir-build (or at least all of mir-opt) in the case that they have impossible predicates.

This PR doesn't currently do that because I wanted to keep the affected compiler surface small, since it's the inliner that I have seen with the most ICEs due to calling codegen_fulfill_obligation on impossible predicates. Do you mind if I investigate additional changes (e.g. to skip all of MIR) in a follow-up PR?

@bors
Copy link
Contributor

bors commented Apr 3, 2022

☔ The latest upstream changes (presumably #85321) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
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 Apr 14, 2022
@compiler-errors
Copy link
Member Author

@rustbot ready

r? rust-lang/compiler

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 21, 2022
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 21, 2022
Comment on lines 463 to 465
let mut predicates = tcx.predicates_of(key.0).instantiate(tcx, key.1).predicates;
predicates.retain(|predicate| !predicate.needs_subst());
let result = impossible_predicates(tcx, predicates);
Copy link
Member

Choose a reason for hiding this comment

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

It's surprising to me that this doesn't just delegate to item_has_impossible_predicates_for_item.

The behavior these two are slightly different; could they be merged?

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried to before, but I had some regressions.

I think I could try again if I'm smarter with some things though... I'll investigate this weekend.

Copy link
Member

Choose a reason for hiding this comment

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

Do you think we should land this in the meantime? If so, I think I'd like a FIXME added, but other than that, r=me

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not ridiculously critical, so I'll play around with it this weekend and either r=you with a better description of why they're different, or unify these two.

@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 24, 2022
@bors
Copy link
Contributor

bors commented Apr 24, 2022

⌛ Trying commit 41ad624 with merge c55a268fc101a6e678d0894680e56e83673f0993...

@bors
Copy link
Contributor

bors commented Apr 24, 2022

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

@rust-timer
Copy link
Collaborator

Queued c55a268fc101a6e678d0894680e56e83673f0993 with parent 18f314e, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (c55a268fc101a6e678d0894680e56e83673f0993): comparison url.

Summary:

  • Primary benchmarks: 😿 relevant regressions found
  • Secondary benchmarks: mixed results
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 40 12 0 2 40
mean2 0.5% 1.4% N/A -1.2% 0.5%
max 0.9% 4.2% N/A -1.2% 0.9%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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-review -S-waiting-on-perf +perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Apr 25, 2022
@compiler-errors
Copy link
Member Author

Oof, that perf regression sucks. It's possibly because I'm elaborating the predicates always.

Testing the previous implementation for perf regression in #96382.

@jackh726 jackh726 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 May 16, 2022
@compiler-errors
Copy link
Member Author

This was superseded by #96806

@compiler-errors compiler-errors deleted the impossible-preds branch August 11, 2023 20:03
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-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
9 participants