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

compare generic constants using AbstractConsts #76575

Merged
merged 12 commits into from
Sep 18, 2020
Merged

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented Sep 10, 2020

This is a MVP of rust-lang/compiler-team#340. The changes in this PR should only be relevant if feature(const_evaluatable_checked) is enabled.

currently based on top of #76559, so blocked on that.

r? @oli-obk cc @varkor @eddyb

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 10, 2020
@lcnr lcnr added A-const-generics Area: const generics (parameters and arguments) F-const_generics `#![feature(const_generics)]` labels Sep 10, 2020
Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

At the current level this is still very reasonable to keep an overview about, but I think we should proactively document the AbstractConstBuilder in detail

compiler/rustc_middle/src/mir/abstract_const.rs Outdated Show resolved Hide resolved
compiler/rustc_trait_selection/src/traits/mod.rs Outdated Show resolved Hide resolved
// FIXME: we probably should only try to unify abstract constants
// if the constants depend on generic parameters.
//
// Let's just see where this breaks :shrug:
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe make the try_unify_abstract_consts query a raw query and add a wrapper that has a fast path for such checks

@oli-obk
Copy link
Contributor

oli-obk commented Sep 11, 2020

Does this treat

const X: usize = { let x = 4; x + 1 };
const Y: usize = 4 + 1;

the same? Should it?

@lcnr
Copy link
Contributor Author

lcnr commented Sep 11, 2020

We do not yet support let bindings, as they add a StatementKind::FakeRead to the mir, added a test for this.

I think it's a good idea to not support them for now and see how often they are desired once this lands on nightly.

@lcnr lcnr force-pushed the abstract-const branch 2 times, most recently from b5d6616 to f7a7cf9 Compare September 11, 2020 20:12
@bors
Copy link
Contributor

bors commented Sep 12, 2020

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

if b_def == def && b_substs == substs {
debug!("is_const_evaluatable: caller_bound ~~> ok");
return Ok(());
if let Some(ct) = AbstractConst::new(infcx.tcx, def, substs) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We only need to build this in case we ever hit the situation where b_def != def || b_substs != substs. I understand that this only computes it once even if needed multiple times, but maybe it can be cached in a mutable local Option?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, this is super cheap for !polymorphic const bodies... carry on

@@ -16,18 +31,23 @@ pub fn is_const_evaluatable<'cx, 'tcx>(
) -> Result<(), ErrorHandled> {
debug!("is_const_evaluatable({:?}, {:?})", def, substs);
if infcx.tcx.features().const_evaluatable_checked {
Copy link
Contributor

Choose a reason for hiding this comment

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

If I'm reading the code right, this is not needed as AbstractConst::new will return None if the feature gate is not enabled

Copy link
Contributor Author

@lcnr lcnr Sep 18, 2020

Choose a reason for hiding this comment

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

I kept it in as we otherwise have to reason globally here.

We would also be able to enter this conditional if we look at constants from extern crates if these crates use this feature without that check, which I don't actually want. (so that we can use it in libs without worrying about this)

@oli-obk
Copy link
Contributor

oli-obk commented Sep 18, 2020

I think this can go out of draft mode now? 😄

@lcnr lcnr marked this pull request as ready for review September 18, 2020 15:13
@lcnr
Copy link
Contributor Author

lcnr commented Sep 18, 2020

@bors r=oli-obk rollup=never in case this influences perf

@bors
Copy link
Contributor

bors commented Sep 18, 2020

📌 Commit 09e6254 has been approved by oli-obk

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 18, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Sep 18, 2020
@lcnr
Copy link
Contributor Author

lcnr commented Sep 18, 2020

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Sep 18, 2020

📌 Commit b764120 has been approved by oli-obk

@bors
Copy link
Contributor

bors commented Sep 18, 2020

⌛ Testing commit b764120 with merge 9f8ac71...

@bors
Copy link
Contributor

bors commented Sep 18, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing 9f8ac71 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 18, 2020
@bors bors merged commit 9f8ac71 into rust-lang:master Sep 18, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 18, 2020
@lcnr lcnr deleted the abstract-const branch September 18, 2020 19:39
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Sep 21, 2020

Hi! This PR showed up in the weekly perf triage report. It seems to have caused a
moderate regression in instruction counts (up to 2.4% on full builds of inflate-check).

It seems like this code is only needed behind a feature gate. @lcnr is there anything that can be done to reduce the impact for stable users?

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 25, 2020
perf: move cold path of `process_obligations` into a separate function

cc rust-lang#76575

This probably won't matter too much in the long run once rust-lang#69218 is merged so we may not want to merge this.

r? `@ecstatic-morse`
@lcnr lcnr added the F-generic_const_exprs `#![feature(generic_const_exprs)]` label Nov 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-generics Area: const generics (parameters and arguments) F-const_generics `#![feature(const_generics)]` F-generic_const_exprs `#![feature(generic_const_exprs)]` 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants