Date: Sun, 27 Mar 2022 01:43:44 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 261977] lang/gcc12-devel: enable LTO Message-ID: <bug-261977-29464-9zcA87LhDT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261977-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-261977-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261977 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 us= age build building gcc* 's --without providing an OPTION to control the behavio= r. 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 otherwi= se 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=20 # This file is auto-generated by 'make config'. # Options for llvm14-14.0.0.r2 _OPTIONS_READ=3Dllvm14-14.0.0.r2 _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU BE_WASM CLANG DOCS EXTRAS FLANG LIT= LLD LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=3DBE_AMDGPU OPTIONS_FILE_UNSET+=3DBE_WASM OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_UNSET+=3DFLANG OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB OPTIONS_FILE_SET+=3DMLIR OPTIONS_FILE_SET+=3DOPENMP OPTIONS_FILE_UNSET+=3DPYCLANG OPTIONS_FILE_UNSET+=3DBE_FREEBSD OPTIONS_FILE_SET+=3DBE_NATIVE OPTIONS_FILE_UNSET+=3DBE_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 . . .) --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261977-29464-9zcA87LhDT>