LTO: We are almost there

[costel78]

Today, with gentoo-sources-4.8.4 and lto patch kernel completely freeze, no crash dump, no error message, it not react on SysReq key, nothing.

[NTU]

Sounds like a fun problem for me to fix! I'll do some more testing, don't worry. I've got a serial port and everything I need to get to the bottom of it, kernel development is so much fun, definitely my favorite area. I'll be helping out the KSPP project as well, security and performance is what I'm shooting for. If people are interested in LTO support for the Linux kernel, then why not go for it. I had no idea that this thread would be as popular as it is, let alone people being crazy enough to try it.

https://gcc.gnu.org/gcc-6/changes.html ->

[costel78]

It would be a fun problem to me to fix, too, only if I have had your experience . Count on me to do the testing, if necessary.
What can I say more ? Likewise, a real pleasure to talk and learn from you. Right now I am not sure what I love more at Gentoo: opportunity to learn, speed or the community.

Thank you for your work! It is really appreciate.

All the best!
_________________
Sorry for my English. I'm still learning this language.

[NTU]

Well this isn't good, I never ran into problems with the kernel starting as early as jump_label.c, I can't even get it to boot on my system.

[costel78]

Plenty of errors, indeed. At least you manage to see them.
I can think only at two future hopes:
1. Last time when saw so many pointer null references was when migrated to gcc-6.2.0 and -fno-delete-null-pointer-checks became mandatory. But as I recall you are on gcc-5.4.0 and the kernel code can not be so buggy to require -fno-delete-null-pointer-checks;
2. Maybe, link posted by charles17 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=84d69848c97faab0c25aa2667b273404d2e2a64a will bring some improvements with kernel-4.9.
Is there any info why original author, Andi Kleen, stopped maintain the patch ? Was he discouraged by Linus Torvalds patch rejection or there was something else ?

Anyway, bright side, LTO and graphite are mature enough to be deployed system-wide. I haven't any glitch or error with them (except annoyance with those in package.env). I believe that, alone, is a step forward.
Kernel, I believe, we have to wait and hope. If "malamutes" projects as libreoffice, firefox, thunderbird, mesa, even no so big, but older code as x11 xorg etc managed to be lto ready, is just a matter of time for kernel.

As always, congratulations for you efforts! Cheer up!
_________________
Sorry for my English. I'm still learning this language.

[altblitz]

[costel78]

about:buildconfig
Build platform
target
x86_64-pc-linux-gnu
Build tools
Compiler Version Compiler flags
/usr/bin/x86_64-pc-linux-gnu-gcc -std=gnu99 6.2.0 -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -pipe -march=native -mtune=btver2 -w -flto=4 -fuse-linker-plugin -fno-fat-lto-objects -fgraphite-identity -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing -fno-math-errno -pthread -pipe
/usr/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11 6.2.0 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wc++14-compat -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -pipe -march=native -mtune=btver2 -w -flto=4 -fuse-linker-plugin -fno-fat-lto-objects -fgraphite-identity -floop-interchange -floop-strip-mine -floop-block -fno-delete-null-pointer-checks -flifetime-dse=1 -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer
Configure options

--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-application=browser PKG_CONFIG=x86_64-pc-linux-gnu-pkg-config --enable-default-toolkit=cairo-gtk3 --disable-tests CC=x86_64-pc-linux-gnu-gcc CXX=x86_64-pc-linux-gnu-g++ HOST_CC=x86_64-pc-linux-gnu-gcc HOST_CXX=x86_64-pc-linux-gnu-g++ MOZ_JEMALLOC4=1 --enable-replace-malloc XARGS=/usr/bin/xargs --enable-system-hunspell --disable-crashreporter --enable-dbus --disable-debug --disable-debug-symbols --enable-extensions=default --disable-gconf --enable-gio --disable-gnomeui --disable-gold --disable-install-strip --enable-ion --disable-necko-wifi --enable-official-branding --enable-optimize=-O2 --enable-pulseaudio --enable-skia --enable-startup-notification --disable-strip --disable-system-cairo --enable-system-ffi --enable-system-sqlite --disable-updater --libdir=/usr/lib64 --prefix=/usr --with-default-mozilla-five-home=/usr/lib64/firefox --with-google-api-keyfile=/var/tmp/portage/www-client/firefox-49.0/work/firefox-49.0/google-api-key --with-intl-api --with-nspr-prefix=/usr --with-nss-prefix=/usr --with-system-bz2 --with-system-graphite2 --with-system-harfbuzz --with-system-icu --with-system-jpeg --with-system-libvpx --with-system-nspr --with-system-nss --with-system-png --with-system-zlib --x-includes=/usr/include --x-libraries=/usr/lib64

[altblitz]

[NTU]

costel78 thanks for the commit! Wouldn't hurt to give it another pass, will try with GCC trunk as well if it's still buggy.

As far as seeing the output, earlyprintk is your friend.

[costel78]

@altblitz In my experience, lto and hardened did not play well together on gcc-4.8.0 days. I do not know nothing regarding status this days.
Also, globally enabled O3 break things, for example, right now it breaks openssh (you can not disconnect cleanly), some parts of libreoffice, at least on my setup.
Will try with -D_FORTIFY_SOURCE=2 -fstack-protector-strong (but I am not on hardened profile) later today and report back.

NTU. It is set:

[costel78]

@altblitz
If firefox fail to build on hardened, -D_FORTIFY_SOURCE=2 -fstack-protector-strong are not the root cause.

[altblitz]

[roarinelk]

[costel78]

Let's hope things will be better with gcc-7.
Anyway, at this stage, it is more likely to be package fault, rather than gcc.
_________________
Sorry for my English. I'm still learning this language.

[CaptainBlood]

I'm sure I have more to add that doesn't support lto but since I stuck to 4.9.4, I'm not sure someone is interested.

Just ask if you please for current list of 74 packages.

Thks 4 ur attention.

[NTU]

Well to rule out GCC being too old I've spent the past short while working on a bleeding edge native toolchain builder:

https://github.com/NTULINUX/toolchain_builder

I'll try out an LTO kernel build using that when I get around to it, feel free to muck around with it in the mean time!

[costel78]

Wow, you did a lot of work!
But I have to admit a failed to get the big picture. You want to try to compile the kernel (with lto) using git-versions of toolchains. How is this different than a -9999 ebuild ? Are you expecting some performance gain doing a stage two ? Also, are you planing to introduce something like gcc-config to be able to use that separate toolchain like the gentoo one, or switching them ?
Yes, I know, a lot of questions. Can you please give more details ?
_________________
Sorry for my English. I'm still learning this language.

[NTU]

The idea is to create a development toolchain that doesn't touch the host system, and crosstool-ng has yet to support a native build, so I wrote my own builder in bash. Installing a -9999 ebuild requires root permissions and changes to root fs, mine doesn't As for gcc-config, probably not as specifying the PATH variable works well (tested a kernel build with it, all was fine.)

I'll write a chroot builder as well that uses that toolchain to build the necessities for a bare minimum chroot, then have it build a complete system from there, inside a home directory for example. It's really just a playground is all, plus you can easily change branches of which one you want to be on and some extra fine tweaking. The toolchain eclasses do this for you, my builder leaves it up to the user. I already have a few hundred lines of the chroot builder written, that way people can test out developer features of compilers or whatever it may be without messing with their main system, it's also all Linux distribution independent

[altblitz]

Blitz did it. Yet again.
Firefox 50.1 with -O3 LTO PGO march=native
and Chromium LTO PGO.

From the benchmarks, Firefox is only ~20% lower than Chromium.

All in all - Blitz have the most speedy browser on the Earth now.
Privacy and security patches applied.

[NTU]

Might be even quicker with a toolchain using all the latest git sources

[costel78]

@altblitz I was unable to compile chromium with lto. Which version ? Can you share the procedure, the patches ?
@NTU Found, on the hard way, that newest isn't always the best. Tried to recompile everything with git sources and I got enough segmentation faults to give up.
Well, of course, I should pick a "lucky day" to grab all those git sources, which it seems I failed miserably.
Any progress on lto kernel ?

Later: At a closer look chromium error is similar with firefox one a while back: lto partitioning on asm code, both encountered on sandbox code. But I am still interested on those security and privacy patches. Thank you!
_________________
Sorry for my English. I'm still learning this language.

[NTU]

You had problems with the toolchain script I posted? Also Gentoo doesn't have a 9999 ebuild for GCC, another reason why I wrote that

[costel78]

No, no with the script itself, but with stability of the system, of the generated binaries.
I'll give another try in the next days.
_________________
Sorry for my English. I'm still learning this language.

[NTU]

Run git pull on the builder before giving it another go, just updated a few things.

[costel78]

I have free time until 3rd of January.
One small sugestion regarding build script: why not make profiledbootstrap -j${CORES} or even make autoprofiledback, perf and autofdo are needed in the last case, see: https://gcc.gnu.org/install/build.html - Building with profile feedback
It is very unlikely that someone using your script are still using x86, or if architecture is x86 go with the simple make to satisfy both cases.
I always build gcc with GCC_MAKE_TARGET="profiledbootstrap", via package.env and autofdo would be really something .

Later:
nice -n 19 when call make it would be... well, nice.
I can confirm that make profiledbootstrap it's working. AutoFDO is next.
_________________
Sorry for my English. I'm still learning this language.