[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