[llvm-bugs] [Bug 38346] New: ObjC++ type encodings can be very large (20K+)

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Jul 27 16:00:27 PDT 2018


            Bug ID: 38346
           Summary: ObjC++ type encodings can be very large (20K+)
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: neuberger at gmail.com
                CC: llvm-bugs at lists.llvm.org

ObjC uses type encoding to facilitate message passing. When you pass a C++ type
to an ObjC method, the encoding recurses the C++ type and for complex C++
objects it can be really huge (we have a few ObjC++ methods that result in
130KB added to our final binary).

If you run "objdump -macho -objc-meta-data SomeObjectFile.o" on an object file
that has an ObjC method that takes a C++ parameter, you'll see something like:

types 0x6112 v40 at 0:8{shared_ptr<Foo::Bar>=^{Bar}^{__shared_weak_count}}16 at 32

This is a really small one, but if you take it out of the shared_ptr and pass
it as a raw pointer, this type would grow to be 20,000 characters long for our
Foo class. There's no compression or deduplication, so if you have 5 ObjC
methods that take this C++ type as a param, the type encoding will appear 5

It seems you can prevent the C++ type from being recursed by hiding it behind a
pointer (which is what shared_ptr ends up doing above). I do that with a simple
helper class:

template<class T>
class ObjCppPtrWrapper {
    T* o;
    ObjCppPtrWrapper(T* t) : o(t) {}
    ObjCppPtrWrapper() {
        o = nullptr;

Can clang just put the class name into the type encoding, instead of recursing
into the type? Is it possible that some code to support anonymous structs is
being accidentally called for all C/C++ types? The relevant code I believe is

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180727/88e4ec35/attachment-0001.html>

More information about the llvm-bugs mailing list