match: Use an aggregate equality comparison for constant array/slice patterns by jakubadamw · Pull Request #155216 · rust-lang/rust

jakubadamw · 2026-04-12T21:59:41Z

When every element in an array or slice pattern is a constant and there is no .. subpattern, the match builder will now emit a single call to PartialEq::eq instead of comparing each element from the value one by one against the respective constant in the pattern.

This drastically reduces the number of MIR basic blocks for large constant-array matches – e.g. a 64-element [u8; 64] match previously generated 64 separate comparison blocks and now generates just one PartialEq::eq call that LLVM can lower to a memcmp(). The optimisation is gated on having at least two constant elements, meaning single-element arrays will still use a plain scalar comparison.

Example:

const FOO: [u8; 64] = *b"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";

pub fn foo(x: &[u8; 64]) -> bool {
    // Before: 64 basic blocks, one per byte.
    // After:  a single `PartialEq::eq()` call.
    matches!(x, &FOO)
}

Closes #103073.
Closes #110870.

rustbot · 2026-04-12T21:59:50Z

Some changes occurred in match lowering

cc @Nadrieril

rustbot · 2026-04-12T21:59:52Z

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, mir
compiler, mir expanded to 69 candidates
Random selection from 12 candidates

JonathanBrouwer · 2026-04-13T18:15:32Z

@bors try @rust-timer queue

match: Use an aggregate equality comparison for constant array/slice patterns when possible

rust-bors · 2026-04-13T20:24:30Z

☀️ Try build successful (CI)
Build commit: 5a6dba6 (5a6dba60b1150a8b57fc739b0829fa4a65c5b8b3, parent: 14196dbfa3eb7c30195251eac092b1b86c8a2d84)

rust-timer · 2026-04-13T21:13:34Z

Finished benchmarking commit (5a6dba6): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Max RSS (memory usage)

Results (primary -0.0%, secondary 0.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.0%, 2.8%]	2
Regressions ❌ (secondary)	2.7%	[1.2%, 5.0%]	3
Improvements ✅ (primary)	-3.9%	[-3.9%, -3.9%]	1
Improvements ✅ (secondary)	-1.8%	[-2.2%, -1.6%]	3
All ❌✅ (primary)	-0.0%	[-3.9%, 2.8%]	3

Cycles

Results (primary -2.3%, secondary 14.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	14.4%	[2.4%, 26.4%]	2
Improvements ✅ (primary)	-2.3%	[-3.1%, -1.7%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.3%	[-3.1%, -1.7%]	4

Binary size

Results (primary -0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	2
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.1%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.2%, 0.1%]	5

Bootstrap: 491.114s -> 490.988s (-0.03%)
Artifact size: 394.23 MiB -> 394.33 MiB (0.03%)

JonathanBrouwer · 2026-04-15T19:44:15Z

@rustbot reroll
Not familiar enough with this code to comfortably review this, but from a quick glance this looks great, thanks <3

dianne · 2026-04-17T21:38:39Z

+            if let PatKind::Constant { value } = pat.kind {
+                Some(ty::Const::new_value(tcx, value.valtree, value.ty))
+            } else {
+                None
+            }


It might also be worth reconstructing aggregate constants for arrays/slices of arrays of constants, etc.? I'm not a specialization expert, but it looks like arrays of bytewise-comparable things are also bytewise-comparable, at least for common array lengths¹. Since array and slice equality are specialized based on their element types' bytewise-comparability, we should be able to get better codegen for nested array patterns too (as long as the inner arrays are of one of those common lengths), I think?

View changes since the review

Footnotes

https://github.com/rust-lang/rust/blob/f29256dd1420dc681bf4956e3012ffe9eccdc7e7/library/core/src/cmp/bytewise.rs#L74-L85 ↩

@dianne, interesting. I’ll look into this next! 🙂

dianne · 2026-04-17T21:49:51Z

+                // When there is no `..`, all elements are constants, and
+                // there are at least two of them, collapse the individual
+                // element subpairs into a single aggregate comparison that
+                // is performed after the length check.
+                if slice.is_none()


An additional possibility: even if there is a .., the comparisons for the sub-slices before and after the .. could be done via aggregate equality when applicable. Credit to #121540, which I think did this?

Edit: assuming prefixes and suffixes are typically small and hand-written, it's probably not worth the trouble to use aggregate equality for them.

Even if only handling the case with no .., it might be worth moving the special-casing into prefix_slice_suffix to share it between PatKind::Slice and PatKind::Array, since that's where the commonalities live.

Edit: after prefix_slice_suffix's cleanup in #154943, I don't think it makes much sense to put this in there. I still think the logic for deciding whether to use aggregate equality is complex enough that it could be worth factoring out, but that's probably not the way to do it.

View changes since the review

jackh726 · 2026-04-23T18:43:22Z

@dianne do you want to take over review here?

dianne

I don't have much context on the ctfe or const traits side of things to evaluate the approach. cc @oli-obk maybe? It feels like we have to make some sort of compromise here to avoid calling anything const-unstable. Possibly we could block on const_cmp stabilizing, or possibly we could have some workaround until then if we want to land this first.

I think I can handle the technical review, at least. Tentatively, r? me (though feel free to steal the assignment if that'd be easier ^^)

View changes since this review

Nadrieril · 2026-08-01T14:42:00Z

@@ -0,0 +1,89 @@
+// EMIT_MIR_FOR_EACH_PANIC_STRATEGY


Can you add a test where the constant has type [CustomType; N]?

View changes since the review

Nadrieril · 2026-08-01T14:44:58Z

@jakubadamw could you fix the conflicts? Then we'll do a perf run and review in detail, but from a first look this looks good to me.

…s when possible When every element in an array or slice pattern is a constant and there is no `..` subpattern, the match builder now emits a single call to `PartialEq::eq` instead of comparing each element one by one. This drastically reduces the number of MIR basic blocks for large constant-array matches – e.g. a 64-element `[u8; 64]` match previously generated 64 separate comparison blocks and now generates just one `PartialEq::eq` call that LLVM can lower to a `memcmp()` The optimisation is gated on having at least two constant elements. Single-element arrays still use a plain scalar comparison. Example: ```rust const FOO: [u8; 64] = *b"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"; pub fn foo(x: &[u8; 64]) -> bool { // Before: 64 basic blocks, one per byte. // After: a single `PartialEq::eq()` call. matches!(x, &FOO) } ```

…on a large fixed-length array

…t contexts This is unless the `const_cmp` feature is enabled, in which case `PartialEq` becomes available in said contexts.

…n't get captured by this logic

…` features

…ng it Following the review feedback, `const_to_pat()` now records the original constant value on the array and slice pattern nodes it expands, and match lowering reads that value back instead of attempting to reconstruct an aggregate constant from the individual element subpatterns. This has two consequences. First, hand-written array and slice patterns are no longer collapsed into aggregate comparisons; the user's intent to match element by element is respected before the MIR boundary. Only patterns that were expanded from an actual constant (a named constant or a byte-string literal) use the aggregate `PartialEq::eq` comparison, and for those the semantics of matching against a constant and comparing with `PartialEq::eq` coincide. Second, nested constant arrays now benefit from the aggregate comparison as well, since the recorded value covers the whole constant, whereas the reconstruction required every immediate element of the pattern to be a leaf constant.

Give the `PartialEq::eq` call emitted for constant array/slice patterns `UnwindAction::Unreachable` instead of an unwind edge. The built-in `PartialEq` implementations for arrays and slices can be trusted not to panic, and the unwind edge would not be harmless: since the aggregate comparison replaces a series of `SwitchInt` tests that could never unwind, the extra edge would make borrow-checking stricter about the drop order in unwinding code, turning previously accepted programs into errors. The string equality tests keep their unwind edge, as they have always had one.

rustbot · 2026-08-02T21:48:35Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

jakubadamw · 2026-08-02T21:52:45Z

@jakubadamw could you fix the conflicts? Then we'll do a perf run and review in detail, but from a first look this looks good to me.

@Nadrieril, thank you for looking at this again, and no worries about the delay – my previous update also took a good while to emerge!

I now rebased this against upstream/main, added the test for a const fixed-size array of a type implementing PartialEq as requested, and made a small update to the comment in perorm_test() in compiler/rustc_mir_build/src/builder/matches/test.rs. Thanks!

Nadrieril · 2026-08-05T14:27:55Z

@bors try @rust-timer queue

match: Use an aggregate equality comparison for constant array/slice patterns

rust-bors · 2026-08-05T15:33:11Z

☀️ Try build successful (CI)
Build commit: b801042 (b8010420c0e48b566a02273dc338547230f6dd6a)
Base parent: 1b29cfd (1b29cfdbee8ee37333f4b24afb936350eb57e705)

rust-timer · 2026-08-05T16:13:55Z

Finished benchmarking commit (b801042): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-1.9%, -0.3%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.0%	[-1.9%, -0.3%]	3

Max RSS (memory usage)

Results (primary -2.7%, secondary 0.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.5%	[0.4%, 0.5%]	4
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	2

Cycles

Results (primary -0.6%, secondary -0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-0.8%	[-2.0%, -0.4%]	8
Improvements ✅ (secondary)	-0.9%	[-1.4%, -0.6%]	8
All ❌✅ (primary)	-0.6%	[-2.0%, 1.0%]	9

Binary size

Results (primary -0.5%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.2%]	2
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	2
Improvements ✅ (primary)	-0.6%	[-3.4%, -0.1%]	11
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.5%	[-3.4%, 0.2%]	13

Bootstrap: 457.809s -> 462.163s (0.95%)
Artifact size: 399.29 MiB -> 399.04 MiB (-0.06%)

jakubadamw · 2026-08-06T13:13:33Z

@Nadrieril, what do you make of these results? 🙁 It seems like a useful small improvement for image and cargo.

dianne · 2026-08-07T04:02:06Z

+                // (Interestingly this means that, for `str`, exhaustiveness analysis
+                // relies for soundness on the `PartialEq` impl for `str` to be correct!)


This applies to aggregates too. We need PartialEq::eq to agree with structural comparison or we may accept non-exhaustive matches.

View changes since the review

dianne · 2026-08-07T04:27:11Z

+                // That is sound because a constant is only allowed in a pattern if its
+                // type is structural match, so the array/slice impl and every element
+                // impl it delegates to are derived or primitive, and cannot panic.


We should only be doing this with element types where we know the PartialEq impl it'll resolve to. In the cases we care about, I don't think we'll be delegating to elements' impls at all? Their PartialEqs should resolve to specialized BytewiseEq impls that compare the aggregates directly. We're relying on the intrinsics compare_bytes and raw_eq used by them not to panic.

In general, being marked StructuralPartialEq doesn't mean we'll be using a derived impl, since it's possible (unstably) to implement it on arbitrary types. It's not an unsafe trait since we always use structural comparison in matches, even if it disagrees with PartialEq.

View changes since the review

dianne · 2026-08-07T04:46:17Z

+        let value = pattern.extra.as_deref()?.expanded_const_value?;
+        if element_count < AGGREGATE_EQ_MIN_LEN || !self.can_use_aggregate_eq() {
+            return None;
+        }
+        Some(value)


We need to check that the element type is such that we'll be using a known PartialEq impl, since we're relying on it being correct and not panicking. For simplicity, I'd suggest keeping this to arrays and slices of bytewise-comparable primitives for now; in those cases, we know that PartialEq will compare aggregates directly:

rust/library/core/src/cmp/bytewise.rs

Lines 31 to 36 in 88f7399

// SAFETY: All the ordinary integer types have no padding, and are not pointers.

is_bytewise_comparable!(u8, u16, u32, u64, u128, usize, i8, i16, i32, i64, i128, isize);

// SAFETY: These have *niches*, but no *padding* and no *provenance*,

// so we can compare them directly.

is_bytewise_comparable!(bool, char, super::Ordering);

Potentially this could be extended to arbitrary BytewiseEq types, but my understanding is that the most important cases to handle are primitives.

View changes since the review

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 Apr 12, 2026

rustbot assigned JonathanBrouwer Apr 12, 2026

This comment has been minimized.

Sign in to view

jakubadamw marked this pull request as draft April 12, 2026 23:12

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 12, 2026

jakubadamw marked this pull request as ready for review April 12, 2026 23:50

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 12, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Apr 13, 2026

Auto merge of #155216 - jakubadamw:issue-110870-103073, r=<try>

5a6dba6

match: Use an aggregate equality comparison for constant array/slice patterns when possible

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 13, 2026

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 13, 2026

rustbot assigned jackh726 and unassigned JonathanBrouwer Apr 15, 2026

dianne reviewed Apr 17, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

Nadrieril reviewed Apr 22, 2026

View reviewed changes

Comment thread compiler/rustc_mir_build/src/builder/matches/match_pair.rs

dianne reviewed Apr 23, 2026

View reviewed changes

Comment thread compiler/rustc_mir_build/src/builder/matches/test.rs Outdated

Comment thread compiler/rustc_mir_build/src/builder/matches/match_pair.rs

rustbot assigned dianne Apr 23, 2026

Nadrieril reviewed Aug 1, 2026

View reviewed changes

jakubadamw added 14 commits August 2, 2026 22:47

Add a MIR test ensuring we use an aggregate comparison when matching …

085b0a4

…on a large fixed-length array

Add another test, a run-pass one

9665678

Extend both tests with the example from rust-lang#103073

6171edd

Make sure the new aggregate equality comparison is excluded from cons…

4df802d

…t contexts This is unless the `const_cmp` feature is enabled, in which case `PartialEq` becomes available in said contexts.

Update the tests to cover const contexts as well

4c496f9

Raise the aggregate equality comparison threshold so simple arrays do…

ca8b70b

…n't get captured by this logic

Merge the AggregateEq and StringEq test arms into a single case

0da5fed

Add a missing space

776ace0

Remove the special treatment of the const_cmp and `const_trait_impl…

9f195dc

…` features

Add a MIR test for a constant array with a custom element type

c02f658

Expand on why the aggregate comparison is assumed not to unwind

2ea4f27

jakubadamw force-pushed the issue-110870-103073 branch from 4a8c85e to 2ea4f27 Compare August 2, 2026 21:48

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 5, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Aug 5, 2026

Auto merge of #155216 - jakubadamw:issue-110870-103073, r=<try>

b801042

match: Use an aggregate equality comparison for constant array/slice patterns

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 5, 2026

dianne reviewed Aug 7, 2026

View reviewed changes

		// (Interestingly this means that, for `str`, exhaustiveness analysis
		// relies for soundness on the `PartialEq` impl for `str` to be correct!)

	// SAFETY: All the ordinary integer types have no padding, and are not pointers.
	is_bytewise_comparable!(u8, u16, u32, u64, u128, usize, i8, i16, i32, i64, i128, isize);

	// SAFETY: These have niches, but no padding and no provenance,
	// so we can compare them directly.
	is_bytewise_comparable!(bool, char, super::Ordering);

Uh oh!

Uh oh!

Conversation

jakubadamw commented Apr 12, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 12, 2026

Uh oh!

rustbot commented Apr 12, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented Apr 13, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Apr 13, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Apr 13, 2026

Overall result: ❌✅ regressions and improvements - no action needed

Uh oh!

JonathanBrouwer commented Apr 15, 2026

Uh oh!

Uh oh!

Uh oh!

dianne Apr 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

jakubadamw Apr 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Uh oh!

jackh726 commented Apr 23, 2026

Uh oh!

dianne left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Nadrieril Aug 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nadrieril commented Aug 1, 2026

Uh oh!

rustbot commented Aug 2, 2026

Uh oh!

jakubadamw commented Aug 2, 2026

Uh oh!

Nadrieril commented Aug 5, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Aug 5, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Aug 5, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

jakubadamw commented Aug 6, 2026

Uh oh!

dianne Aug 7, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne Aug 7, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

jakubadamw commented Apr 12, 2026 •

edited by rustbot

Loading

dianne Apr 17, 2026 •

edited by rustbot

Loading

jakubadamw Apr 26, 2026 •

edited

Loading

dianne Apr 17, 2026 •

edited

Loading

dianne left a comment •

edited by rustbot

Loading

Nadrieril Aug 1, 2026 •

edited by rustbot

Loading

dianne Aug 7, 2026 •

edited by rustbot

Loading

dianne Aug 7, 2026 •

edited

Loading

dianne Aug 7, 2026 •

edited by rustbot

Loading