Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v5] gcc: Don't disable '-ftree-vectorize' if gcc version higher than 13.
Date: Tue, 5 Aug 2025 16:02:18 +0300 (EEST)
Message-ID: <caa559a0-54eb-baee-97f6-677a383540d6@martin.st> (raw)
In-Reply-To: <CABPLAST9imeq3tY+_t3EzrzTnJK-PV-TXqw08RKgsMn695WPVA@mail.gmail.com>

On Fri, 18 Jul 2025, Kacper Michajlow wrote:

> On Fri, 11 Jul 2025 at 23:41, Michael Niedermayer
> <michael@niedermayer.cc> wrote:
>>
>> Hi Martin
>>
>> On Thu, Jul 10, 2025 at 02:35:10PM +0300, Martin Storsjö wrote:
>> > On Thu, 10 Jul 2025, Jiawei wrote:
>> >
>> > > Hi Martin,
>> > >
>> > > Is there any progress for this patch, should I resend it to the mailing
>> > > list again?
>> >
>> > When I posted the updated version of the patch, the patchwork test runners
>> > noticed that this patch causes test failures on Loongarch. So modern
>> > versions of GCC still do have vectorization bugs, at least on some
>> > architectures.
>> >
>>
>> > 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.

I've tried to gather the consensus about this patch from the discussions 
above, and reposted this patch at 
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20120 - hopefully that 
captures the gist of it.

In short, this allows the GCC default on GCC >= 13, on x86/arm/aarch64.

People actively testing other architectures are welcome to try overriding 
configure on their platform and suggesting other architectures that should 
allow potential vectorization as well - and if other issues are observed 
(and ideally reported) we can add that to the tracking list, so we don't 
end up with this disabled forever.

(Keeping it disabled on all architectures is also making it harder for GCC 
itself to get potential corner case bugs observed and fixed.)

// Martin
_______________________________________________
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".

  parent reply	other threads:[~2025-08-05 13:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250613083704.6858-1-jiawei@iscas.ac.cn>
2025-06-13  8:42 ` Martin Storsjö
2025-06-14 22:49   ` Michael Niedermayer
2025-06-16  7:37     ` Martin Storsjö
     [not found]       ` <a37b238c-c136-4a13-96ba-0bca77fdcb38@iscas.ac.cn>
     [not found]         ` <ec574b73-bf1d-4174-9e8f-617101a5820c@iscas.ac.cn>
2025-07-10 11:35           ` Martin Storsjö
     [not found]             ` <871c0cb0-5433-43db-a57c-aee96bdeae16@iscas.ac.cn>
2025-07-10 12:44               ` Martin Storsjö
2025-07-11 21:41             ` Michael Niedermayer
2025-07-18 15:42               ` Kacper Michajlow
2025-08-02 18:27                 ` Alexander Strasser via ffmpeg-devel
2025-08-05 13:02                 ` Martin Storsjö [this message]
2025-06-17 22:17     ` compn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caa559a0-54eb-baee-97f6-677a383540d6@martin.st \
    --to=martin@martin.st \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git