https://web.archive.org/web/20170227190422/http://hilbert-space.de/?p=22
在这个过时的网站上，它表明手写的asm会比内在的更好。我想知道这是不是现在的事实，即使是现在2012年。
使用gnu交叉编译器为内在函数改进了编译优化吗？
答案 0 :(得分：13)
我的经验是内在的并不值得这么麻烦。编译器在内在函数之间注入额外的寄存器卸载/加载步骤太容易了。让它停止这样做的努力比在原始NEON中编写东西更复杂。我在最近的编译器中看到过这种东西（包括clang 3.1）。
在这个级别，我发现你真的需要控制到底发生了什么。如果你做的事情几乎没有错，你就可以拥有各种各样的摊位。在内在函数中进行操作就像戴上焊工手套的手术一样。如果代码对性能至关重要，我根本不需要内在函数，那么内在函数就不够好了。也许其他人在这里有不同的经历。
答案 1 :(得分：9)
我必须在几个项目中使用NEON内在函数来实现可移植性。事实是，GCC没有从NEON内在函数生成良好的代码。这不是使用内在函数的弱点，而是GCC工具的弱点。 Microsoft的ARM编译器从NEON内在函数生成了很好的代码，在这种情况下不需要使用汇编语言。便携性和实用性将决定您应该使用哪些。如果你可以处理编写汇编语言，那么写asm。对于我的个人项目，我更喜欢在ASM中编写时间关键代码，这样我就不必担心错误/劣等编译器会弄乱我的代码。
更新：Apple LLVM编译器介于GCC（最差）和Microsoft（最佳）之间。它在指令交错和最佳寄存器使用方面表现不佳，但至少它会生成合理的代码（在某些情况下与GCC不同）。
Update2： ARMv8的Apple LLVM编译器得到了显着改进。它现在可以很好地从C和内在函数生成ARMv8代码。
答案 2 :(得分：3)
所以这个问题已经有四年了，现在仍然出现在搜索结果中......
2016年情况要好得多。
我从汇编到内在函数转换的很多简单代码现在由编译器优化得比我好，因为我懒得做管道工作（有多少不同）管道现在？），而编译器只需要我传递正确的--mtune=。
对于寄存器分配可能变得紧张的复杂代码，GCC和Clang两者仍然比手写代码慢两倍......或三（ish）。它主要是寄存器泄漏，因此您应该从代码结构中了解这是否存在风险。
但他们有时会发生令人失望的事故。我现在说这是值得冒险的（虽然我付钱承担风险），如果你确实遇到了什么，那么就提出一个bug。这样事情会继续变得更好。
答案 3 :(得分：0)
现在，您甚至可以对普通C代码进行自动向量化，并且正确处理了内部函数： https://godbolt.org/z/AGHupq