Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.

["Rémi Denis-Courmont" <remi@remlab.net>]

Le 26 mai 2025 00:37:08 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :
>Hi Rémi
>
>On Sat, May 24, 2025 at 07:10:57PM +0300, Rémi Denis-Courmont wrote:
>> Le torstaina 22. toukokuuta 2025, 9.32.18 Itä-Euroopan kesäaika Jiawei a écrit 
>> :
>> > > The RISC-V autovectorised output looks like it has a warning "Odd
>> > > rotation angle" which is not present in the non-autovectorised output.
>> > 
>> > I found this occured when using '-ffast-math' in RISC-V, also occur in
>> > -O3 -ffast-math -fno-tree-vectorize case(much slower due to the
>> > -ffast-math)，supplementary more comparison results here:
>> 
>
>> Unfortunately, the FFmpeg code is written with x87 semantics in mind.
>
>I dont remember ever writing code intentionally with x87 semantics. And i
>have doubts other people did.

It doesn't have to be intentional. FFmpeg was started and mostly developed with x86-32 then x86-64 in mind. It's entirely possible that this happened innocently.

Specifically, FFmpeg uses open-code for minimum, maximum, absolute value and so on (see FFMIN, FFMAX, FFABS). They work nicely for integer maths. They also work nicely on x87 with the current set of FPU optimisations, but they differ from IEEE semantics because of NaNs, negative zeros and such.

Because of that the compiler will *not* use the native FPU instructions on platforms with native IEEE floats.

>> For
>> instance, the FFmpeg math macros work nicely on x86, but they would work much 
>> better with fabs/fmax/fmin/fabsf/fmaxf/fminf on other platforms. I tried to fix 
>> that with copious amount of _Generic(), but that lead to ICE...
>
>ICE as the name says, is a internal compiler error and not the fault of
>the code passed to the compiler

Obviously yes. But if it crashes every major recent versions of both major compilers, then it is a given that the code will be rejected.

And even if the compilers got fixed, the code wouldn't be accepted until ten or twenty years in the future judging by how conservative this project is with compiler versions. Lastly, I suspect it's caused ny excessively complex evaluation that simply drive compilers into OOM. It is debatable if OOM is even a compiler bug.

>> So we are stuck between a rock and a hard place where we need fast math for 
>> good perfs, but we need to turn it off for correct results.
>
>--ffast-math is not one option, its many

Indeed only a few of these flags are troublesome. I mentioned it on IRC many moons ago.

>
>on the gcc here, it does this:
>+  -fassociative-math          		[enabled]
>+  -fcx-limited-range          		[enabled]
>+  -ffinite-math-only          		[enabled]
>+  -fmath-errno                		[disabled]
>+  -freciprocal-math           		[enabled]
>+  -fsigned-zeros              		[disabled]
>+  -ftrapping-math             		[disabled]
>+  -funsafe-math-optimizations 		[enabled]
>
>So maybe some of this can be globally enabled.




>
>But some things like fassociative-math are simply not "safe"
>on general nummeric code. It also violates ISO C according to
>the official gcc documentation
>
>thx
>
>[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".