do not count non-codegen statement as estimzed cgu element

[csmoe]

Found that some statements doesn't codegen nowadays, so they shouldn't be count as a element in cgu size estimation.

cc #69382

r?@bjorn3 may I have a perf-run?

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 7ac8751 with merge 23e8280651de33e8cdd2cf18fc22ea3130d18aa3...

[bors]

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

[rust-timer]

Queued 23e8280651de33e8cdd2cf18fc22ea3130d18aa3 with parent 4596f4f, future comparison URL.

[rust-timer]

Finished benchmarking commit (23e8280651de33e8cdd2cf18fc22ea3130d18aa3): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

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.8%	[0.4%, 1.4%]	7
Regressions ❌ (secondary)	0.3%	[0.2%, 0.3%]	2
Improvements ✅ (primary)	-0.3%	[-0.8%, -0.2%]	21
Improvements ✅ (secondary)	-1.0%	[-1.9%, -0.3%]	14
All ❌✅ (primary)	-0.0%	[-0.8%, 1.4%]	28

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)	3.8%	[2.4%, 5.5%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.0%	[-7.8%, -0.2%]	10
Improvements ✅ (secondary)	-4.5%	[-6.2%, -2.8%]	2
All ❌✅ (primary)	-1.1%	[-7.8%, 5.5%]	16

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)	1.5%	[1.4%, 1.7%]	5
Regressions ❌ (secondary)	2.9%	[1.7%, 3.9%]	17
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.5%	[1.4%, 1.7%]	5

[csmoe]

The mem usage metric changes more than the others as this patch effects the cgu merging steps. And this makes the size estimation more accurate, seems reasonable to merge it although it has some regressions, how do you think? @bjorn3

[csmoe]

@bjorn3 another perf-run requested, add back the previous included terminator.

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit e5d4856 with merge 392e416a17fde7a21323e4d632402619c9770e51...

[bors]

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

[rust-timer]

Queued 392e416a17fde7a21323e4d632402619c9770e51 with parent c493bae, future comparison URL.

[rust-timer]

Finished benchmarking commit (392e416a17fde7a21323e4d632402619c9770e51): comparison URL.

Overall result: ❌ regressions - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

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.6%	[0.2%, 3.1%]	94
Regressions ❌ (secondary)	0.7%	[0.2%, 2.0%]	63
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[-0.6%, 3.1%]	95

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)	3.5%	[2.0%, 5.3%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.2%	[-7.8%, -0.2%]	5
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	1
All ❌✅ (primary)	-1.3%	[-7.8%, 5.3%]	8

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)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	3.4%	[3.4%, 3.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

[csmoe]

cc @rust-lang/wg-compiler-performance any advise on this? this pr makes the size estimation more accurate, but introduces a new loop on each basicblock, thus instr regressed and mem improved.

[nnethercote]

Both cycles and wall-time are slightly worse with this change, which suggests it's not a win overall.