debuginfo: emit DW_TAG_call_site entries on optimized builds

[resrever]

This is a follow-up to #154200, which was reverted in #154468. The perf metrics showed an average increase of ~2% in binary size and 0.5% compile-time, which is expected due to the space and processing of the DW_TAG_call_site entries.

What this PR does different is gate it behind optimized builds. DW_TAG_call_site is only useful on debug symbols with optimized builds anyway, because unoptimized builds have clear call sites with no tail calls. This behavior also aligns with Clang.

Only one binary in the perf suite - ripgrep - uses debug+optimized builds, so the performance impact is expected to remain, but with that cost comes the benefit of improved debuggability.

r? dingxiangfei2009

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1959f8b (1959f8b227e8d49591068fd085a39fa40008c390, parent: 148adf223edb0444eb1f99753919dd2080c2a534)

[rust-timer]

Finished benchmarking commit (1959f8b): comparison URL.

Overall result: ❌ regressions - 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.7%	[0.2%, 1.0%]	6
Regressions ❌ (secondary)	0.6%	[0.3%, 1.0%]	14
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.2%, 1.0%]	6

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (primary -2.4%)

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

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

Binary size

Results (primary 1.4%, secondary 1.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.8%, 2.1%]	16
Regressions ❌ (secondary)	1.8%	[0.1%, 2.1%]	45
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.4%	[0.8%, 2.1%]	16

Bootstrap: 492.806s -> 486.147s (-1.35%)
Artifact size: 394.85 MiB -> 395.10 MiB (0.06%)

[resrever]

As expected, ripgrep is showing an increase because it is generating debug symbols with optimization.

I did not anticipate the helloworld regression, but after some digging it looks like std is compiled with opt-level 3 before being included in helloworld, so this is working as intended. This brings the standard practice of callsite records that Clang and GCC emit to rustc, and it gates it behind optimization like getCallSiteRelatedAttrs() in CGDebugInfo.cpp.

[resrever]

The callsite info is important for improving debugger's ability to identify function calls, particularly on tail calls that appear on optimized binaries. Compared to the previous PR that was merged and reverted, this one has far fewer regressions since it only adds callsite info only to crates that are compiled with both optimization and debug symbols. There are not many crates compiled with both optimization and debug symbols in the perf tests. One is ripgrep, which adds debug symbols to release builds, and the other is std, which compiles with opt-level=3, which only tips the smallest helloworld binary over the perf-regression thresholds. The callsite info is important for improving debugger's ability to identify function calls, particularly on tail calls that appear on optimized binaries.

@rustbot label: +perf-regression-triaged

[wesleywiser]

r? wesleywiser

[rustbot]

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

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

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

...............................F.................. (50/144)
.................................................. (100/144)
............................................       (144/144)

======== tests/rustdoc-gui/go-to-collapsed-elem.goml ========

[ERROR] line 40
    at `tests/rustdoc-gui/go-to-collapsed-elem.goml` line 21: Error: Node is detached from document: for command `click: "//*[@id='search']//a[@href='../test_docs/struct.Foo.html#method.must_use']"`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/test_docs/struct.Foo.html?search=t_use>


<= doc-ui tests done: 143 succeeded, 1 failed, 0 filtered out

Error: ()