[m-rev.] preliminary review: Removing dead code at link time.

[Julien Fischer]

Hi Peter,

On Fri, 8 Aug 2014, Peter Wang wrote:

> After making this patch I remembered to check what to do on OS X.
> It seems there you only need to pass -dead_strip to the linker,
> so the --split-sections flag is specific to Linux or ELF targets.
>
> We could drop most of this patch and just build the standard library
> and runtime with `-ffunction-sections -fdata-sections' where it helps,
> and leave it to the user to pass the correct linker flag if they care.
>
> ---
>
> This patch makes it more convenient to reduce executable sizes,
> using the gcc and clang options `-ffunction-sections -fdata-sections'
> and the linker option `--gc-sections'.  The former places functions and
> data into their own sections in object files so they can be removed
> individually; the latter performs the removal.
>
> We introduce a Mercury compiler and mgnuc flag `--split-sections'
> which passes `-ffunction-sections -fdata-sections' to the C compiler.
> It is off by default because it makes the object files larger and most
> user code would hopefully not see much benefit from it.  There are some
> warnings about problems with gprof or debugging in the gcc manual.

Perhaps it should be disabled by default for everything in the .ll_debug
grades.

> We introduce a Mercury compiler and ml flag `--gc-sections' which passes

Given that the documentation you added below has to have sentence
mentioning that this has nothing to do with the garbage collector, a
better name for this option might be somthing like

    --strip-dead-sections

(Indeed, since the option for dead procedure elimination in Mercury is
--optimize-dead-procs, perhaps --optimize-dead-sections?)

> `-Wl,--gc-sections' through to the linker.  It is off by default, as it
> makes linking noticeably slower.

Perhaps it should be implied by --opt-space?

> We enable `--split-sections' when building the runtime and standard
> library.
>
> On Linux/x86-64, `hello' goes from 4.1 MiB to 663 KiB in size
> and `mercury_compile' goes from 16 MiB to 13 MiB.
> (both statically linked to the Mercury libraries and stripped)
>
> configure.ac:
> scripts/Mercury.config.in:
> 	Set CFLAGS_FOR_SPLIT_SECTIONS for gcc or clang.  gcc has
> 	supported `-ffunction-sections -fdata-sections' since at least
> 	2.95.3, and clang as of 2010, so probably long enough.
>
> 	Set LD_GC_SECTIONS_FLAG after testing if "-Wl,--gc-sections"
> 	works.
> 	XXX -dead_strip on Darwin?

I'll look into the Darwin side of things after you commit.

...

> diff --git a/doc/user_guide.texi b/doc/user_guide.texi
> index addcfac..051dccb 100644
> --- a/doc/user_guide.texi
> +++ b/doc/user_guide.texi
> @@ -9339,6 +9339,13 @@ This option has no effect if @samp{--gc boehm}
> is not set or if the C compiler is not GNU C.
>
> @sp 1
> + at item --split-sections
> + at findex --split-sections
> +Tell the C compiler to place each function or data item into
> +its own section in the object file.
> +This option has no effect if the C compiler is not GNU C or clang.

Aside: at some point we should decicde whether it's "GNU C" or "GCC" and
stick to one of them.

> @sp 1
> + at item --gc-sections
> + at findex --gc-sections
> +Tell the linker to garbage collect unused input sections in object files
> +if supported.
> +(This option has nothing to do with the Mercury garbage collector.)

Which is why I don't think this is a good option name (see above).

That looks okay otherwise.

Cheers,
Julien.