Tip: library size reduction

Thiago Macieira thiago at kde.org
Fri Jul 3 08:22:36 BST 2009


Michael Pyne wrote:
>On Thursday 02 July 2009 21:29:44 Benjamin Meyer wrote:
>> Why not work on getting a patch for upstream in gcc?
>>
>> -Benjamin Meyer
>
>I'm not convinced it's actually a GCC bug.  The bug was closed as
> not-a-bug, saying that the different ctors were for the base object and
> not-a-base-object constructors[1].  At best I'd say that gcc could
> perhaps point both mangled names to the same generated code but that
> probably breaks a ELF or ABI requirement.
>
>[1] If I understand it correctly, one is for the case of the constructor
>having to allocate memory, and the other is for the case of a
> constructor that is a subclass.  In the case given in the bug the class
> is not subclassing anything else so the ctors are the same.  I think
> the case of virtual base classes can itself introduce a different type
> of ctor but I don't have time to Google it right now.

GCC doesn't use the allocating constructor base.

The two possibilities for constructors are the one initialises virtual 
bases and the one that doesn't. Since we mostly don't use virtual bases in 
KDE, we'll have only one constructor created in most cases.

However, GCC does use deleting destructors. So there are three 
possibilities: deleting, non-deleting but calling virtual bases, and non-
deleting and not calling virtual bases. If you have no virtual bases, you 
have two: deleting and non-deleting.

This is part of the ABI. It can't be changed.

It could be optimised by sharing code though. If we can add an "init" and 
a "destroy" private functions to reduce code size, so can GCC. It already 
does that for thunks anyway.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090703/1da473e7/attachment.sig>


More information about the kde-core-devel mailing list