Date: Wed, 8 Jul 2020 03:10:44 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Stefan_E=C3=9Fer?= <se@freebsd.org> Cc: svn-src-head@freebsd.org, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) Message-ID: <D650A757-F668-4CE5-B652-E2BF347D62FD@yahoo.com> In-Reply-To: <d96b12df-cbff-387d-7bf4-bc5b279b10f4@freebsd.org> References: <64523602-7EFC-4A97-90EA-C776BF2A0AF7.ref@yahoo.com> <64523602-7EFC-4A97-90EA-C776BF2A0AF7@yahoo.com> <d96b12df-cbff-387d-7bf4-bc5b279b10f4@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-8, at 01:28, Stefan E=C3=9Fer <se at freebsd.org> wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain use >> to see what the current status is for such use.) >>=20 >> I attempted to build a system for 32-bit powerpc using clang >> and binutils, building head -r363000 ( from -r363000 ). (This >> was a cross build, amd64 -> powerpc.) It got a new type of >> failure, compared to my past experience: >=20 > Hi Mark, >=20 > thank you for the report. I have tested with "make universe" (with > default settings) that this version builds on all architectures, > but Ed Maste has already disabled -flto for powerpc64, due to run > time issues (floating point exception, IIRC). The builds I actually run are based on pure-llvm, not such odd mixes --nor even gcc+binutils. Also, I've not even tried a build since updating to head -r360311 --until now trying to update things to head -r363000 (or so). It is not obvious to me that FreeBSD intends for gcc based builds or binutils based buildworld buildkernel to be supported, even without mixing in LLVM. The ci.freebsd.org builds via gcc6 for amd64 have not completed in a very long time. My standard build procedure historically builds combinations like clang-with-binutils that used to completely build. (Not that the result worked to boot and operate an old PowerMac in recent times.) So I noticed this just by the build procedure failing. There are other combinations that failed some time ago that I turned off in my build procedure after sending a notice to the lists. As of the official switch to llvm-based for powerpc64 and powerpc, I've not been able to boot and operate anything but pure-llvm based builds, even for other types of builds that did "complete". That includes not being able to build and operate system based on modern gcc+binutils without LLVM. It appears to me that it would be a fair sized effort to get gcc+binutils working for powerpc64 or powerpc. My history with odd combinations derived from experimenting with more modern toolchains for powerpc64 and powerpc back in the gcc 4.2.1 days when no llvm based linker was affectively available. Although, I do like the idea of having code pass through and the result operate based on multiple toolchains, not just one, say, modern gcc+binutils as an alternate. Still, if FreeBSD declared "gcc not supported" and "binutils not supported" and "gcc+binutils not supported" for building FreeBSD, I'd just stick to llvm based. > I know that you are actively working on PowerPC and I'd appreciate, > if you could provide me with information on which parameters cause > breakage and which work for you. I think that the answer is: only pure llvm-based has worked for booting and operating since the switch away from gcc 4.2.1 for powerpc64 and powerpc. Everything else either stops the build early or does not operate correctly (as I remember anyway). Apparently, more combinations are landing in the "stops the build early" category over time. > The combination of CLANG with LTO > and GNU binutils cannot work - CLANG and GCC use incompatible file > formats to represent the intermediate object files. To my knowledge, a modern gcc+binutils does not work as the basis for a FreeBSD build for powerpc64 or powerpc. No need to have a mixed toolchain involved or -flto involved to have blocking issues. > This version of bc uses advanced algorithms (compared to the one > it replaced) for much reduced time complexity (a factor of more > than 100 for large numbers has been observed). It uses layering > for correctness, e.g. a set of "vector" management functions, that > are built as a separate compile unit. Compiling with -flto lets the > linker replace many function calls with constant parameters with > much more efficient inline instructions, resulting in 30% higher > performance. The code could be re-arranged to use inline functions > instead of relying on -flto, but this would be a lot of effort and > might make the code much harder to maintain. I'm not objecting to -flto use, even if it constrains what can be used as a basis for building and operating FreeBSD. There are issues that well predate -flto use that block other toolchains for powerpc64 and powerpc. If more than llvm-based is to be supported, I'd just suggest modern gcc+binutils, avoiding claiming support for mixes such as llvm+binutils. > If there is a condition that could be added to the Makefile to not > enable LTO if CLANG+binutils or GCC+LLD are mixed, then I'm willing > to add it. If it happened that -flto use vs. not needs to be configurable for other reasons and it happens to end up that turning it off allows the mixes, that would be fine. (But there could be more issues before any mixes would work.) This would not be the same as targeting being sure that some specific mix(es) would work (all issues handled for the mix). > If more programs were to be built with LTO for performance > reasons, then it might be a good idea to have a global parameter that > controls whether lTO may be used, though. Yep. It avoids needing to find and adjust each individually. > TL;DR >=20 > Perhaps we could add a WITH(OUT)_LTO option that only affects specific > programs that get a significant performance boost from building with > LTO. IMHO, using LTO is preferable to the introduction of inline > functions in source files that fall into that category. >=20 > WITHOUT_LTO could be implied on platforms that are known to not fully > support -flto with default their compiler and linker. And it could be > set by the user when non-default build tools are used. I've no clue if there are platforms for which -flto needs to be avoided in general, even without mixed toolchains getting involved. > This would allow to use -flto for specific programs without the need > to make this optimization conditional on compilers or architectures. FYI: I have disabled attempting to build the failing combination in my environment. There are new non-flto issues also causing more examples of disabled build attempts. But I do not expect that anything disabled was able to boot and operate okay for powerpc64 or for powerpc. > Best regards, STefan >=20 >> --- gh-bc.full --- >> /usr/local/powerpc-unknown-freebsd13.0/bin/ld: = /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open = "/usr/bin/../lib/LLVMgold.so" >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >> *** [gh-bc.full] Error code 1 >>=20 >> Yep: /usr/lib/LLVMgold.so when = -B/usr/local/powerpc-unknown-freebsd13.0/bin/ >> was in use. >>=20 >> I turns out that the link of gh-bc used -flto : >>=20 >> make[4]: stopped in /usr/src/usr.bin/gh-bc >> .ERROR_TARGET=3D'gh-bc.full' >> = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc= /usr/src/powerpc.powerpc/usr.bin/gh-bc/gh-bc.full.meta' >> .MAKE.LEVEL=3D'4' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'cc -target powerpc-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src= /powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -O2 = -pipe -fno-common -B/usr/local/powerpc-unknown-freebsd13.0/bin/ = -DMAINEXEC=3Dbc -DNLSPATH=3D/usr/share/nls/%L/%N.cat -DBC_ENABLED = -DBC_ENABLE_PROMPT -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_EXTRA_MATH = -DBC_ENABLE_HISTORY -DBC_ENABLE_RAND -DDC_ENABLED -DNDEBUG = -DVERSION=3D3.1.1 -I/usr/src/contrib/bc/include -DBC_ENABLE_NLS=3D1 = -flto -g -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments = -Wl,--secure-plt -o gh-bc.full args.o data.o file.o lang.o lex.o main.o = num.o parse.o program.o read.o vector.o vm.o bc/bc.o bc/lex.o bc/parse.o = dc/dc.o dc/lex.o dc/parse.o history/history.o bc_help.o dc_help.o lib.o = lib2.o opt.o rand/rand.o ;' >> .CURDIR=3D'/usr/src/usr.bin/gh-bc' >> .MAKE=3D'make' >> = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/= powerpc.powerpc/usr.bin/gh-bc' >> .TARGETS=3D'all' >> = DESTDIR=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/= powerpc.powerpc/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'powerpc' >> MACHINE_ARCH=3D'powerpc' >> MAKEOBJDIRPREFIX=3D'' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20200606' >> = PATH=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/pow= erpc.powerpc/tmp/usr/sbin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.p= owerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/usr/obj/powerpcvtsc_clang_altb= inutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/sbin:/usr/o= bj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/t= mp/legacy/usr/bin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/u= sr/src/powerpc.powerpc/tmp/legacy/bin:/usr/obj/powerpcvtsc_clang_altbinuti= ls/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/libexec::/sbin:/= bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> = OBJTOP=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/p= owerpc.powerpc' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc-clang_altbinutils-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/gh-bc/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/usr.bin/gh-bc/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/usr.bin/gh-bc /usr/src/contrib/bc/src = /usr/src/contrib/bc/gen /usr/src/contrib/bc/manuals = /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.pow= erpc/usr.bin/gh-bc' >> 1 error >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D650A757-F668-4CE5-B652-E2BF347D62FD>