On 2025-07-18 17:42 +0200, Kacper Michajlow wrote: > On Fri, 11 Jul 2025 at 23:41, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Thu, Jul 10, 2025 at 02:35:10PM +0300, Martin Storsjö wrote: [...] > > > > > I'm unsure if we should allow it everywhere, and just single out loongarch > > > as a case where it is known broken, or if we should only let GCC enable it > > > on the major architectures that we've tested. > > > > I think for architectures where there is an active maintainer, > > that maintainer should decide. > > > > For architectures where there is noone looking after them, its > > safer to leave it disabled. Otherwsie users could be having > > complex to debug issues to deal with and noone in ffmpeg able to > > replicate > > I agree. In a perfect world we would enable it everywhere, but if > there is a worry that GCC is not a mature enough compiler to enable > it, it's better to gradually roll it out on an opt-in basis. We can > start with major architectures and for other architectures allow > maintainers to decide. > > Alternatively enable it everywhere for start and selectively disable > it, once issues are identified. This may cause breakage, but is easy > to workaround (by adding a compiler flag), and will likely identify > issues with GCC faster. > > Bottom line is that adding `-fno-tree-vectorize` in current year is > quite a heavy hammer to avoid possible issues and especially on major > architectures like x86 it should be safe to enable vectorization. It > also currently gives clang and advantage over gcc if we compare pure c > code in some cases.
Do we have concrete numbers how much better it is? I mean pure C versions of FFmpeg were never really recommended. Would also need the numbers per architecture. Otherwise I would argue people that care about it because they don't have Assembly implementations for their target or use more C code because of other reasons should just enable vectorization as well if they think it works for them. Anyway I see no problem to enable compiler vectorization for compilers and architectures where it works correctly and active maintainers agree on it. And act, should it ever break again. Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
