Re: -ffunction-sections -fdata-sections vs. string-inst

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

>> Any thoughts?

> Most tests appear to get smaller.  However, for some reason, some
> tests appear to get *much* larger now.  E.g. see 21_strings/append.cc.
> I am rerunning the entire bootstrap to verify that I didn't somehow
> mess up the libstdc++ rebuild process.  Will report tomorrow.

Here are the results of comparing full bootstraps (with the only
difference being your patch to enable -ffunction-sections
-fdata-sections).  I also offer a full analysis of why this feature
isn't working as expected on my platform (nor many others I expect).

I have removed all shrinkage (weren't very many and all tiny) and any
growths that were within %5.

Also note that (as expected) shared executable sizes didn't change at
all.  Since I detected such changes yesterday, I suspect that
different compiler flags are passed during a make bootstrap build of
libstdc++ and later remake in my environment (sure enough, I appear to
get -O2 in bootstrap case, no optimization in remake case).

--- /dev/fd/3	Fri Jan  7 13:49:20 2000
+++ /dev/fd/4	Fri Jan  7 13:49:20 2000
-63208	4504	345986	21_strings/append.cc
+216500	9477	1586636	21_strings/append.cc
-59032	4088	321122	21_strings/find.cc
+214852	9061	1564683	21_strings/find.cc

I am using the prerelease binutils 2.10.  Unless it is out of date,
here is the reason those executables explode in size (from gcc 2.95.2
info pages):

`-ffunction-sections'
`-fdata-sections'
     Place each function or data item into its own section in the output
     file if the target supports arbitrary sections.  The name of the
     function or the name of the data item determines the section's name
     in the output file.

     Use these options on systems where the linker can perform
     optimizations to improve locality of reference in the instruction
     space.  HPPA processors running HP-UX and Sparc processors running
     Solaris 2 have linkers with such optimizations.  Other systems
     using the ELF object format as well as AIX may have these
     optimizations in the future.

     Only use these options when there are significant benefits from
     doing so.  When you specify these options, the assembler and
     linker will create larger object and executable files and will
     also be slower.  You will not be able to use `gprof' on all
     systems if you specify this option and you may have problems with
     debugging if you specify both this option and `-g'.

Here is some information from ld/NEWS (from the 2.10 prerelease of
binutils) which makes be believe that the gcc info page is more or
less up-to-date:

* Added garbage collection of unused sections, enabled by --gc-sections. 
  It does require a bit of backend support; currently implemented are
  ppc-elf, mips-elf, and mn10300-elf.  Others will ignore the option.

Assuming my analysis is correct, the upshot is that any useful
configure test may not rely on gcc accepting the -ffunction-sections
and -fdata-sections options alone since the underlying ld may not
support the feature (even binutils 2.10 does not support it yet - at
least on my ELF platform).

If you give those two options to gcc at compile time, then
-Wl,--gc-sections has to be given to gcc for the link iff GNU ld is
the linker (since the default is --no-gc-sections).  I don't think the
current patch does that (although check the comments near the changes
of the patch, -Wl,--gc-section is mentioned).

Also, -ffunction-sections and -fdata-sections should only be applied
while building objects destined for the static library.  Those options
don't help (and from the warning above may actual hurt) construction
of the shared library w.r.t. size and debugging on some platforms.

OTOH, I suspect that any developers (maybe even users) configured with
--enable-shared would prefer faster bootstrap since they will rarely
use the static libraries.  Thus, it might be nice to be able to
disable all fancy machinery related to -ffunction-sections and
yet force building of the string stuff in one big chump.

Regards,
Loren