[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.

Martin Storsjö martin at martin.st
Wed Jan 13 10:10:04 EET 2021


On Tue, 12 Jan 2021, Reimar Döffinger wrote:

>> On 12 Jan 2021, at 13:24, Josh Dekker <josh at itanimul.li> wrote:
>> 
>> Hi,
>> 
>> AS	libavcodec/aarch64/hevcdsp_idct_neon.o
>> libavcodec/aarch64/hevcdsp_idct_neon.S: Assembler messages:
>> libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S'
>
> Yes, I noticed that a few days ago, I sent the fixed version now. I had 
> only tested on Apple assembler, assuming it would be the same. Really 
> stupid behaviour by the GNU one, as if the type mattered for a mov 
> instruction, needlessly complicates macros.

Yes, this particular restriction is a bit annoying, but there's also a 
number of other cases, with assembly constructs that are accepted by GAS 
but not supported by LLVM/Clang, like "umov w0, v0.4h[0]" (where the 
canonical form, that LLVM supports, is "umov w0, v0.h[0]").

If you just test your code with one tool, there's always a possibility of 
these slipping in, but by testing with more than one tool (either 
proactively by the developer, or by a reviewer, or ultimately by FATE) one 
can pick up on such issues, and in practice, all common tools (GAS, LLVM, 
and armasm64) usually support the canonical spellings of instructions.

(See my other reply about explanations around the fact that armasm64, 
while it uses a different syntax for directives, still can build all of 
our assembly thanks to the gas-preprocessor tool.)

// Martin


More information about the ffmpeg-devel mailing list