LTO Support on PPC

[acjones8]

Hello! I've been interested in trying to get LTO (Link Time Optimization) working on 10.5, but I'm a little stumped on the process. In particular:

1. Does LTO work on PPC without any extra configuration if GCC's new enough? I currently have GCC 12 installed, and I've tried compiling some software with -flto. It looks at first glance like it works; if I check with ps, I can see lto-wrapper and lto1 getting called during the process, which they aren't during a regular compile. However, when I try to call it with -fuse-linker-plugin , it refuses by telling me that ld (I'm using ld64-127) doesn't have plugin support, so it can't use LTO. This makes sense to me, given that ld64-127 seems to be pretty old, but when I look at ld64's Portfile, I see a note that apparently ld64-127 can't be compiled without LTO support...

As best I understand it, ld64-127 seems to have LTO support of some kind, but it appears too old for GCC 12 to work with or detect; therefore, GCC still generates GIMPLE code because I'm asking it to, but ld64 just throws it out. If I want to actually benefit from LTO, I need to compile a newer version of ld64 from your darwin-xtools repo.

Is this reasoning correct? I apologize for how elementary this question is, I'm just really confused by all the mixed signals.

2. Can I use the copy of GCC 12 I already have from MacPorts, or do I need to use GCC 12 from the repo here? Also, since I already have a C++11 capable compiler, can I skip Stage 0 and start at Stage 1 of the Darwin 9-13 process?

[barracuda156]

On a side note, ld64-127 has problems with PPC, in particular with ppc64. It is advisable to use ld64-97 instead. At least until we can move to @iains version of ld64.

[acjones8]

Yeah, I had issues with getting GCC 12 linked with ld64-127, so I used ld-97 for that step. However, ld-97 has a patch in MacPorts to disable LTO support, and I assumed that if ld-127 doesn't work with GCC 12's LTO, then ld-97 wouldn't either, since it's older. I tested it just to be sure, but it shows the same symptoms as ld-127 - I see lto-wrapper and lto1 getting launched, but I can't use -fuse-linker-plugin with it either.

[iains]

• ld64 does not work with GCC's LTO (any version) - someone needs to implement that one day.
• on PPC/PPC64 you might as well disable LTO until the powerpc-darwin implementation in clang/LLVM is finished/working (since the current code-gen is not ABI compliant).
• ld64-97 has better support for large [PPC*] binaries than any other version published yet, it also correctly supports PPC64 with mdynamic-no-pic (as does ld64-85.2.1) where later versions omit the necessary tests.
• I am testing a version of ld64-236-3 with PPC support restored and a number of fixes (including large binary support for PPC*) ..

[iains]

apropos LTO : well, if you are building cross-tools to i386/x86_64 then of course there could be some reason to enable LTO ... it will still not work for PPC* though.

[acjones8]

Thanks so much! That answers all my questions, I'll switch back to ld64-97 and disable LTO then. I'm nowhere near as talented as you, kencu, or barracuda are, but if you need any help testing ld64-236, I'd be happy to give it a shot!

[barracuda156]

@iains Iain, could you please say if ld64 is supposed to work if it is built for ppc64)? I am trying to build GCC on Leopard for ppc64, and it keeps failing on this:

	  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a  -L/opt/local/lib -lisl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lmpc -lmpfr -lgmp   -lz -L/opt/local/lib -lzstd 
/opt/local/libexec/gcc10-bootstrap/bin/g++ -std=c++11 -no-pie   -g -fPIC -DIN_GCC -fPIC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -L/opt/local/lib -Wl,-headerpad_max_install_names -o cc1plus \
	      cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/contracts.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/mapper-client.o cp/mapper-resolver.o cp/method.o cp/module.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o darwin-c.o rs6000-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcody/libcody.a  \
		libcommon.a ../libcpp/libcpp.a  -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a  -L/opt/local/lib -lisl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lmpc -lmpfr -lgmp   -lz -L/opt/local/lib -lzstd 
ld: bl out of range (-16810336 max is +/-16M) from __ZN10hash_tableI24allocno_hard_regs_hasherLb0E11xcallocatorED1Ev at 0x10100C098 in __text of libbackend.a(ira-color.o) to __Z8ggc_freePv at 0x100004054 in __text of  libbackend.a(ggc-page.o) in __ZN10hash_tableI24allocno_hard_regs_hasherLb0E11xcallocatorED1Ev from libbackend.a(ira-color.o)
ld: bl out of range (-16803216 max is +/-16M) from __ZN10hash_tableI24allocno_hard_regs_hasherLb0E11xcallocatorED1Ev at 0x10100A548 in __text of libbackend.a(ira-color.o) to __Z8ggc_freePv at 0x1000040D4 in __text of  libbackend.a(ggc-page.o) in __ZN10hash_tableI24allocno_hard_regs_hasherLb0E11xcallocatorED1Ev from libbackend.a(ira-color.o)
ld: bl out of range (-16797628 max is +/-16M) from __ZN15odr_name_hasher6removeEP10odr_type_d at 0x10100A164 in __text of libbackend.a(ipa-devirt.o) to __Z8ggc_freePv at 0x100005218 in __text of  libbackend.a(ggc-page.o) in __ZN15odr_name_hasher6removeEP10odr_type_d from libbackend.a(ipa-devirt.o)
ld: bl out of range (-16814716 max is +/-16M) from __Z25native_encode_initializerP9tree_nodePhiiS1_ at 0x10100EBEC in __text of libbackend.a(fold-const.o) to __Z8ggc_freePv at 0x1000060C8 in __text of  libbackend.a(ggc-page.o) in __Z25native_encode_initializerP9tree_nodePhiiS1_ from libbackend.a(fold-const.o)
collect2: error: ld returned 1 exit status
make[3]: *** [lto1] Error 1

I tried numerous options, and regardless of anything keep bumping into this.

P. S. I wanna implement a reproducible procedure to build gcc13 for ppc64 in Macports. I kinda gave up on an idea to build universal binaries, that will require too much to rewrite and fix, but at least having ppc64 working will be great.
Quite some time ago I was able to hack somehow the way through to a working gcc11 build as universal (ppc+ppc64), but as I recall it involved using 32-bit ld64 and cctools first and then rebuilding those again. That was perhaps far from optimal, and no one will be happy to accept such solutions in Macports.
Now we have gcc10 for ppc+ppc64, and then everything is broken.

(For ppc32 everything works beautifully, at least on 10.6 ppc.)

[iains]

It looks like you are hitting the branch islanding bug(s) ... sorry I've not had time to publish the fixed 236.3 version yet - but I do build that 64b on both i686 and powerpc darwin9 (and it works).

[barracuda156]

It looks like you are hitting the branch islanding bug(s) ... sorry I've not had time to publish the fixed 236.3 version yet - but I do build that 64b on both i686 and powerpc darwin9 (and it works).

@iains Got it. Please consider publishing a patch at least – this is not something which I can fix on my own, unfortunately.

BTW, which version of xtools were you using on Leopard prior to updating? I mean, of those publicly available ATM.

[iains]

my old toolchain uses xtools 1.1.0 [ld 253.9] (but that is built as a 32b executable); it does work OK to link ppc64 code, tho and it will link exes that require branch islands.

There is a second issue: linking large C++ projects with debug using the 32 linker (because you can have an exe that is maybe only 120Mb but the .o files including debug can exceed the address space of the 32b process). However, the error messages in your example are related to branching.

[barracuda156]

because you can have an exe that is maybe only 120Mb but the .o files including debug can exceed the address space of the 32b process

I think I have bumped into that with mongodb (on ppc).

BTW, what is the solution in those cases? Just drop flags that trigger debug info being added?