Introduce debuginfo to statements in MIR #142771

dianqk · 2025-06-20T07:16:46Z

The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix #128081.

I don't modify Stable MIR, as I don't think we need debug information when using it.

This PR represents the debug information for the dead reference statement via #dbg_value. For example, let _foo_b = &foo.b becomes #dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26). You can see this here: https://rust.godbolt.org/z/d43js6adv.

The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.

The current rules for dropping debug information in this PR are:

If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.

I doesn't drop debuginfos in MatchBranchSimplification, because LLVM also pick one branch for it.

compiler/rustc_middle/src/mir/mod.rs

dianqk · 2025-06-20T10:52:57Z

@bors2 try @rust-timer queue

rust-bors · 2025-06-20T10:53:00Z

⌛ Trying commit 51576e7 with merge eb83156…

To cancel the try build, run the command @bors2 try cancel.

Introduce debuginfo to statements in MIR Not ready for reviewing. Something known: - [ ] Retain debuginfo when concatenating bbs - [ ] Document about when to drop debuginfos (don't be worse than the optimized LLVM IR) - [ ] Missing tests r? ghost

rust-bors · 2025-06-20T13:23:31Z

☀️ Try build successful (CI)
Build commit: eb83156 (eb83156169ae3bbdd1385d498455dbc44283f5ff, parent: 18491d5be00eb3ed2f1ccee2ac5b792694f2a7a0)

rust-timer · 2025-06-20T23:32:50Z

Finished benchmarking commit (eb83156): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.9%	[0.2%, 14.5%]	51
Regressions ❌ (secondary)	0.8%	[0.1%, 1.6%]	52
Improvements ✅ (primary)	-0.4%	[-2.1%, -0.2%]	35
Improvements ✅ (secondary)	-0.3%	[-0.5%, -0.2%]	39
All ❌✅ (primary)	0.4%	[-2.1%, 14.5%]	86

Max RSS (memory usage)

Results (primary 2.3%, secondary 3.4%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[0.8%, 4.7%]	54
Regressions ❌ (secondary)	3.6%	[0.7%, 7.4%]	38
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	1
All ❌✅ (primary)	2.3%	[0.8%, 4.7%]	54

Cycles

Results (primary 3.2%, secondary 2.5%)

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

	mean	range	count
Regressions ❌ (primary)	3.9%	[1.1%, 14.4%]	7
Regressions ❌ (secondary)	2.5%	[2.0%, 3.3%]	3
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.2%	[-2.0%, 14.4%]	8

Binary size

Results (primary 0.5%, secondary 0.3%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.0%, 2.2%]	123
Regressions ❌ (secondary)	1.1%	[0.0%, 3.5%]	59
Improvements ✅ (primary)	-0.9%	[-6.5%, -0.1%]	11
Improvements ✅ (secondary)	-0.5%	[-13.0%, -0.1%]	55
All ❌✅ (primary)	0.5%	[-6.5%, 2.2%]	134

Bootstrap: 691.482s -> 692.445s (0.14%)
Artifact size: 371.94 MiB -> 372.12 MiB (0.05%)

dianqk · 2025-06-21T02:59:42Z

@bors2 try @rust-timer queue

rust-bors · 2025-06-21T02:59:46Z

⌛ Trying commit e72c3ae with merge 77d5c6a…

To cancel the try build, run the command @bors2 try cancel.

Introduce debuginfo to statements in MIR Not ready for reviewing. Something known: - [ ] Retain debuginfo when concatenating bbs - [ ] Document about when to drop debuginfos (don't be worse than the optimized LLVM IR) - [ ] Missing tests r? ghost

rust-bors · 2025-06-21T05:28:30Z

☀️ Try build successful (CI)
Build commit: 77d5c6a (77d5c6a20a77fabdee3790a412618b82178e9ab4, parent: 15c701fbc995eb6c5b3a86021c18185f8eee020d)

rust-timer · 2025-06-21T09:26:06Z

Finished benchmarking commit (77d5c6a): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.9%	[0.1%, 14.5%]	53
Regressions ❌ (secondary)	0.8%	[0.1%, 1.6%]	50
Improvements ✅ (primary)	-0.4%	[-3.0%, -0.2%]	46
Improvements ✅ (secondary)	-0.3%	[-0.5%, -0.2%]	41
All ❌✅ (primary)	0.3%	[-3.0%, 14.5%]	99

Max RSS (memory usage)

Results (primary 2.4%, secondary 3.4%)

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

	mean	range	count
Regressions ❌ (primary)	2.4%	[0.5%, 5.7%]	38
Regressions ❌ (secondary)	4.2%	[1.3%, 6.2%]	25
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-3.0%, -1.1%]	4
All ❌✅ (primary)	2.4%	[0.5%, 5.7%]	38

Cycles

Results (primary 2.1%, 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)	3.0%	[0.8%, 14.1%]	10
Regressions ❌ (secondary)	3.3%	[2.3%, 4.3%]	2
Improvements ✅ (primary)	-2.3%	[-2.9%, -1.7%]	2
Improvements ✅ (secondary)	-2.2%	[-2.6%, -1.9%]	2
All ❌✅ (primary)	2.1%	[-2.9%, 14.1%]	12

Binary size

Results (primary 0.5%, secondary 0.3%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.0%, 3.0%]	122
Regressions ❌ (secondary)	1.1%	[0.0%, 3.5%]	59
Improvements ✅ (primary)	-0.7%	[-4.9%, -0.0%]	15
Improvements ✅ (secondary)	-0.5%	[-12.7%, -0.0%]	55
All ❌✅ (primary)	0.5%	[-4.9%, 3.0%]	137

Bootstrap: 690.617s -> 691.47s (0.12%)
Artifact size: 371.83 MiB -> 372.01 MiB (0.05%)

bors · 2025-06-25T18:27:45Z

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

cjgillot · 2025-09-07T21:14:15Z

compiler/rustc_codegen_ssa/src/mir/statement.rs

+                        // For `_n = &((*_1).0: i32);`, we are calculating the address of `_1.0`, so
+                        // we should drop the deref projection.
+                        let projected_ty = local_ref


I really have trouble understanding the logic here. &(*_1).0 and &_1.0 should result in very different code, shouldn't they?

If you are talking about the following code (https://rust.godbolt.org/z/xsdazTs1n):

#[repr(C)] pub struct Foo(i32, i64, i32); #[unsafe(no_mangle)] fn bar(ptr_foo: Foo) -> i32 { let b = &ptr_foo.1; // &(_1.1: i64); ptr_foo.2 } #[unsafe(no_mangle)] fn foo(ref_foo: &Foo) -> i32 { let a = &ref_foo.1; // &((*_1).1: i64); ref_foo.2 }

They are different MIR statements, but they have the same LLVM IR statement due to the ABI of arguments.
Both Foo and &Foo are passed as a pointer here.

dianqk · 2025-09-14T14:05:31Z

cc @davidtwco for the debuginfo part, since you are the only debuginfo reviewer now.

cjgillot · 2025-09-15T00:35:26Z

r=me on the MIR part. I don't mind an extra review for the codegen part.

bors · 2025-09-17T11:28:09Z

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

dianqk · 2025-09-17T15:01:47Z

I am writing some explanations for debugging information, which should help with the review.

@rustbot author

dianqk · 2025-09-21T13:25:43Z

While I was explaining cases one-by-one based on PassMode and BackendRepr, I found some bugs. For instance, accessing the &i32 in (&[i32; 16], i32) via &_1.1 should result in poison.

@cjgillot I think you are right, they have the same LLVM IR, however their code logic is very different.

It would be easier to understand and maintain if we used LocalRef instead of PassMode and BackendRepr.

The test cases are based on PassMode, and from a testing perspective, I think this is easier to understand, since LocalRef is an internal implementation detail.

@rustbot review

r? cjgillot (for the debuginfo part if you think the new change is fine)

rustbot · 2025-09-21T13:25:46Z

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

rustbot · 2025-09-21T13:44:24Z

This PR was rebased onto a different master 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.

cjgillot · 2025-09-21T16:38:48Z

compiler/rustc_codegen_ssa/src/mir/statement.rs

+                    // For an rvalue like `&(*_1).1`, we are calculating the address of `_1.1`,
+                    // so we should drop the deref projection.


This comment is wrong. &(*_1).1 means &((*_1).1), which is not the same as &(*(_1.1)).

Hmm, IIUC, the MIR statement of pub fn foo(a: &Foo){ let b = &a.2; } is _2 = &((*_1).2: i32);.

I think you mean calculating the address of (*_1).1 here. _1.1 doesn't exist. That would be the second field of a reference, but references don't have fields.

If the `LocalRef` is `LocalRef::Place`, we can refer to it directly, because the local of place is an indirect pointer. Such a statement is `_1 = &(_2.1)`. If the `LocalRef` is `LocalRef::Operand`, the `OperandRef` should provide the pointer of the reference. Such a statement is `_1 = &((*_2).1)`. But there is a special case that hasn't been handled, scalar pairs like `(&[i32; 16], i32)`.

dianqk · 2025-09-23T14:31:06Z

The new change should exactly match codegen_rvalue_operand.

rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 20, 2025

This comment has been minimized.

Sign in to view

dianqk force-pushed the mir-stmt-debuginfo branch from 15c968a to 6b013d4 Compare June 20, 2025 08:01

This comment has been minimized.

Sign in to view

bjorn3 reviewed Jun 20, 2025

View reviewed changes

compiler/rustc_middle/src/mir/mod.rs Outdated Show resolved Hide resolved

dianqk force-pushed the mir-stmt-debuginfo branch from 6b013d4 to 51576e7 Compare June 20, 2025 09:23

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 Jun 20, 2025

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jun 20, 2025

dianqk force-pushed the mir-stmt-debuginfo branch from 51576e7 to e72c3ae Compare June 21, 2025 02:31

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 Jun 21, 2025

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 Jun 21, 2025

cjgillot reviewed Sep 7, 2025

View reviewed changes

dianqk force-pushed the mir-stmt-debuginfo branch from 47cc699 to e2f9c7e Compare September 10, 2025 14:39

This comment has been minimized.

Sign in to view

dianqk added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Sep 14, 2025

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 Sep 17, 2025

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 21, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 21, 2025

dianqk force-pushed the mir-stmt-debuginfo branch from eba7551 to df5c862 Compare September 21, 2025 13:44

dianqk force-pushed the mir-stmt-debuginfo branch from df5c862 to 8018751 Compare September 21, 2025 14:18

This comment has been minimized.

Sign in to view

cjgillot reviewed Sep 21, 2025

View reviewed changes

dianqk added 5 commits September 22, 2025 08:02

mir-opt: Eliminate dead ref statements

15eb297

simplifycfg: Preserve debuginfos when merging bbs

5c3e0cd

mir-opt: Eliminate trivial unnecessary storage annotations

0d9cd30

codegen: Generate dbg_value for the ref statement

f63ab39

mir-opt: Eliminate dead statements even if they are used by debuginfos

ebe3c97

dianqk force-pushed the mir-stmt-debuginfo branch from 8018751 to 6c0fd07 Compare September 22, 2025 00:21

This comment has been minimized.

Sign in to view

dianqk force-pushed the mir-stmt-debuginfo branch from 6c0fd07 to 844c8a4 Compare September 22, 2025 10:41

dianqk force-pushed the mir-stmt-debuginfo branch from 844c8a4 to 8c5a513 Compare September 23, 2025 14:28

		// For an rvalue like `&(*_1).1`, we are calculating the address of `_1.1`,
		// so we should drop the deref projection.

Introduce debuginfo to statements in MIR #142771

Are you sure you want to change the base?

Introduce debuginfo to statements in MIR #142771

Conversation

dianqk commented Jun 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

This comment has been minimized.

dianqk commented Jun 20, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jun 20, 2025

Uh oh!

rust-bors bot commented Jun 20, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jun 20, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

dianqk commented Jun 21, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jun 21, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jun 21, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jun 21, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

bors commented Jun 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

dianqk commented Sep 14, 2025

Uh oh!

cjgillot commented Sep 15, 2025

Uh oh!

bors commented Sep 17, 2025

Uh oh!

dianqk commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianqk commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 21, 2025

Uh oh!

rustbot commented Sep 21, 2025

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

dianqk commented Sep 23, 2025

Uh oh!

Uh oh!

dianqk commented Jun 20, 2025 •

edited

Loading

dianqk commented Sep 17, 2025 •

edited

Loading

dianqk commented Sep 21, 2025 •

edited

Loading