問題タブ [compiler-optimization]

私はかなり奇妙な問題に直面しています。私はビット演算をサポートしないアーキテクチャ用のコンパイラに取り組んでいます。ただし、符号付き16ビット整数演算を処理するため、以下のみを使用してビット単位の演算を実装できるかどうか疑問に思いました。

• 加算（c = a + b）
• 減算（c = a --b ）
• 除算（c = a / b）
• 乗算（c = a * b）
• 係数（c = a％b）
• 最小（c = min（a、b））
• 最大（c = max（a、b））
• 比較（c =（a <b）、c =（a == b）、c =（a <= b）など）
• ジャンプ（goto、for、et.c.）

サポートできるようにしたいビット演算は次のとおりです。

• または（c = a | b）
• そして（c = a＆b）
• Xor（c = a ^ b）
• 左シフト（c = a << b）
• 右シフト（c = a >> b）
• （すべての整数は符号付きなので、これは問題です）
• 符号付きシフト（c = a >>> b）
• 1の補数（a = 〜b ）
• （すでに解決策が見つかりました。以下を参照してください）

通常、問題はその逆です。ビット単位のハックを使用して算術最適化を実現する方法。ただし、この場合はそうではありません。

このアーキテクチャでは書き込み可能なメモリが非常に少ないため、ビット単位の演算が必要です。ビット単位の関数自体は、多くの一時変数を使用するべきではありません。ただし、一定の読み取り専用データと命令メモリは豊富です。ここでの注意点は、ジャンプとブランチは高価ではなく、すべてのデータが簡単にキャッシュされることです。ジャンプのコストは、算術（ロード/ストアを含む）命令の半分のサイクルです。つまり、上記でサポートされているすべての関数は、1回のジャンプの2倍のサイクルのコストがかかります。

役立つかもしれないいくつかの考え：

次のコードで1の補数（ビットを否定）を実行できることがわかりました。

また、2の累乗で除算するときの古いシフトハックを覚えているので、ビット単位のシフトは次のように表すことができます。

残りのビット演算については、私は少し無知です。このアーキテクチャのアーキテクトがビット演算を提供してくれればよかったのにと思います。

また、メモリデータテーブルを使用せずに（シフト操作の場合）2の累乗を計算する高速で簡単な方法があるかどうかも知りたいです。素朴な解決策は、掛け算の分野に飛び込むことです：

またはセット＆ジャンプアプローチ：

ちょっとしたテストプログラム：

結果 ：

VisualStudio2008および2010でテスト済み。

1. 私は他のコンパイラーに取り組み、よく覚えていれば、最初の結果を2番目の結果のようにしました。今、私の記憶は間違っている可能性がありますが、TEST_FLOATはTEST_Cと同じ値を持つべきではありませんか？そうでない場合、なぜですか？
2. TEST_C値はコンパイル時または実行時に解決されますか？私はいつも前者を想定していましたが、それらの結果を見ると、いくつか疑問があります...

x86ベースのコアを使用して32ビットメモリマップドレジスタを操作しています。私のハードウェアは、CPUが32ビット幅の読み取りと書き込みをこのレジスタに生成する場合にのみ正しく動作します。レジスタは32ビットアドレスにアラインされており、バイト粒度でアドレス指定できません。

C（またはC99）コンパイラがすべての場合に完全な32ビット幅の読み取りと書き込みのみを生成することを保証するにはどうすればよいですか？

たとえば、次のような読み取り-変更-書き込み操作を実行すると、次のようになります。

一番下のバイトだけが変更され、8ビット幅の読み取り/書き込みが生成されるという事実についてコンパイラーが賢くなりたくありません。x86での8ビット演算では、マシンコードの密度が高くなることが多いため、不要な最適化が心配です。一般に、最適化を無効にすることはできません。

-----編集-------
興味深く、非常に関連性の高い論文：http ://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf

次のようなコードがあります。

残念ながら、 flag を使用すると、/fp:fast明らかcalc_something(0)==1に間違ったコード パスを使用していることになります。これは、コード内の複数のポイントで異なるパラメーターを使用してメソッドを使用する場合にのみ発生するため、コンパイラ (Microsoft Visual Studio 2008、SP1) からの怪しい最適化が行われていると思います。

また、インターフェースを次のように変更すると、上記の問題はなくなります。

しかし、なぜこれが奇妙な動作を修正するのかわかりません。誰でもこの動作を説明できますか? 何が起こっているのか理解できない場合は、/fp:fastスイッチを削除する必要がありますが、これによりアプリケーションがかなり遅くなります。

C++で最適化されたコードを見ることができますか........(アセンブリではありません)??

__assumeのドキュメントには、「次の例に示すように、__ assumeの最も一般的な使用法は、switchステートメントのデフォルトの場合です。」と記載されています。

• __assumeがより効率的な（または別の）コードにつながる可能性がある他のケースはありますか？
• if / elseの内部にある場合、コンパイラはif条件のためにすでにわかっていることを自動的に「想定」していますか？

上記のいずれかを示す重要な例を見つけることができませんでした-他の誰かが見つけられることを願っています。

Visual Studio C/C++ プロジェクトでは、"プロパティ ページ | C/C++ | 最適化" でコンパイラの最適化設定を簡単に変更できます。たとえば、/O2 や /O3 などのさまざまな最適化レベルや、「フレーム ポインターの省略」などの高度な最適化を提供する場合があります。

ただし、Visual Studio の C# プロジェクトで対応する UI を簡単に見つけることができません。私が見つけることができるのは、最適化をオフにすることだけです。「コードを最適化する」チェックボックスしかありません。

C# ユーザーは、C/C++ のような詳細なコンパイラの最適化を制御できますか? コマンド ラインでコンパイラ オプションを指定する必要がありますか?

バックグラウンド：

何年も前に、Visual Studio (VC++) フラグ '/fp:fast' を使用して特定の計算量の多いライブラリでより高速なコードを生成するコードベースを継承しました。残念ながら、'/fp:fast' は、別のコンパイラ (Borland C++) の下で同じライブラリとわずかに異なる結果を生成しました。まったく同じ結果を出す必要があったので、'/fp:precise' に切り替えました。ただし、現在、uBuntu Linux 10.04 で g++ を使用して同じライブラリをコンパイルしていて、同様の動作が見られます。同様の根本原因があるのではないかと考えています。g++ ビルドの数値結果は、VC++ ビルドの数値結果とは少し異なります。これは私の質問に私をもたらします：

質問：

g++ には、VC++ の 'fp:fast' および 'fp:precise' オプションと同等または類似のパラメーターがありますか? (そしてそれらは何ですか? 'fp:precise' に相当するものを有効にしたいのです。)

詳細情報:

g++ を呼び出す「make」を使用してコンパイルします。私が知る限り (make ファイルは少し不可解で、私が書いたものではありません) g++ 呼び出しに追加される唯一のパラメーターは、「通常の」パラメーター (フォルダーとコンパイルするファイルを含める) と -fPIC (このスイッチが何をするのかよくわかりません。'man' ページには表示されません)。

「man g++」の唯一の関連パラメーターは、最適化オプションをオンにするためのもののようです。(例: -funsafe-math-optimizations)。ただし、何かをオンにしているわけではなく、関連する最適化をオフにしたいだけです。

リリース ビルドとデバッグ ビルドを試しましたが、VC++ ではリリースとデバッグで同じ結果が得られ、g++ ではリリースとデバッグで同じ結果が得られますが、g++ バージョンで VC++ バージョンと同じ結果を得ることができません。

MSVC ++コンパイラがコードを最適化できるか（コード例を含む）、または最適化できないものとその理由を疑問に思っています。

たとえば、私はこのようなものでSSE-intrinsicsを使用しました(varは__m128値です)(これは錐台カリングテスト用でした):

asm-output を見てみると、醜い非常にびくびくしたバージョンにコンパイルされていることがわかりました (そして、CPU がタイトなジャンプを嫌うだけであることはわかっています)。また、SSE4.1 PTEST 命令で最適化できることもわかっています。 、しかし、なぜコンパイラーはそれをしなかったのですか?

どのような最適化も実行できません (今まで)。

これは、組み込みとインライン ASM およびリンクされた ASM 関数を使用することを余儀なくされた今日のテクノロジで、コンパイラがそのようなものを見つけることを意味しますか (私はそうは思いません)。

MSVC++ コンパイラの最適化の詳細については、どこで読むことができますか?

(編集 1): SSE2 スイッチと FP:fast スイッチを使用しました

OpenCV 2.1、VS2008 標準で avi ファイルを 2 日間読み込もうとしていますが、うまくいきません。プログラムコンソールに次のメッセージが常に表示されます。

コンパイラがスタック変数を整列しませんでした。Libavcodec が正しくコンパイルされていないため、非常に遅くなったり、クラッシュしたりする可能性があります。これは libavcodec のバグではなく、コンパイラのバグです。gcc >= 4.2 を使用して再コンパイルしてみてください。FFmpeg 開発者にクラッシュを報告しないでください。

..そして、フレームレートは0.5fpsの再生だけです。さまざまな AVI および MPEG ファイルで試しましたが、結果は同じでした。また、ウェブカメラを使用した例は非常に遅いです。OpenCV 1.1 を使っていたときはそのような問題はありませんでした

この問題を解決するためにすでに試したこと：

• ライブラリ全体を再コンパイルしました
• SVN からライブラリを更新し、再コンパイル
• libavcodec.a ファイルのさまざまなバージョンを試しました

ファイルを読み取るために使用しているコードは次のようになります。

誰でも私を助けることができますか？これは私を夢中にさせています:(