[Bug 261977] lang/gcc12-devel: enable LTO

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261977

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to commit-hook from comments #3 and #5)

These changes have caused large increases in my build times and resource usage
build building gcc* 's --without providing an OPTION to control the behavior.

For example, I built lang/gcc12-devel on a 16 Cortex-A72 HoneyComb with 64
GiByes of RAM. This was the only builder active and the machine was otherwise
unloaded. It was allowed use of all 16 cores. It took 4 hours to build and
at one point got: 12278Mi MaxObs(Act+Lndry+SwapUsed). [But no swap usage was
ever reported, so: Act+Lndry.] At least twice there were 7 /usr/local/bin/ld
processes doing lto1 activity at the same time over long periods. The large
Act+Lndry was from one of these times.

(I have a patched version of top that monitors and reports various
"Maximum Observed" figures.)

I'll note that my prior build of devel/llvm14 (.r4) by otself via the
HoneyComb [also unloaded] took under 1hr 40 min. But, in that case, I
had used:

# more /usr/local/etc/poudriere.d/options/devel_llvm14/options 
# This file is auto-generated by 'make config'.
# Options for llvm14-14.0.0.r2
_OPTIONS_READ=llvm14-14.0.0.r2
_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU BE_WASM CLANG DOCS EXTRAS FLANG LIT LLD
LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD
OPTIONS_FILE_SET+=BE_AMDGPU
OPTIONS_FILE_UNSET+=BE_WASM
OPTIONS_FILE_SET+=CLANG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXTRAS
OPTIONS_FILE_UNSET+=FLANG
OPTIONS_FILE_SET+=LIT
OPTIONS_FILE_SET+=LLD
OPTIONS_FILE_SET+=LLDB
OPTIONS_FILE_SET+=MLIR
OPTIONS_FILE_SET+=OPENMP
OPTIONS_FILE_UNSET+=PYCLANG
OPTIONS_FILE_UNSET+=BE_FREEBSD
OPTIONS_FILE_SET+=BE_NATIVE
OPTIONS_FILE_UNSET+=BE_STANDARD

So one could argue with how to make such a comparison.

I looked around that the package status information from various
builds and sometimes lang/gcc12-devel gets runaway_process and
other times completes. My guess for the official build servers
is that it depends on what other builders are doing over the
same time frame.

But there is another, possibly related issue. In my 16-core context,
top reported:

last pid: . . .;  load averages:  . . . MaxObs:  28.02,  17.04,  16.87

So, on the timescale of the first load average, the lang/gcc12-devel
build does not always stay limited to the hardware threads available.
(I happen to have my configuration set up for high load average
contexts.)

Overall, the implications of the LTO based builds for those with
systems with signficantly less resources are messy for them.

I understand having default options that match what the FreeBSD build
servers are supposed to build. But not having control of such things
without editing of the Makefiles seems odd for the general audience
that does local builds. (I can maintain adjusted Makefiles so I am
not stopped from reverting the code for my own activities. But still
. . .)

-- 
You are receiving this mail because:
You are on the CC list for the bug.