Rewrite representability

[camsteffen]

• Improve placement of Box in the suggestion
• Multiple items in a cycle emit 1 error instead of an error for each item in the cycle
• Introduce representability query to avoid traversing an item every time it is used.
• Also introduce params_in_repr query to avoid traversing generic items every time it is used.

[rust-highfive]

r? @fee1-dead

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

[camsteffen]

Ope I'm getting a cycle error in an incremental test. Not sure how to fix that but I'm sure it has to do with my usage of ImplicitCtxt...

Edit: Fixed with eval_always.

[camsteffen]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 74b5ebb844d94d9f73b616935db85fcf10cee785 with merge 44959bb541376c812edaad691a6f425d303af4cc...

[cjgillot]

Why does the output change without eval_always?

[camsteffen]

@cjgillot IIUC, eval_always is necessary because the query uses "global state" in ImplicitCtxt, so a nested query can't properly resume where it left off in incremental. I think it would be okay to cache only results that are Ok, but I don't know if it's possible to cache based on the result value?

[bors]

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

[rust-timer]

Queued 44959bb541376c812edaad691a6f425d303af4cc with parent 8064a49, future comparison URL.

[rust-timer]

Finished benchmarking commit (44959bb541376c812edaad691a6f425d303af4cc): comparison url.

Instruction count

• Primary benchmarks: ❌ relevant regressions found
• Secondary benchmarks: ❌ relevant regressions found

	mean1	max	count2
Regressions ❌ (primary)	0.6%	1.4%	123
Regressions ❌ (secondary)	0.9%	1.7%	72
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	-0.3%	4
All ❌✅ (primary)	0.6%	1.4%	123

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.7%	3.3%	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	-2.7%	2
All ❌✅ (primary)	-	-	0

Cycles

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: ❌ relevant regressions found

	mean1	max	count2
Regressions ❌ (primary)	2.3%	2.9%	3
Regressions ❌ (secondary)	2.9%	3.7%	6
Improvements ✅ (primary)	-2.0%	-2.0%	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.2%	2.9%	4

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. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[camsteffen]

Hmm is there some combination of query modifiers that might get the perf back? Or is my whole approach just flawed?

[fee1-dead]

r? compiler

I'm not familiar enough with query code and representability to review this.

[cjgillot]

By marking the query as eval_always, you force recomputation of all representability, even if nothing has changed. This causes the regression in incr-unchanged and incr-patched profiles. You also have a regression in the full profiles, but I'm not sure where this comes from.

IIUC, the only case a type is not representable, is when there is a cycle in its representation. I'd suggest a 2 step approach without global state:

1. one query to list the local ADTs that appear in the representability, returning a vector of field ids & ADT's id;
2. the toplevel query is_representable that performs a graph traversal to find a cycle.

Caching the graph traversal in 2 requires special support from the query system. I have a commit that would implement that, but I'm still trying to design what the API should look like.

[camsteffen]

Caching the graph traversal in 2 requires special support from the query system. I have a commit that would implement that, but I'm still trying to design what the API should look like.

So you think we can cache non-acyclic query results? Sounds fun!

[camsteffen]

Noting a couple problems I found with my own code fwiw 😆

[camsteffen]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit ab8509ee3eda951741269715e55855f5eadf4605 with merge 1a1e80337e2850a979b64f8fe9c654fbe79accf8...

[bors]

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

[rust-timer]

Queued 1a1e80337e2850a979b64f8fe9c654fbe79accf8 with parent 01af504, future comparison URL.

[rust-timer]

Finished benchmarking commit (1a1e80337e2850a979b64f8fe9c654fbe79accf8): comparison URL.

Overall result: ✅ improvements - 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-review -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-1.0%, -0.4%]	2
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.4%]	7
All ❌✅ (primary)	-0.7%	[-1.0%, -0.4%]	2

Max RSS (memory usage)

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	8.3%	[0.9%, 15.8%]	4
Regressions ❌ (secondary)	2.4%	[1.9%, 3.2%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-8.7%, -2.1%]	4
All ❌✅ (primary)	8.3%	[0.9%, 15.8%]	4

Cycles

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	2.7%	[2.7%, 2.8%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.7%	[2.7%, 2.8%]	2

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[cjgillot]

Thanks @camsteffen for accepting to re-do it multiple times.
@bors r+

[bors]

📌 Commit ff940db has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit ff940db with merge bba9785...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing bba9785 to master...

[rust-timer]

Finished benchmarking commit (bba9785): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.8%, -0.2%]	38
Improvements ✅ (secondary)	-0.9%	[-3.3%, -0.2%]	21
All ❌✅ (primary)	-0.4%	[-0.8%, -0.2%]	38

Max RSS (memory usage)

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	8.8%	[2.4%, 15.8%]	4
Regressions ❌ (secondary)	4.0%	[2.1%, 5.2%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-4.6%, -1.2%]	7
All ❌✅ (primary)	8.8%	[2.4%, 15.8%]	4

Cycles

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[1.9%, 5.3%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³