1
如何影响Android / ARM目标的Delphi XEx代码生成?
更新2017-05-17。我不再为产生此问题的公司工作,也无法访问Delphi XEx。在我在那里的时候,通过迁移到混合FPC + GCC(Pascal + C)来解决问题,对于某些例程,NEON内在函数有所作为。(强烈建议使用FPC + GCC,因为它可以使用标准工具,尤其是Valgrind。)如果有人可以通过可靠的示例演示他们实际上如何从Delphi XEx生成优化的ARM代码,我很乐意接受答案。 Embarcadero的Delphi编译器使用LLVM后端为Android设备生成本机ARM代码。我有大量Pascal代码,需要将这些代码编译到Android应用程序中,并且我想知道如何使Delphi生成更有效的代码。现在,我什至没有在谈论诸如自动SIMD优化之类的高级功能,而只是在生成合理的代码。当然必须有一种方法可以将参数传递给LLVM端,否则会影响结果?通常,任何编译器都会有很多选择来影响代码的编译和优化,但是Delphi的ARM目标似乎仅仅是“优化开/关”,仅此而已。 LLVM应该能够生成合理的紧致和明智的代码,但是Delphi似乎在以奇怪的方式使用其功能。Delphi希望非常大量地使用堆栈,并且通常只将处理器的寄存器r0-r3用作临时变量。也许最疯狂的是,它似乎正在将正常的32位整数作为四个1字节的加载操作进行加载。如何使Delphi产生更好的ARM代码,而又没有它为Android带来的逐字节麻烦呢? 起初,我认为逐字节加载是为了交换big-endian的字节顺序,但事实并非如此,它实际上只是加载具有4个单字节加载的32位数字。*可能是加载完整的32位,而不会产生未对齐的字大小的存储器负载。(是否应该避免那是另一回事,这暗示整个事情都是编译器错误)* 让我们看一下这个简单的函数: function ReadInteger(APInteger : PInteger) : Integer; begin Result := APInteger^; end; 即使启用了优化,带有更新包1的Delphi XE7以及XE6也会为该功能生成以下ARM汇编代码: Disassembly of section .text._ZN16Uarmcodetestform11ReadIntegerEPi: 00000000 <_ZN16Uarmcodetestform11ReadIntegerEPi>: 0: b580 push {r7, lr} 2: 466f mov r7, sp 4: b083 sub sp, #12 6: 9002 str …
266
android
delphi
android-ndk
arm
llvm