[m-users.] Link-time optimization

Massimo Dentico m.dentico at virgilio.it
Sat Jun 13 23:02:29 AEST 2020


Sorry Peter for the duplicate, this was intended to for all the
mailing-list, not just to you.

On 13/06/2020 04:24, Peter Wang wrote:
 > [...]
 > The Linux binaries do not include the C standard library, which is
 > dynamically linked by default. I believe your Windows binaries will
 > statically link the C library so that would make up at least part of
 > the difference.

I checked with Dumpbin to be sure and the Microsoft C Runtime Library
(msvcrt.dll) is linked dynamically:

    C:\mercury\bin>dumpbin /dependents mercury_compile.exe
    Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
    Copyright (C) Microsoft Corporation.  All rights reserved.

    Dump of file mercury_compile.exe

    File Type: EXECUTABLE IMAGE

      Image has the following dependencies:

        KERNEL32.dll
    >>> msvcrt.dll <<<
        libwinpthread-1.dll

      Summary
        [... sections omitted ...]


 > BTW, a simpler (faster?) option for reducing binary sizes is using the
 > gcc and clang options -ffunction-sections -fdata-sections,
 > and the linker option --gc-sections.
 > http://lists.mercurylang.org/archives/reviews/2014-August/017151.html

I preferred to use LTO because in the GCC manual apropos of
"-ffunction-sections -fdata-sections" they wrote:

    Only use these options when there are significant benefits from doing
    so. When you specify these options, the assembler and linker create
    larger object and executable files and are also slower. These options
    affect code generation. They prevent optimizations by the compiler
    and assembler using relative locations inside a translation unit
    since the locations are unknown until link time. An example of such
    an optimization is relaxing calls to short call instructions.

Possibly I will also try these options.


 >> b. How much effort would be needed to modify the Mercury compiler
 >>      (specifically the back-end that produces high-level C code)
 >>      to produce a single stand-alone C file? That is, a single source
 >>      file easy to include in other C projects, which has *only* the
 >>      necessary machinery from the run-time library and refers to C
 >>      standard libraries only, with an option to avoid them too.
 >
 > A lot of effort.

I suspected it but I wanted to be sure. To this end I'll try to
resurrect CMI then, if it will not cause too much troubles:

    * Cross-Module Inliner, from the Flux Research Group at the
      University of Utah's School of Computing
    https://www.cs.utah.edu/flux/knit/cmi.html

--
Massimo A. Dentico



More information about the users mailing list