Clever Geek Handbook

Does Apple AS assembler replace some NEON instructions with iOS equivalent?

I was trying to use ffmpeg on iOS and debugging a crash in the optimized hand code. I found that some unsigned command (.u16, .u32) was replaced with signed ones (.i16, .i32). It's easy to see because the disassembled GDB instruction doesn't quite match the source code.

For example,

vrshrn.u32 -> vrshrn.i32
vrshrn.u16 -> vrshrn.i16
vadd.u16 -> vadd.i16

My questions:

  • Is this behavior correct and expected? If not, how do we fix it?
  • If they are equivalent, why do we need unsigned ones at all? Is it because the code is more explicit?
  • Is this behavior expected with other platform instrumentation? For example the Android toolkit? (I've heard that Apple AS is ancient).
+3


source to share


3 answers


These instructions are independent of the signature of the elements - it actually means the suffix .Inn

. The assembler still accepts versions of .Snn

or .Unn

, but disassembly will only use .Inn

.



For instructions that distinguish between signed and unsigned integers (for example, VMULL

), the assembler does not accept a suffix .Inn

, only .Snn

or .Unn

.

+4


source


These are the same instructions. The sign does not affect the operation.



$ cat neon.s 
    .text
    .code 32
    .globl _foo
_foo:
    vrshrn.u32 d0, q0, #1
    vrshrn.i32 d0, q0, #1

$ otool -tv neon.o 
neon.o:
(__TEXT,__text) section
_foo:
00000000    f29f0850    vrshrn.i32  d0, q0, #1
00000004    f29f0850    vrshrn.i32  d0, q0, #1
+3


source


In general, you can be sure that assemblers don't do anything crazy, unlike some compilers. When the assembler changes some instructions, it is basically an exact equivalent or pseudo-insturction.

0


source






More articles:


All Articles