[llvm-dev] distinct DISubprograms hindering sharing inlined subprogram descriptions

[via llvm-dev]

My recollection is that type units can end up being used for types that actually don’t take up a lot of space, and so the overhead of the type units ends up costing extra.  I put a task on our internal tracker to look into this properly, but we wouldn’t mind if someone else had a run at it (if only to prove that my recollection is incorrect).
Thanks,
--paulr
who is on vacation and really shouldn’t be looking at these emails

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Reid Kleckner via llvm-dev
Sent: Friday, October 15, 2021 3:26 PM
To: David Blaikie <dblaikie at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] distinct DISubprograms hindering sharing inlined subprogram descriptions

Sorry for derailing into your aside, but...

On Fri, Oct 15, 2021 at 12:07 PM David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote:
(side note: Anyone interested in making ThinLTO home type definitions? That'd be great to reduce type duplication - would mean ThinLTO could turn off type units and/or that .o/.dwo/etc files would just generally be smaller anyway)

Hey, I think that is a great idea! ThinLTO tends to be used in release build configurations, which tend to have debug info enabled. The size of symbols in release build config matters a lot because it is typically archived for a long time.

COFF & MachO platforms have other ways to deduplicate types (PDBs & dsymutil), but less duplicate stuff always makes things faster.

For ELF users already using type units, this optimization will only allow us to recover the overhead of type units, which I recall is significant. In our evaluation of the feature for Chrome, we found it increased the final binary size significantly: crbug.com/1031936#c4<https://urldefense.com/v3/__http:/crbug.com/1031936*c4__;Iw!!JmoZiZGBv3RvKRSx!qg0PDEAWoBKjGth7hk524aPYTrQqB8FrCOws1hiil6XaLGH_lFZRG8n7oW4wMKqPkA$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211015/d9f6d3fe/attachment.html>