[m-users.] Link-time optimization

[Massimo Dentico]

Hi list.

I installed the Mercury compiler for the first time months ago, for
learning and experimentation at first. I would like to propose it to a
small local (Italian) software house for some exploratory projects and,
in case of satisfactory results, to production use.

I'm particularly interested to ascertain if the results detailed in [1]
are achievable in the context of software development for micro/small
business (per EU definition as number of employees: micro<10, small<50,
medium<250).

[SIDE NOTE: I'm on Windows 10 64 bit and I use Msys2, updated to the
last GCC stable version available:

    $ gcc --version
    gcc.exe (Rev3, Built by MSYS2 project) 10.1.0

When I bootstrapped the compiler I had to move the directory where mmc
is installed at the head of PATH variable (I choose to add mmc to PATH
in my .bashrc), otherwise it conflicted with mmc.exe (Microsoft
Management Console) in "C:\Windows\System32\". I see that this is a long
known annoyance§ but I haven't found it mentioned in the documentation.

§ 
https://github.com/Mercury-Language/mercury/issues/38#issuecomment-178687600
]

I were somewhat disappointed by the size of executable produced by the
Mercury compiler. A cursory inspection of the C source files produced
revealed the most probable source of such large executables: most (all?)
of the run-time library is always linked in. More on this later.

In the last months I were distracted by other things but the very
interesting results in this Peter Wang's email of January caught my
attention:

    * [m-dev.] LTO benchmarks
 
http://lists.mercurylang.org/archives/developers/2020-January/017070.html

I recompiled mercury-srcdist-20.01.2 with this shell script:

    export CFLAGS="-Os -flto -fuse-linker-plugin"
    export GRADE="hlc.gc"
    export EXTRA_MCFLAGS="-O5 --intermod-opt"
    make PARALLEL=-j2
    make PARALLEL=-j2 install

with this results:

    real    167m36.827s
    user    13m42.766s
    sys     48m28.633s

    mercury_compile.exe 21.5 MiB (22'552'436 bytes)

(Yes, it was slow, I have a 14 years old machine at home, Intel Pentium
E2160, 1M Cache, 1.80 GHz, 800 MHz FSB; sources and target directory
onto an SSD.)

21.5 MiB is better than ~30 MiB of the preceding compile without LTO but
it still isn't ~10 MiB documented by Peter (gcc-lto — yes, I see that
GCC version is different and he is on Linux, but a difference of ~10 MiB
seems too much to me).

Compiling "mercury-srcdist-20.01.2/samples/hello.m" with

    $ mmc --mercury-linkage static -s hlc.gc -O5 --intermod-opt hello.m

gives a 3.02 MiB (3'174'400 bytes) "hello.exe".
With

    $ export CFLAGS="-Os -flto -fuse-linker-plugin"
    $ mmc --mercury-linkage static -s hlc.gc -O5 --intermod-opt hello.m

the difference is negligible: 3.02 MiB (3'173'376 bytes).

QUESTIONS

a. What am I doing wrong (wrt Peter results)?
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.
    I would like to distribute this C file as a library, to people
    without a Mercury compiler installed, so that they can compile it
    with a (compatible) C compiler without problems.

Regards.

--
Massimo A. Dentico

REFERENCE
1. Ontology driven software engineering for real life applications
    http://mercurylang.org/documentation/papers.html#mc_swese_2007