|
Date: Tue, 27 Oct 2015 17:01:24 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] configure: add gcc flags for better link-time optimization On Tue, Oct 27, 2015 at 08:09:28PM +0100, Denys Vlasenko wrote: > On Tue, Oct 27, 2015 at 2:21 AM, Rich Felker <dalias@...c.org> wrote: > > On Fri, Oct 23, 2015 at 03:12:02PM +0200, Szabolcs Nagy wrote: > >> * Denys Vlasenko <vda.linux@...glemail.com> [2015-10-23 14:30:26 +0200]: > >> > libc.so size reduction: > >> > > >> > text data bss dec hex filename > >> > 564099 1944 11768 577811 8d113 libc.so.before > >> > 562277 1924 11576 575777 8c921 libc.so > >> > > >> > >> i assume this is x86_64, nice improvement. > > > > I suspect all of this difference comes from optimizing out dummy weak > > functions that are replaced by strong versions in other files. > > No, it does not look that way. These options don't give linker > any extra freedom to eliminate anything. > > "nm --size-sort -D libc.so" shows no differences after > > --sort-section=alignment --sort-common > > were added to ld command line. Oh, sorry, I misread which change that difference was coming from. In that case it's a pleasant surprise. > After -ffunction-sections -fdata-sections are added to gcc command line, > "nm" output does change, the entire difference is as follows: > > --- libc.so.nm.OLD 2015-10-27 19:57:52.971964518 +0100 > +++ libc.so.nm 2015-10-27 19:58:28.544115009 +0100 > @@ -18,7 +18,6 @@ > 0000000000000001 T setutxent > 0000000000000001 W updwtmp > 0000000000000001 T updwtmpx > -0000000000000002 T dlclose > 0000000000000002 T __stack_chk_fail > 0000000000000003 T catclose > 0000000000000003 T dirfd > @@ -84,6 +83,7 @@ > 0000000000000005 T catopen > 0000000000000005 T creall > 0000000000000005 T dladdr > +0000000000000005 T dlclose > 0000000000000005 T dlinfo > 0000000000000005 T __fbufsize > 0000000000000005 T __freadptrinc > @@ -328,7 +328,6 @@ > 000000000000000b T recv > 000000000000000b T send > 000000000000000b T setprotoent > -000000000000000b T tfind > 000000000000000b T __xstat > 000000000000000b W __xstat64 > 000000000000000c T __acquire_ptc > @@ -417,6 +416,7 @@ > 000000000000000e T tcflow > 000000000000000e T tcflush > 000000000000000e T tcsendbreak > +000000000000000e T tfind > 000000000000000f T dcgettext > 000000000000000f T execv > 000000000000000f T execvp > @@ -986,8 +986,6 @@ > 0000000000000032 T pthread_rwlock_init > 0000000000000032 T putchar_unlocked > 0000000000000032 T sem_init > -0000000000000032 T __stdio_exit > -0000000000000032 W __stdio_exit_needed > 0000000000000032 T wcschr > 0000000000000033 T pthread_rwlock_tryrdlock > 0000000000000033 T pthread_setcanceltype > @@ -1011,6 +1009,8 @@ > 0000000000000035 T pthread_sigmask > 0000000000000035 T pwritev > 0000000000000035 W pwritev64 > +0000000000000035 T __stdio_exit > +0000000000000035 W __stdio_exit_needed > 0000000000000035 W thrd_detach > 0000000000000035 T __tre_mem_destroy > 0000000000000035 T tsearch > > As you see, not a single label was eliminated. > > > The visible small differences in size for a few functions are caused > by the need to always use "near" jumps (not "short" ones) > for tail call optimizations now, since they now jump across sections: > > Before: > 00000000000274a6 <dlclose>: > 274a6: eb c8 jmp 27470 <__reset_tls+0x1f0> > After: > 000000000002795f <dlclose>: > 2795f: e9 c5 ff ff ff jmpq 27929 <__reset_tls+0x1f0> I see. That's probably not a big deal. Did you see any symbols disappear when adding --gc-sections? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.