ffmpeg-3.4.2 can compile with graphite and lto enabled

[emptyparcel]

My USE flags are very stripped down, encoding and all the other jazz is disabled, so I could imagine results might differ on a more complete ffmpeg, but nonetheless it's worth noting.
These are my USE flags: X, alsa, aes, mmx, mmxext, sse ,sse2 ,sse3, sse4_1, sse4_2, ssse3, gpl, hardcoded-tables, iconv, libass, libdrm, mp3, network, opengl, sdl, threads, truetype, vaapi, vorbis, xcb, xvid, zlib.
I used the cflags from your make.conf plus -ffast-math. There is a minor but nonetheless real improvement from enabling graphite and lto here. A particularly intense 3 minute segment of video which consistently dropped around 160 frames in MPV prior to recompiling with lto and graphite now only drops 140. If there are indeed issues with compiling a full ffmpeg with grapite and lto, they obviously should be disabled by default. But it might be worth commenting in that it can work with them, as it can be a noticable improvement for people with trash hardware like me.

[InBetweenNames]

Indeed, at least one other user has been able to do this as well. I'm waiting on a GCC 8 release before I investigate further.

[Hello71]

I got https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728 with ffmpeg-4. supposed to be fixed in gcc 8 though

[InBetweenNames]

Managed to get it built with Graphite, but without LTO using GCC 8.1.0. I'll update the workaround accordingly, but keep the issue open.

[InBetweenNames]

GCC 8.2.0 and still can't build with LTO here. Can still build with Graphite however.

[Hello71]

for me it compiles fine and then promptly crashes on loading anything: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132. looks to be fixed in ffmpeg-9999 though

[pchome]

@Hello71
Do you really able to build 9999 w/ LTO enabled and confirm crashes are gone?

In #85132 they blame --enable-hardcoded-tables ffmpeg option, but I can't find any changes in mentioned code. Last commit (and probably one that brakes LTO): https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/sinewin_tablegen.h (this)

Meanwhile, I can confirm USE="-hardcoded-tables" resolves crashing problem for me.

=media-video/ffmpeg-3.4.4
=sys-devel/gcc-8.2.0-r3

LTO and Graphite enabled (default)

FFmpeg flags:
USE="X alsa bzip2 encode gpl iconv jack ladspa mp3 network nvenc openal opencl opengl openssl postproc pulseaudio sdl svg threads truetype vdpau vorbis x264 xcb xvid zlib"
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"
FFTOOLS="aviocat cws2fws ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart sidxindex trasher"

[Hello71]

Ah, my mistake, I accidentally also uncommented the ltoworkarounds line, so it actually compiled without LTO. It in fact still crashes with 9999 if LTO is properly enabled.

[InBetweenNames]

I just tried to build with USE="-hardcoded-tables" using LTO, no luck

[pchome]

#47 ?
+ https://github.com/InBetweenNames/gentooLTO/blob/master/sys-config/ltoize/files/package.cflags/ltoworkarounds.conf#L143

NOTE: Depending on your CPUFLAGS this may work with LTO. The SSE intrinsics seem to cause problems in some cases.

Your comments.

[InBetweenNames]

Indeed, I was just testing to see if anything had changed since then. So far, still in the same spot.

[pchome]

Then possible solution is to drop problematic flags (-cpu_flags_x86_sse4 ?) and set LTO + -hardcoded-tables by default.

[InBetweenNames]

Yeah, that is one way -- foregoing the explicit SSE code for the implicit version offered by the compiler via vectorization. I'd want to benchmark both before dropping the SSE4 flag. It may be that the implicit SSE is equivalent or better when combined with LTO (+O3, Graphite, and now -fipa-pta).

[Althorion]

Do you have any reasons to suspect that compiler-generated code with LTO will be faster than hand-made?

[InBetweenNames]

No reason to believe one way or the other! Just suggesting a possibility :) Vectorization has improved a ton in recent releases of GCC and Clang.

[Hello71]

aac crash fixed upstream https://trac.ffmpeg.org/ticket/7491

[pchome]

@Hello71
Thanks for taking this in your hands.

I can confirm: adding this patch (minus version.h part) to user patches, and re-enabling USE=hardcoded-tables -- fixes crashes for me.

$LTO, $GRAPHITE and $IPA are enabled.
media-video/ffmpeg-3.4.4

[Hello71]

note that upstream also suggests to turn off hardcoded-tables: https://bugs.gentoo.org/668636

[pchome]

BTW, can't build with LTO and abi_x86_32.

Previously I used only abi_x86_64, but now 32bit version triggered by ffmpeg flag in app-emulation/wine and app-emulation/faudio.

Sadly there is no simple method to change *FLAGS for specific ABI.
Currently using hack (filtered flags remains filtered for the rest ABIs, so restoring):

--- a/ffmpeg-4.1.3.ebuild
+++ b/ffmpeg-4.1.3.ebuild
@@ -401,6 +401,7 @@
                break
        done
 
+       [[ ${ABI} == x86 ]] && filter-flags "-flto*" || append-flags "-flto"
        # LTO support, bug #566282
        is-flagq "-flto*" && myconf+=( "--enable-lto" )