@brikler, I read it!
clang's -flto=thin attempts to make lto more scalable by breaking up compilation (using less memory at the cost of somewhat less thorough optimization), similar to gcc's -fwhopr. This is sometimes necessary when compiling very large programs with lto. This may also decrease compile time, as less effort is made to find optimization opportunities in distant parts of the code. EDIT: I have since learned that clang's lto uses a number of threads equal to the number of cores by default, and the flag to control this is --thinlto-jobs=N.
gcc's -flto=n parallelizes the optimization threads, which may also decrease compile time but requires a significantly greater amount of free memory as it searches through larger sections of code (and in multiple threads). EDIT: I have since learned that -fwhopr was scrapped and incorporated as the default behavior of -flto=n; the original behavior can be restored by additionally specifying -flto-partition=none
They are both lto methods, but their goals and results differ.
-flto=thin is not supported by gcc, and -flto=n is not supported by clang. In order to support both, I'd have to come up with some means (in ''lto.sh.in'') of distinguishing which compiler is intended to be used. Perhaps there is something in makepkg's code I could use.
There are actually a lot of other lto-related flags to consider as well. I might make a few other changes to the lto macro, but it's troublesome that the compilers are using mutually incompatible options (makes my job harder).
On a hunch, I went looking for pgo in clang, and found that they are using different flags on the command line and different terms in their documentation. Rather than "profile guided optimization", clang's devs are calling it "profiling with instrumentation".
At the moment makepkg-optimize's macros can only be said to support gcc. I'll look into adding support for clang, and making sure gcc-specific flags aren't getting sent to non-compliant compilers.
Edit: Looking at the archwiki page for clang, in the header it mentions having to edit makepkg.conf to set up the compiler. Doesn't seem like makepkg has any built-in mechanism to set the compiler. This could be an opportunity for libmakepkg--perhaps something like a supplemental buildenv script could be used to switch compilers and filter flags. Not yet sure if I'm talking about a few scripts (maybe another aur package, ie 'makepkg-compilers') or a massive change to makepkg itself (to be proposed, revised, argued, and fought over on the mailing list; then perhaps, someday, implemented).
Pinned Comments
quequotion commented on 2019-02-27 07:49 (UTC) (edited on 2022-01-09 13:20 (UTC) by quequotion)
makepkg-optimize is a collection of libmakepkg tidy, buildenv, and executable extensions, and a supplement to pacman. These enable various optimization routines for building and packaging such as upx compression, profile guided optimization, polyhedral model optimization, etc..
Note: Over-optimization is a thing, and it is not good.
See the wiki article for details.
Note to packagers: makepkg-optmize's macros may be enabled or disabled in options() as well!