[R-SIG-Mac] Link-Time Optimization (LTO)

[Prof Brian Ripley]

This is a rather technical post about how libraries of compiled code can 
be further optimized.  LTO generally produces smaller[*] and faster code 
(typically by a few percent) at the expense of increased installation 
time and is being used for large projects such as browsers and soon for 
some Linux distributions.

I have committed a series of enhancements to LTO support in R-devel and 
will shortly port the more important of these to R-patched.

This includes pretty comprehensive LTO support for clang, mainly to make 
LTO usable on macOS.  (LLVM/clang has diverged considerably from GCC in 
how LTO is implemented - in particular with 'Thin LTO'.)

Full details (including example settings for macOS) are in the R-admin 
manual.

I would not use LTO on macOS routinely (I do on Linux), but for some 
applications the performance gains[+] maybe valuable enough.  By the 
time R 4.1.0 is released it may be worth using it for the distributed R 
and binary packages

LTO can be used to find inconsistencies between C/C++ compilation units 
as reported in the CRAN LTO 'Additional issues'.  Unfortunately it 
cannot help with the more common C/Fortran inconsistencies as the 
intermediate representation used by gfortran is different and ignored by 
the macOS linker.  An LLVM-based Fortran compiler (variously called 
flang and f18) has been promised for years but is being re-implemented 
and is far from usable.

[*] although probably due to inlining, sometimes larger as it is for 
libR.dylib.

[+] some R test scripts show negligible change in performance, several a 
gain of 5% and a couple a gain of 10-15%.  Installation times depend 
rather a lot on how much one can make use of multithreading: on my 
dual-core MBP total R build elapsed time increased from 7:13 to 8:04 (m:s).

-- 
Brian D. Ripley,                  ripley using stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford