[llvm-dev] Homing types in ThinLTO

[David Blaikie via llvm-dev]

Since this aside got a life of its own - changing the subject to reflect
that.

On Fri, Oct 15, 2021 at 12:47 PM <paul.robinson at sony.com> wrote:

> 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> 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.
>

Yeah, I had some vague idea (I forget whether I've implemented parts of it)
to have the frontend make smart decisions about whether to put a linkage
name on a type (used for deduplicating during IR linking, and also used as
the key for DWARF type units) if it knew the type was being emitted only
once (eg: if it had a strong vtable - no need to use a type unit).

That'd have some wins straight away for situations like strong vtables (or
I guess we could do something similar with ctor homing - if the type only
has one ctor and it has strong linkage, and explicit template
specializations... maybe you can technically have more than one of those?
Ah well) - and then if we taught ThinLTO to remove the linkage name from a
type and "promote" it to a singular definition, stripping it out from other
modules - it could benefit there too.

I mean, we'd probably just end up turning off type units entirely under
ThinLTO because it'd be "perfect" (hmm, only if it's whole program/you're
not deduplicating types with objects outside the ThinLTO scope... ) - so
the "opting out of type units on a per-type basis" part of this probably
isn't necessary but a nice way to express things anyway, maybe.


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

Yep yep.


> 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$>
>

Yep, the overhead is significant (hmm - you'd only see an increase in the
final binary size if there were very few duplicates - perhaps after ctor
homing that was the case that there was so little duplication that the
advantages of deduplicating were outweighed by the overhead of type units)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211015/3d04dd59/attachment.html>