On Tue, 12 Jan 2021, Reimar Döffinger wrote:
On 12 Jan 2021, at 13:24, Josh Dekker <j...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
