Don't allocate on SimplifyCfg/Locals/Const on every MIR pass

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.

[miguelraz]

Hey! 👋🏾 This is a first PR attempt to see if I could speed up some rustc internals.

Thought process:

pubstructSimplifyCfg{label:String,}

in compiler/src/rustc_mir_transform/simplify.rs fires multiple times per MIR analysis. This means that a likely string allocation is happening in each of these runs, which may add up, as they are not being lazily allocated or cached in between the different passes.

...yes, I know that adding a global static array is probably not the future-proof solution, but I wanted to lob this now as a proof of concept to see if it's worth shaving off a few cycles and then making more robust.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Do you have any evidence to suggest that these are expensive operations? I don't think this code is really worth the extra complication and possibly introducing new panic edges to the compiler just to avoid some string formatting.

[jyn514]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ccc7a0c1af6f58b3081024583d3cfdbcfb4f3434 with merge b89ba5d787d15245a9be6ac6f1619c153b23ea97...

[bors]

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

[rust-timer]

Finished benchmarking commit (b89ba5d787d15245a9be6ac6f1619c153b23ea97): 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-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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-2.8%, -0.2%]	19
Improvements ✅ (secondary)	-2.4%	[-7.5%, -0.2%]	17
All ❌✅ (primary)	-0.7%	[-2.8%, -0.2%]	19

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.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.3%	[2.0%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-4.7%, -2.7%]	3
All ❌✅ (primary)	-	-	0

[compiler-errors]

Apparently keccak and codegen-cranelift have been particularly noisy recently, so I've been advised to ignore those.

As for the other positive perf results, I'll have to take a closer look at them to see if they're legit or just noise as well. (Or maybe I'll queue another perf run in the morning and see if these perf results stick?)

[workingjubilee]

comment worth noting from a sidebar conversation about (current behavior, as it relates to this PR):

[11:57 PM] compilererrors: there are 273521 calls to format! [editor's note: when constructing mir passes] to bootstrap stdlib

[compiler-errors]

Anyways, @miguelraz, I did some thinking. I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Something like:

enumSimplifyCfgPassName{Initial,PromoteConsts,
...
}implSimplifyCfg{fnnew(e:SimplifyCfgPassName) -> Self{SimplifyCfg{ e }}fnname(&self) -> &'staticstr{matchself.e{SimplifyCfgPassName::Initial => "SimplifyCfg-initial",}}

[JakobDegen]

The improvement is probably legit. I've seen major regressions in the past resulting from over-calling name and creating string allocations for it

[workingjubilee]

We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

This would also reduce the size from the size of the string ref (pointer and length) to the size of the enum, which will save about 7~15 bytes per instance of this struct that is in memory at any given moment. Not the most important win compared to allocation overhead, but y'know, everything counts in large amounts.

[Noratrieb]

cachegrind results from libc Debug Full:

1,260,425 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_qpath
888,494 ???:<core::cell::once::OnceCell<bool>>::get_or_try_init::<<core::cell::once::OnceCell<bool>>::get_or_init<<rustc_middle::mir::basic_blocks::BasicBlocks>::is_cfg_cyclic::{closure#0}>::{closure#0}, !>
-790,524 library/core/src/fmt/mod.rs:core::fmt::write
-710,531 ???:<rustc_data_structures::graph::iterate::TriColorDepthFirstSearch<rustc_middle::mir::basic_blocks::BasicBlocks>>::run_from_start::<rustc_data_structures::graph::iterate::CycleDetector>
-659,804 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/arena.c:_rjem_je_arena_ralloc
-638,356 ???:<rustc_passes::dead::MarkSymbolVisitor>::check_def_id
-634,657 ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:__memcpy_avx_unaligned_erms
-564,660 library/core/src/fmt/mod.rs:<&mut W as core::fmt::Write>::write_str
-527,874 ???:<rustc_passes::dead::MarkSymbolVisitor as rustc_hir::intravisit::Visitor>::visit_ty
-513,184 obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-5bd9bcfdf2a83955/out/build/src/jemalloc.c:do_rallocx
-508,194 library/core/src/fmt/mod.rs:core::fmt::Formatter::pad
-435,018 ???:rustc_ast::mut_visit::noop_visit_fn_decl::<rustc_expand::expand::InvocationCollector>
-417,494 ???:rustc_passes::reachable::has_custom_linkage
-399,892 ???:<rustc_middle::ty::context::TyCtxt>::def_kind::<rustc_span::def_id::LocalDefId>
-395,262 library/core/src/fmt/mod.rs:alloc::fmt::format::format_inner

lots of noise, but there are some memcpys and core::fmt, so this looks like a legit improvement. Awesome!

[Noratrieb]

I quickly profiled a few other allocation sites inside simplify and found a few interesting results, it may be worth it to SmallVec a bunch of these: https://hackmd.io/3ViTm3u5QDST-c6mUIyjXg

[lqd]

keccak and cranelift-codegen are indeed noisy right now unfortunately.

Some of the other wins look related to formatting so probably legit.

There shouldn't be many instances of these structs in-flight at the same time, so maybe we wouldn't really see size reduction benefits (nor exhaustiveness for such debugging info), and can e.g. take the name as &'static str and do the Simplify*-$pass concatenations at the 10 or so call-sites instead.

[cjgillot]

I think the right approach for this would be to make SimplifyCfg/etc's constructors instead take some enum that actually makes the matches you constructed above exhaustive. We can probably store those enums in the mir pass structs instead of a &'static str, then match on them in fn name to turn them into a &'static str.

Even simpler: we can make SimplifyCfg itself an enum, and have fn name match on self?

[miguelraz]

@cjgillot yes, I just realized that and push that very change, thanks for the tip!

[compiler-errors]

@miguelraz can you squash this into one commit? Other than that, this PR looks good to go.

[jyn514]

@bors r=compiler-errors

[bors]

📌 Commit fc27ae1 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit fc27ae1 with merge 9e7f72c...

[JakobDegen]

(nit) no need to block the PR on this, but if you touch this code again in the future could you rename this to just SimplifyConstCondition? That would make it consistent with all the other ones

[miguelraz]

Thanks for this, finally got around to this fix.
#110657

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 9e7f72c to master...

[rust-timer]

Finished benchmarking commit (9e7f72c): 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.3%]	10
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	9
All ❌✅ (primary)	-0.5%	[-0.7%, -0.3%]	10

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.9%, 3.1%]	2
Regressions ❌ (secondary)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-4.2%	[-4.2%, -4.2%]	1
All ❌✅ (primary)	0.5%	[-3.6%, 3.1%]	3

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.7%, 3.6%]	4
Improvements ✅ (primary)	-2.9%	[-4.6%, -1.5%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-4.6%, -1.5%]	8

[miguelraz]

For the record, this PR was a revived attempt of #108026.