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. What i did in soem rare places do, was depend on IEEE 754 semantics (that is when doing so lead to simpler and cleaner code) > 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 > > 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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact