[llvm-bugs] [Bug 43419] New: Binary size higher with statically-linked libomp.a

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Sep 23 15:36:31 PDT 2019


            Bug ID: 43419
           Summary: Binary size higher with statically-linked libomp.a
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: pirama at google.com
                CC: danalbert at google.com, llvm-bugs at lists.llvm.org,
                    srhines at google.com

This was originally reported a while ago in the Android NDK bug tracker as

Statically-linking libomp.a for a simple OpenMP hello world program,
https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c, produces a
468K binary (after strip).  gcc + libgomp.a, in comparison, produces a binary
of size 128K.

I want a sanity check if this is expected behavior or if the runtime can be
better organized for static linking.

Steps to reproduce:

Build OpenMP statically with:

$ release/bin/clang++ -fopenmp=libomp omp_hello.cpp -ldl -fuse-ld=lld

$ du -sh a.out

$ strip a.out && du -sh a.out

* gold produces a 464K binary.

* Adding -fvisibility=hidden -ffunction-sections -fdata-sections to C, CXX
flags, and -Wl,--gc-sections,
  the unstripped binary is 2.2M but the stripped binary is 344K.

* Bloaty [https://github.com/google/bloaty]:
$ bloaty a.out -d fullsymbols produces the following:
  75.9%   414Ki  71.2%   338Ki    [1339 Others]
   5.5%  30.3Ki   6.4%  30.3Ki    [section .rodata]
   2.8%  15.1Ki   3.2%  15.0Ki    __kmp_aux_affinity_initialize()
   1.9%  10.6Ki   2.2%  10.6Ki    __kmp_stg_parse_affinity(char const*, char
const*, void*)
   0.0%      39   2.0%  9.65Ki    __kmp_sighldrs
   1.5%  8.35Ki   1.8%  8.35Ki    [section .text]
   1.5%  8.03Ki   1.7%  7.99Ki    __kmp_fork_call
   1.4%  7.89Ki   1.6%  7.78Ki   
__kmp_affinity_create_cpuinfo_map(AddrUnsPair**, int*, kmp_i18n_id*, _IO_FILE*)
   1.4%  7.68Ki   1.6%  7.58Ki   
__kmp_affinity_create_x2apicid_map(AddrUnsPair**, kmp_i18n_id*)
   0.9%  5.18Ki   1.1%  5.12Ki    __kmp_stg_parse_omp_schedule(char const*,
char const*, void*)
   0.9%  4.97Ki   1.0%  4.93Ki    __kmp_allocate_team
   0.8%  4.52Ki   0.9%  4.43Ki   
__kmp_affinity_create_apicid_map(AddrUnsPair**, kmp_i18n_id*)
   0.8%  4.36Ki   0.0%       0    [Unmapped]
   0.0%      52   0.8%  4.00Ki    __kmp_threadprivate_d_table
   0.7%  3.98Ki   0.8%  3.82Ki    void __kmp_dispatch_init_algorithm<long
long>(ident*, int, dispatch_private_info_template<long long>*, sched_type, long
long, long long, traits_t<long long>::signed_t, traits_t<long long>::signed_t,
long long, long long)
   0.7%  3.96Ki   0.8%  3.92Ki    __kmp_balanced_affinity
   0.7%  3.77Ki   0.8%  3.71Ki    __kmp_stg_parse_schedule(char const*, char
const*, void*)
   0.7%  3.56Ki   0.0%       0    [section .symtab]
   0.6%  3.42Ki   0.7%  3.37Ki    __kmp_aux_capture_affinity
   0.6%  3.23Ki   0.7%  3.16Ki    __kmp_partition_places(kmp_team*, int)
   0.6%  3.06Ki   0.6%  2.89Ki    int __kmp_dispatch_next_algorithm<unsigned
long long>(int, dispatch_private_info_template<unsigned long long>*,
dispatch_shared_info_template<unsigned long long> volatile*, int*, unsigned
long long*, unsigned long long*, traits_t<unsigned long long>::signed_t*,
unsigned long long, unsigned long long)
 100.0%   546Ki 100.0%   474Ki    TOTAL

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/20190923/7dd3921c/attachment.html>

More information about the llvm-bugs mailing list