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".

Reply via email to