[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