LTO'ing Mesa Is Getting Discussed For Performance & Binary Size Reasons

[My8th]

Would this noticeably improve performance per watt?

[haagch]

With linker plugin, -ffat-lto-objects should no longer be needed. It only makes GCC to proudce assembly at compile time that doubles compile times. It is also possible that during linking the plugin is not used (because build machinery bypasses gcc-ar or gcc or gcc-nm somehow and calls binutils directly) and then the LTO is silently discarded and you won't see any LTO options. So try to get your build working without -ffat-lto-objects.

-flto-odr-type-merging is the default, so no need to specify it.

Thanks for all the info. I have already switched to fireburn's flags though: https://www.phoronix.com/forums/foru...333#post875333

I did not have to set AR, NM and RANLIB though, it just works like that. Not sure if it is using gcc-ar etc. I'll try setting the variables and see whether anything changes for the next build.

[discordian]

@atomsymbol: Thanks for the sample, I am actually quite shocked that relative jumps arent used (independent of PIC or not). On ARM the code is quite similar whether PIC or not is used (PIC has branch trampolines, non-PIC a jumptable). Been working on non-linux, non-intel for a long time

GCC 6+ uses linker plugin to drop -fPIC at linktime when the resulting binary is not PIC. -fPIC limits optimizations compiler can do (because with PIC you can dynamically interpose symbols) and thus it needs to be know when the code is being optimized. not sure you would move away from specifying it explicitly to compiler/linker.

Thats an ELF requirement, however it should only apply to visible symbols, LTO should help hiding anything thats not externally visible. But after the example above it seems there is alot unused potential (to put this optimistic, I can also label this as clear WTF)

[FireBurn]

Works. I applied the mentioned patch and used your flags. No Problems at all. Thx

Which patch? The one from the bug? I don't think it's necessary - or rather I'm not using it

[hubicka]

In my opinion, we should slowly be moving to a world where -fPIC passed to a compiler is ignored as a command-line option because the compiler (and the "system" behind) will automatically decide when to use position-independent code.

As far as I know we aren't moving to such a world at all, which is unfortunate.

GCC 6+ uses linker plugin to drop -fPIC at linktime when the resulting binary is not PIC. -fPIC limits optimizations compiler can do (because with PIC you can dynamically interpose symbols) and thus it needs to be know when the code is being optimized. not sure you would move away from specifying it explicitly to compiler/linker.

[hubicka]

Anyone used pgo for big programs ? According to gcc doc it is easy for a few files. But is there any way to use PGO for MESA ?

It is used byt Firefox and google, so yes, there are big programs compiled with PGO.

[hubicka]

I also learned about other flags from https://lists.freedesktop.org/archiv...ay/118929.html so I'm now compiling with

export CFLAGS="$CFLAGS -O3 -flto=9 -ffat-lto-objects -flto-odr-type-merging"
export CXXFLAGS="$CFLAGS"
export LDFLAGS=" -flto=9"

With linker plugin, -ffat-lto-objects should no longer be needed. It only makes GCC to proudce assembly at compile time that doubles compile times. It is also possible that during linking the plugin is not used (because build machinery bypasses gcc-ar or gcc or gcc-nm somehow and calls binutils directly) and then the LTO is silently discarded and you won't see any LTO options. So try to get your build working without -ffat-lto-objects.

-flto-odr-type-merging is the default, so no need to specify it.

[hubicka]

I have tried compiling mesa with lto recently and didn't have any problems - except compilation takes a lot longer. And the worst of it is that for incremental builds, it takes that long every time it links mesa. Is there something gcc can do to cache lto optimizations? Or does it already do that and it's just a high chance that any of the stuff linked together has changed so it needs to relink everything?

With -flto=<num of jobs> the LTO times improve. If you have more than 32 threads, you need to bump up --param max-lto-partitions

Keeping track of functions which does not change since last optimization is technically possible with GCC'S WHOPR - IPA optimizations are performed without modifying the gimple bodies and theoretically all one needs is to check if the bodies are the same and the IPA optimization decisions match. It needs to be implemented though.

[CochainComplex]

Also interessting in this context and as mentioned in the given dev correspondence : https://download.clearlinux.org/rele.../source/SRPMS/ <- extracting the used flags out of the clear linux source packages.

[CochainComplex]

Let me know if you need to contents of the env.d conf files too

Works. I applied the mentioned patch and used your flags. No Problems at all. Thx