我正在尝试使用MSFA（googles music synth），它有四个用于DSP操作的 neon 汇编源文件，显然是为32位架构编写的。我最初被告知最好将其重写为NEON intrinsics，这样它将是架构不可知的。然而，在阅读了一些文章后，（例如http://hilbert-space.de/?p=22），但将其作为纯手工编写的程序集似乎仍然是理想的。
我的问题是，将其转换为64位是否微不足道？如果是，我将如何开始做这件事？
.s文件包括：
https://github.com/google/music-synthesizer-for-android/blob/master/cpp/src/neon_fir.s
https://github.com/google/music-synthesizer-for-android/blob/master/cpp/src/neon_fm_kernel.s
https://github.com/google/music-synthesizer-for-android/blob/master/cpp/src/neon_iir.s
https://github.com/google/music-synthesizer-for-android/blob/master/cpp/src/neon_ladder.s
1条答案
按热度按时间tvmytwxo1#
TL;DR：使用内部函数
检查asm输出以确保它不是哑的，这不是一个坏主意，但是使用内部函数可以让编译器进行常量传播，并为按顺序的内核调度/软件流水线。
如果您阅读that post from 2009 you linked上的注解线程，您会发现 neon 内部函数中的错误代码是gcc bug fixed in 2011。
现在编译器在处理内部函数方面做得很好，而且还在不断改进。尤其是Clang可以做很多事情，比如使用与内部函数不同的shuffle指令。
至少它们是针对x86的;面向ARM的编译器有时仍会与内部函数做斗争，尤其是在试图访问16字节向量的两个8字节部分时，就像您经常希望在32位ARM代码中进行水平操作一样。参见 * ARM NEON intrinsics convert D (64-bit) register to low half of Q (128-bit) register, leaving upper half undefined * / * NEON intrinsic for sum of two subparts of a Q register * - Jake Lee报告说，就在2018年，一些clang版本把它弄得一团糟，但GCC6.x没有那么糟糕。
对于AArch 64，这可能不是什么大问题。
ASM级差异：
我不是这方面的Maven，但 neon 的主要变化之一是Aarch 64有32个128 b NEON寄存器（
v0 - v31），而不是每个q寄存器都混叠成两个d。另请参阅official ARM documentation中有关element-size的语法，其中可以使用
.16B来表示16字节元素的向量。（与旧语法相反，.8表示每个元素为8位。）