Measure binary size impact of implicit caller location

[anp]

The largest unanswered questions about implicit caller location are about the binary size impact of the feature and how to offer users control over it.

There are three ways I see that #[track_caller] inflates binaries:

1. code bloat from panicking branches that were previously fused
2. encoding the Location structs themselves
3. encoding the &'static str for every filename referenced by a Location

We need to determine the impact to the ecosystem for each of these before deciding on mitigation strategy.

(1) was the main concern in the RFC but it was predicated on the assumption that #[track_caller] would affect inlining (an artifact of the implementation proposed). Since it doesn't affect inlining now, the only lost optimization in panicking branches would be for cases where LLVM previously used knowledge of a single constant panic location to make the failure path of a function smaller.

We've not yet had any reports of this and some ad-hoc measurements don't show any difference. This matches my mental model of LLVM's ability to optimize calling conventions which is "very expensive magic". I'm open to ideas for how to better assess this, including "wait and see".

TLDR Re (2) and (3),

Locations are 24 bytes when size_of::<usize>() == size_of::<u64>() and we don't currently measure how many we encode. We should put these in their own section to make it easier to measure.

Which filenames do we encode? In practice: probably all source files. We should put these in their own section too.

[anp]

@eddyb could you provide some pointers on how to put static allocations in their own sections? I assume it's a change to librustc_codegen_ssa?

[eddyb]

@anp Yeah, look at how #[link_section] is handled and do the same.

[Mark-Simulacrum]

Have we looked at a diff of a stage1 (or stage2) rustc build? rustc has a lot of expect/unwrap etc code so I suspect if there's essentially no delta then I'm not too worried. I haven't noticed nightlies getting much bigger so I suspect we in practice aren't growing by too much.

[eddyb]

@Mark-Simulacrum this reminds me that we're not measuring size changes on perf.rust-lang.org.

[anp]

Filed: rust-lang/rustc-perf#643

[anp]

OK, here's a gist documenting an instrumentation-based approach. TLDR: rustc with #[track_caller] in the standard library uses ~0.68% of its binary size on the static Location allocations and their filenames but the binary is still quite a bit smaller than a matching stage1 build. I haven't yet been able to observe a conclusive net increase in binary size due to the feature.

The fact that intuitively we know this could cause a net binary bloat makes me think that we want to polish up the custom sections patch in my gist. It's useful instrumentation for the future.

I'm not sure whether this is sufficient motivation to block stabilization on #70580. Thoughts?

[tmandry]

The best way of calculating the impact of the feature itself would be doing two stage2 builds, one with track_caller turned on and one with it off. From your analysis now we know it's no more than 810 kB for rustc.

Percentage of the overall binary size is probably useful, but it's hard to say without seeing more binaries. For a large enough system I'd guess it'd be approximately the same overall, but for smaller binaries it could take up a higher percentage.