[FFmpeg-devel] Re: [DISCUSSION] Adding ARM64EC support to FFmpeg

["Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>]

On Sat, 27 Sep 2025, Rémi Denis-Courmont via ffmpeg-devel wrote:

> But this will constrain the assembler is aggravating. It probably requires
> major changes already, but even if it doesn't, I don't think we should
> constrain future assembler code nor expect developers to support the JIT-
> friendly ABI.

This is indeed a core concern of mine as well.

I don't mind adding build system tweaks to make it possible to build, but 
having to modify all the assembly to make it properly compatible with 
arm64ec isn't really feasible or maintainable.

Given the information in your other mails, it sounds like you don't make 
any modifications to the aarch64 assembly at all - so it uses all the 
aarch64 registers, including the ones that are disallowed to use in 
arm64ec mode.

If building with MSVC with the suggested configuration, building produces 
a very large number of warnings of this kind:

Z:\home\martin\code\ffmpeg-msvc-arm64ec\libavutil\aarch64\float_dsp_neon.o.asm(1056) 
: warning A4253: this instruction uses forbidden registers
         fmul            v16.4s, v0.4s,  v4.4s

The same also is produced if building with Clang:

src/libavutil/aarch64/float_dsp_neon.S:32:9: warning: register Q16 is 
disallowed on ARM64EC.
         fmul v16.4s, v0.4s, v4.4s
         ^

I've tried to talk to acquaintances to figure out exactly what one can 
expect to work and what one can't expect to work, if using assembly 
routines with all registers in arm64ec mode.

First off, calling a C function, which turns out to be in x86_64 mode, 
will clobber those registers. But for assembly which only works as leaf 
functions, that don't call C functions (and those C functions are internal 
in ffmpeg, which also are in arm64ec mode, not x86_64), this shouldn't be 
happening.

Secondly, unwinding through such functions won't work correctly either. 
But we never provide any unwind info for assembly functions, and don't 
expect to unwind through them anyway, so that's probably not an issue 
either.

Inspecting (and possibly single-stepping through) such code in a debugger 
could break.

One case which really can break though, is if some other process suspends 
and resumes the thread - as a form of manual scheduling. This sounds 
exotic, but I'm told these things do exist.

All in all, it sounds to me like these things actually can work, at least 
with some amount of caveats. In that case, it sounds acceptable to add 
build system tweaks to make it buildable, as long as the assembly itself 
doesn't need compromises for this mode.

I tested a checkasm.exe built in this mode, both with MSVC and with Clang, 
and it seems to run fine in a single-shot test at least.

// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org