llvm dev - Sep 2016 - objc object file generated for gnustep runtime for ELF target is too big

Dear community,

    
I'm using gnustep runtime -fobjc-runtime=gnustep with       gnustep-libobjc2
(https://github.com/gnustep/libobjc2) and
    
Cocotron/Chameleon.
    
For following source file
    
#import <Foundation/Foundation.h>
      #import <UIKit/UIKit.h>
    
int main(void)
        {
                NSString *str = [NSString stringWithCString:"TEST"];
                NSLog(@"test object %@", str);
                return 0;
        }
      
Compilation in xcode's clang
xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c      
test_foundation.m -o test_foundation_apple.o
gives following result:
1. object file has only 3156 bytes size
2. and in disassembler only main function
3. the final executable will be 49992 bytes size in this case

    
But compilation in llvm's clang downloaded from
http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
    
(
clang version 3.8.0 (tags/RELEASE_380/final)
      Target: x86_64-apple-darwin15.0.0
      Thread model: posix
      )
gives another results:
1. object file has 159044 bytes size
2. in disassembler a lot of unnecessary .objc_property_list,      
.objc_method_list, .objc_protocol_list and .objc_protocol  in .bss       and
.data section
3. the final binary size is 101837 bytes size
    

    
If comment in above sample #import <UIKit/UIKit.h, the size of       object
file and binary file in xcode compilation will be the same,
but size binary and object file in case of      
clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced      
sufficiently:
binary 28569 and object 36952 accordingly.
                

    
Looks like all protocols from UIKit.h is placed into       binary/object even
it's not used there.
I got 3.9.0 from public git (branch release_39 of clang git       repository)
and found that all protocols interpret as definition      
(isThisDeclarationADefinition),
and in CGObjCGNU.cpp it's placed into object file whenever it's      
used or not. With the same open source compiler and       -fobjc-runtime=ios
protocols are not putting into
object file even in compilation for ELF (I used -target      
arm-linux-gnueabi).
I used default binutil linker, not llvm's ld.ldd, due to I have problem with
relocation on ARM.
I didn't use LTO, due to my linker doesn't have plugin support (I
didnt' yet recompile it).

Could somebody point me where to solve that problem, is it AST       generation
stage, or linkage stage or maybe it's not a problem and just LTO could be
solution here?

    

    
p.s. It's not only one issue found by me in gnustep runtime      
generation, and I'll report these issues in next emails.
    

    


         Best regards,
        Alexey Perevalov

> On Sep 26, 2016, at 6:33 AM, Perevalov Alexey via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Dear community,
> 
> 
> I'm using gnustep runtime -fobjc-runtime=gnustep with      
gnustep-libobjc2 (https://github.com/gnustep/libobjc2) and
> 
> Cocotron/Chameleon.
> 
> For following source file
> 
> #import <Foundation/Foundation.h>
>      #import <UIKit/UIKit.h>
> 
> int main(void)
>        {
>                NSString *str = [NSString
stringWithCString:"TEST"];
>                NSLog(@"test object %@", str);
>                return 0;
>        }
> 
> Compilation in xcode's clang
Which version?

— 
Mehdi

> xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c      
test_foundation.m -o test_foundation_apple.o
> gives following result:
> 1. object file has only 3156 bytes size
> 2. and in disassembler only main function
> 3. the final executable will be 49992 bytes size in this case
> 
> 
> But compilation in llvm's clang downloaded from
http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
> 
> (
> clang version 3.8.0 (tags/RELEASE_380/final)
>      Target: x86_64-apple-darwin15.0.0
>      Thread model: posix
>      )
> gives another results:
> 1. object file has 159044 bytes size
> 2. in disassembler a lot of unnecessary .objc_property_list,      
.objc_method_list, .objc_protocol_list and .objc_protocol  in .bss       and
.data section
> 3. the final binary size is 101837 bytes size
> 
> 
> 
> If comment in above sample #import <UIKit/UIKit.h, the size of      
object file and binary file in xcode compilation will be the same,
> but size binary and object file in case of      
clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced      
sufficiently:
> binary 28569 and object 36952 accordingly.
> 
> 
> 
> Looks like all protocols from UIKit.h is placed into       binary/object
even it's not used there.
> I got 3.9.0 from public git (branch release_39 of clang git      
repository) and found that all protocols interpret as definition      
(isThisDeclarationADefinition),
> and in CGObjCGNU.cpp it's placed into object file whenever it's    
used or not. With the same open source compiler and       -fobjc-runtime=ios
protocols are not putting into
> object file even in compilation for ELF (I used -target      
arm-linux-gnueabi).
> I used default binutil linker, not llvm's ld.ldd, due to I have problem
with relocation on ARM.
> I didn't use LTO, due to my linker doesn't have plugin support (I
didnt' yet recompile it).
> 
> Could somebody point me where to solve that problem, is it AST      
generation stage, or linkage stage or maybe it's not a problem and just LTO
could be solution here?
> 
> 
> 
> 
> p.s. It's not only one issue found by me in gnustep runtime      
generation, and I'll report these issues in next emails.
> 
> 
> 
> 
> 
>         Best regards,
>        Alexey Perevalov
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

От: mehdi.amini at apple.com <mehdi.amini at apple.com> от имени Mehdi
Amini <mehdi.amini at apple.com>
Отправлено: 27 сентября 2016 г. 8:46
Кому: Perevalov Alexey
Копия: cfe-users at lists.llvm.org; llvm-dev at lists.llvm.org
Тема: Re: [llvm-dev] objc object file generated for gnustep runtime for ELF
target is too big
    
> On Sep 26, 2016, at 6:33 AM, Perevalov Alexey via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Dear community,
> 
> 
> I'm using gnustep runtime -fobjc-runtime=gnustep with      
gnustep-libobjc2 (https://github.com/gnustep/libobjc2) and
> 
> Cocotron/Chameleon.
> 
> For following source file
> 
> #import <Foundation/Foundation.h>
>      #import <UIKit/UIKit.h>
> 
> int main(void)
>        {
>                NSString *str = [NSString
stringWithCString:"TEST"];
>                NSLog(@"test object %@", str);
>                return 0;
>        }
> 
> Compilation in xcode's clang
>Which version?
I think, it doesn't matter, due to with xcode's clang all fine

but if you intersting,

xcrun -sdk iphoneos clang --version
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

also all fine with open source llvm clang if I choose ios as -fobjc-runtime, I
got troubles only with gnustep runtime in clang+llvm-3.8.0 and 3.9.x.
>— 
>Mehdi
> xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c      
test_foundation.m -o test_foundation_apple.o
> gives following result:
> 1. object file has only 3156 bytes size
> 2. and in disassembler only main function
> 3. the final executable will be 49992 bytes size in this case
> 
> 
> But compilation in llvm's clang downloaded from 
http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
> 
> (
> clang version 3.8.0 (tags/RELEASE_380/final)
>      Target: x86_64-apple-darwin15.0.0
>      Thread model: posix
>      )
> gives another results:
> 1. object file has 159044 bytes size
> 2. in disassembler a lot of unnecessary .objc_property_list,      
.objc_method_list, .objc_protocol_list and .objc_protocol  in .bss       and
.data section
> 3. the final binary size is 101837 bytes size
> 
> 
> 
> If comment in above sample #import <UIKit/UIKit.h, the size of      
object file and binary file in xcode compilation will be the same,
> but size binary and object file in case of      
clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced      
sufficiently:
> binary 28569 and object 36952 accordingly.
> 
> 
> 
> Looks like all protocols from UIKit.h is placed into       binary/object
even it's not used there.
> I got 3.9.0 from public git (branch release_39 of clang git      
repository) and found that all protocols interpret as definition      
(isThisDeclarationADefinition),
> and in CGObjCGNU.cpp it's placed into object file whenever
it's       used or not. With the same open source compiler and      
-fobjc-runtime=ios protocols are not putting into
> object file even in compilation for ELF (I used -target      
arm-linux-gnueabi).
> I used default binutil linker, not llvm's ld.ldd, due to I have problem
with relocation on ARM.
> I didn't use LTO, due to my linker doesn't have plugin support (I
didnt' yet recompile it).
> 
> Could somebody point me where to solve that problem, is it AST      
generation stage, or linkage stage or maybe it's not a problem and just LTO
could be solution here?
> 
> 
> 
> 
> p.s. It's not only one issue found by me in gnustep runtime      
generation, and I'll report these issues in next emails.
> 
> 
> 
> 
> 
>         Best regards,
>        Alexey Perevalov
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

llvm-dev Info Page
lists.llvm.org
To see the collection of prior postings to the list, visit the llvm-dev
Archives. Using llvm-dev: To post a message to all the list members, send ...

On 26 Sep 2016, at 14:33, Perevalov Alexey via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Could somebody point me where to solve that problem, is it AST      
generation stage, or linkage stage or maybe it's not a problem and just LTO
could be solution here?
First, please don’t expect the sizes for different runtimes to be the same (or,
necessarily, to be even very close).  The Mac runtimes have a bit more support
from the linker for various things.  To ensure that property introspection is
consistent without this support, the GNUstep runtime IR generation emits
property definitions in all compilation units and then uniques them later.

We’re currently working on a new ABI for the GNUstep runtime that should address
the size issues, but until then this looks pretty much what I’d expect.

David

От: Dr D. Chisnall <dc552 at hermes.cam.ac.uk> от имени David Chisnall
<David.Chisnall at cl.cam.ac.uk>
Отправлено: 27 сентября 2016 г. 10:42
Кому: Perevalov Alexey
Копия: cfe-users at lists.llvm.org; llvm-dev at lists.llvm.org
Тема: Re: [llvm-dev] objc object file generated for gnustep runtime for ELF
target is too big
    
On 26 Sep 2016, at 14:33, Perevalov Alexey via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Could somebody point me where to solve that problem, is it AST      
generation stage, or linkage stage or maybe it's not a problem and just LTO
could be solution here?
>First, please don’t expect the sizes for different runtimes to be the same
(or, necessarily, to be even very close).  The Mac runtimes have a bit more
support from the linker for >various things.  To ensure that property
introspection is consistent without this  support, the GNUstep runtime IR
generation emits property definitions in all compilation units and >then
uniques them later.
>We’re currently working on a new ABI for the GNUstep runtime that should
address the size issues, but until then this looks pretty much what I’d expect.
>David
Thank you David,
I didn't expect the same size for executable file, but I got binary (real
application) for gnustep runtime 5 times bigger than for ios runtime, and then I
decided to figure out it.
(neither -flto nor -fdata-sections -ffunction-sections  -Wl,--gc-sections 
helped).
5x bigber it's not due to only this issue ;) I think.

For small sample (listed above in thread) I found that all protocol's
declaration is interprets as definitions, and I see a lot of
.objc_protocol:
        .long   3
        .long   .L.objc_protocol_name
        .long   .objc_protocol_list
        .long   .objc_method_list
        .long   .objc_method_list.1
        .long   .objc_method_list.2
        .long   .objc_method_list.3
        .long   .objc_property_list
        .long   .objc_property_list.4
        .size   .objc_protocol, 36

        .type   .L__unnamed_37,%object  @ @34
        .section        .rodata.str1.1,"aMS",%progbits,1
.L__unnamed_37:
        .asciz  "copyWithZone:"
        .size   .L__unnamed_37, 14

        .type   .L__unnamed_38,%object  @ @35
...

in disassembler output and in final binary, but these protocol aren't used
in sample. Neither front end nor linker got rid of it.
You wrote definitions will be unique, but it didn't strip out unnecessary
.objc_protocol and depended fields.
(frankly saying after strip -s I didn't see .objc_protocol, but still find
all selector and protocol names in strings output ;)

And it's look like a bug.