Rimvydas Jasinskas has been improving LTO – Link Time Optimization – support. It’s led to a lot of commits, and those are just a few examples.
One Reply to “Better Fortran”
Comments are closed.
A running description of activity related to DragonFly BSD.
LTO in general is not limited to any particular language, it just happened that my case is big’ish fortran project with quite a few ISO_C_BINDINGS to C that get quite expensive when moving bigger chunks of data for post-processing. LTO allows to quickly detect the cases where certain assumptions on data layouts doesn’t stand or there is mismatches in different compilation units that were overlooked and likely would cause long debugging sessions trying to understand what and were went wrong. But best use of LTO is to detect algorithms that could be done in a more optimized way. Member the days when programs could fit in the floppies?
Currently on DragonFly master buildworld and buildkernel has only limited support for -flto compilations. Certain parts (like csu, ld-elf.so, libc, libpthread and ofc libm) are excluded from using LTO for obvious reasons (for now). Note, even if certain subsets of those parts could use and benefit from -flto provided information, it is very easy to expose too much internals and have over optimization issues (not all sources can pass as “legal” C code). Build system makefiles were adapted to ease up the -flto compilations as much as possible while trying to find compromise between WARNS/WERROR and over complicating makefile logic. For most users it will be just:
make -jN buildworld WORLD_CCFLAGS=”-flto” WORLD_CCOPTLEVEL=2 && make installworld
LTO’ed installworld is still compatible with DPorts packages compiled from source as long utilities from the dports devel/binutils package are not used in compilations where static base system libraries(having the slim LTO objects, shared libraries are OK) get linked in or packages that are not aware of LTO in general.
Users are expected to be familiar with how LTO works and what are the requirements for the toolchain to support it. In most cases it would be enough to just pass -plugin option for ar, ld, nm, ranlib, like: /usr/local/bin/nm –plugin `gcc -print-prog-name=liblto_plugin.so` (only for dports gcc compilers, base gcc50 will soon be patched to give that information too). Also for the moment plain -flto addition to CFLAGS is left boobytrapped to fail in libarchive contrib sources to prevent one way ticket installations where users can no longer bootstrap a new buildworld.
Any testing efforts will be very welcomed.