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コードを生成します。Androidアプリケーションにコンパイルする必要があるPascalコードが大量にあり、Delphiでより効率的なコードを生成する方法を知りたいです。現在、私は自動SIMD最適化のような高度な機能についてさえ話していません。合理的なコードを生成することについてだけです。確かに、パラメーターをLLVM側に渡す方法、または何らかの方法で結果に影響を与える方法が必要ですか？通常、どのコンパイラにもコードのコンパイルと最適化に影響を与える多くのオプションがありますが、DelphiのARMターゲットは単に「最適化のオン/オフ」であり、それだけです。 LLVMは適度にタイトで実用的なコードを生成できるはずですが、Delphiはその機能を奇妙な方法で使用しているようです。Delphiはスタックを非常に多用したいと考えており、通常、プロセッサのレジスタr0〜r3を一時変数としてのみ使用します。おそらく最もクレイジーなのは、通常の32ビット整数を4つの1バイトのロード操作としてロードすることです。Delphiがより優れたARMコードを生成するようにするにはどうすればよいですか？ 最初は、バイトごとの読み込みはビッグエンディアンからバイト順を交換するためのものだと思っていましたが、そうではありません。実際には、32ビットの数値を4つのシングルバイトの読み込みで読み込むだけです。*アライメントされていないワードサイズのメモリロードを行わずに、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