[m-users.] Link-time optimization

Massimo Dentico m.dentico at virgilio.it
Sat Jun 13 20:56:14 AEST 2020

On 13/06/2020 04:09, M McDonough wrote:
> It's not just enough to put the LTO flags in the CFLAGS, since the
> standard library (which accounts for much of the executable size in my
> experience).
> There is an LTO option during configuration, although I only seriously
> tested it for MSVC since that's my main target on Windows and shared
> libraries aren't possible with Mercury in that configuration. That
> will reduce the resulting exe file by quite a lot.

Thanks a lot, I completely missed it the last time I looked at the 
output of "./configure --help" (maybe it wasn't there before version 20?)

Ok, I'll try restarting from scratch and passing "--enable-lto" to 

> The LTO flags are implemented for gcc and clang as well as MSVC, but I
> am unsure if it's done in an optimal way (a large part of why it's
> marked as experimental I believe).
> Using LTO will also cause the linking steps to be quite long, since
> it's basically compiling the entire Mercury runtime and standard
> library at that point.

Yes, my experience with compiling other software with LTO is that
compilation is a bit faster and linking is slower. I would like to try
to pass "-fno-fat-lto-objects" to GCC:

    Note that when -fno-fat-lto-objects is enabled the compile stage is
    faster but you cannot perform a regular, non-LTO link on them.

But if passing "-flto" in CFLAGS is not effective, I think that passing
"-fno-fat-lto-object" will also not be effective. But I can be wrong:
my experience with Autotools is limited, I have always used them as a

> ...................... But the file size is quite a bit smaller. The
> actual performance change is pretty minor from my experience over just
> intermodule optimization, since intermodule-optimization tends to be
> very effective before the actual grade's compiler even gets the code.

Well, I was attracted to Mercury for the performance of the executables 
produced by its compiler compared to Prolog interpreters/compilers, so 
at the moment I'm more interested in producing executables of reasonable 

Next I'll investigate how much the tools based on Datalog variants (e.g. 
Soufflé) are apt to the task of high-level intermediate target for 
specifications-as-programs (business rules, ontologies and so on) and 
what are their performances.

It's unfortunate that Mercury is missing in this comparison of
declarative systems:

    * Benchmarks of Deductive Database Systems, Relational Databases, 
and Graph Databases – Introduction to rbench

Massimo A. Dentico

More information about the users mailing list