Le 20 janvier 2026 15:34:57 GMT+02:00, "Martin Storsjö" <[email protected]> a écrit : >On Tue, 20 Jan 2026, Rémi Denis-Courmont via ffmpeg-devel wrote: > >> Do you have a plan to address the outstanding shortcomings? What would the >> actual performance look like in such case, seen as it would disable most or >> all of the assembler optimisations? > >It is possible to use the current aarch64 assembler as such - even though it >does violate the arm64ec ABI.
In other words, "it works except when it doesn't." You can also mess with X18, TPIDR or SP in a leaf function, as long as you restore them before return. Tests will pass (and even checkasm won't notice). It seems ridiculous that a few GPRs and half the vectors are forbidden, but there are interoperability reasons for this. Windows is riddled with all sorts of weird code doing weird things even to other apps. If it were about calling to/from x86, only the callee-saved GPRs would be justifiably reserved by the ABI. Given enough users, someone will find a way to unwittingly expose the bug at their expense. The argument was that those 3 apps are hugely popular to begin with: you cannot have the cake and eat it. _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
