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-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] configure: Improve aarch64 feature detection on older, broken Clang versions
Date: Tue, 31 Oct 2023 12:23:11 +0200 (EET)
Message-ID: <8467358d-cc81-a68e-ea40-33131b920a0@martin.st> (raw)
In-Reply-To: <20231024122258.210941-2-martin@martin.st>

On Tue, 24 Oct 2023, Martin Storsjö wrote:

> Clang versions before 17 (Xcode versions up to and including 15.0)
> had a very annoying bug in its behaviour of the ".arch" directive
> in assembly. If the directive only contained a level, such as
> ".arch armv8.2-a", it did validate the name of the level, but it
> didn't apply the level to what instructions are allowed. The level
> was applied if the directive contained an extra feature enabled,
> such as ".arch armv8.2-a+crc" though. It was also applied on the
> next ".arch_extension" directive.
>
> This bug, combined with the fact that the same versions of Clang
> didn't support the dotprod/i8mm extension names in either
> ".arch <level>+<feature>" or in ".arch_extension", could lead to
> unexepcted build failures.
>
> As the dotprod/i8mm extensions couldn't be enabled dynamically
> via the ".arch_extension" directive, someone building ffmpeg could
> try to enable them by configuring their build with
> --extra-cflags="-march=armv8.6-a".
>
> During configure, we test for support for the i8mm instructions
> like this:
>
>    # Built with -march=armv8.6-a
>    .arch armv8.2-a             # Has no visible effect here
>    #.arch_extension i8mm       # Omitted as the extension name isn't known
>    usdot v0.4s, v0.16b, v0.16b
>    # Successfully assembled as armv8.6-a is the effective level,
>    # and i8mm is enabled implicitly in armv8.6-a.
>
> Thus, we would enable assembling those instructions. However if
> we later check for another extension, such as sve (which those
> versions of Clang actually do support), we can later run into the
> following situation when building actual code:
>
>    # Built with -march=armv8.6-a
>    .arch armv8.2-a             # Has no visible effect here
>    #.arch_extension i8mm       # Omitted as the extension name isn't known
>    .arch_extension sve         # Included as "sve" is as supported extension name
>    # .arch_extension effectively activates the previous .arch directive,
>    # so the effective level is armv8.2-a+sve now.
>    usdot v0.4s, v0.16b, v0.16b
>    # Fails to build the instructions that require i8mm. Despite the
>    # configure check, the unrelated ".arch_extension sve" directive
>    # breaks the functionality of the i8mm feature.
>
> This patch avoids this situation:
> - By adding a dummy feature such as "+crc" on the .arch directive
>  (if supported), we make sure that it does get applied immediately,
>  avoiding it taking effect spuriously at a later unrelated
>  ".arch_extension" directive.
> - By checking for higher arch levels such as armv8.4-a and armv8.6-a,
>  we can assemble the dotprod and i8mm extensions without the user
>  needing to pass -march=armv8.6-a. This allows using the dotprod/i8mm
>  codepaths via runtime detection while keeping the binary runnable
>  on older versions. I.e. this enables the i8mm codepaths on Apple M2
>  machines while built with Xcode's Clang.
>
> TL;DR: Enable the I8MM extensions for Apple M2 without the user needing
> to do a custom configuration; avoid potential build breakage if a user
> does such a custom configuration.
>
> Once Xcode versions that have these issues fixed are prevalent, we
> can consider reverting this change.
> ---
> configure | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)

Will push now.

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

  reply	other threads:[~2023-10-31 10:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24 12:22 [FFmpeg-devel] [PATCH 1/2] aarch64: Simplify the linux runtime cpu detection code Martin Storsjö
2023-10-24 12:22 ` [FFmpeg-devel] [PATCH 2/2] configure: Improve aarch64 feature detection on older, broken Clang versions Martin Storsjö
2023-10-31 10:23   ` Martin Storsjö [this message]
2023-10-24 12:40 ` [FFmpeg-devel] [PATCH 1/2] aarch64: Simplify the linux runtime cpu detection code Sean McGovern
2023-10-26 21:40   ` Sean McGovern
2023-10-26 21:42     ` Sean McGovern
2023-10-31 10:22   ` Martin Storsjö

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=8467358d-cc81-a68e-ea40-33131b920a0@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