Design: 提案：WasmのFp IEEEコンプライアンスレベルフラグ（Wasm ScalarおよびSIMDのFP-Fast-Math）

fp操作の厳密さはプログラムのセマンティクスに影響を与えるため、より寛容なセマンティクスを可能にする最善の方法は、カスタムセクションやブロック構造ではなく、新しい命令を導入することだと思います。 NaN伝播ルールにより、浮動小数点の非決定性を処理するために必要な仕様メカニズムはすでに用意されているため、より多くの結果を可能にする新しい浮動小数点命令を導入するのは簡単だと思います。

追加のコンテキストとして、JVMは、その一部として、 strictfpをすることを検討しています。

より寛容なセマンティクスを可能にする最良の方法は、カスタムセクションやブロック構造ではなく、新しい命令を導入することです。

新しい命令を導入することは便利ですが、拡張性が高すぎたり、ツールチェーンの依存関係を完全に削除したりすることはありません。 fma、reciprocalなどの優れたプラットフォームサポートを備えた命令は、新しい命令の追加に適しています。 ネイティブコンパイラが提供するヒント/フラグにはかなりの
-fassociative-math -ffast-math -fno-honor-nans -ffinate-math-only -fdenormal-fp-math -fno-strict-float-cast-overflow -fno-math-errno -fno-trapping-math ...
これらのほとんどは、代数変換、nans、符号付きゼロ、トラップ、丸めなどの制限を解除する、より積極的なfp最適化を可能にするためのヒントです。新しい命令としてすべての有用なフラグを表現することは理想的なimoではありません。

追加のコンテキストとして、JVMは、その一部として、strictfpを削除し、厳密なセマンティクスのみをサポートすることを検討しています。

この追加されたコンテキストを@sunfishcodeに感謝します！ 私はこの新しい更新について知りませんでした、そして動機は数学ライブラリの変形を統合することであるように思われます。 よく見ると、Java strict-fpはもう少し特殊化されているように見え、gcc / clangによって提供されるコントロールポイントの範囲を適切に表してはいません。 -ffast-mathフラグと関連するフラグは、githubのクイック検索からのネイティブリポジトリで非常に人気があるようです。 上記のフラグと関連するpargmasの使用法を調べる予定です

gcc / clangの-ffast-mathを使用する典型的なプロジェクトは、ネイティブコードにコンパイルされています。 それらを使用するアプリケーション開発者は、通常、自分で作成したすべてのネイティブコードバリアントをテストします。 また、一般的なハードウェアISAはすべて完全に決定論的な浮動小数点の動作をしているため、開発者がこれらのバリアントをテストすると、ユーザーの動作が変わらないことをかなり確信で​​きます。 現在、WebAssemblyの浮動小数点もこのように機能します。 これは、ハードウェアISAと同様に完全に決定論的であるため、-ffast-mathを追加して、「それらに対して機能する」ことをテストできるという、長年の開発者の前提が守られています。

WebAssemblyレベルの-ffast-mathフラグは、WebAssemblyがこの点でハードウェアISAに似ておらず、これらの仮定を支持していないことを意味します。 開発者は作成したバイナリをテストしますが、ユーザーにwasmを出荷する場合、ユーザーはさまざまなハードウェアまたはさまざまなエンジンで実行できることを期待する必要があります。 WebAssemblyレベルで高速数学のようなフラグを使用すると、WebAssemblyはISAのように動作せず、ユーザーは開発者がテストしたものとは異なる浮動小数点の結果を見ることができます。

また、これらのフラグを使用するプロジェクトは、今日WebAssemblyにコンパイルするときに見逃すことはありません。 たとえば、-fassociative-mathによって有効になる最適化の多くは、WebAssemblyを作成する前にLLVMが実行できるループ指向の最適化です。

はい、フロートの精度/動作に影響を与える決定は、ツールによってWasmモジュールに組み込まれる必要があります。 現在の命令では表現できない動作に対して、新しい命令を追加できます。

前回のCGミーティングでこのトピックについて話し合い、目標の代替手段として新しい命令を追加しました。 後者の方向でこれを解決することに一般的な関心があるようです。 ツールチェーンの最適化と欠落している命令バリアントの導入によって、パフォーマンスの向上に対する開発者の期待が支持されれば、私は異議を唱えません。 その場合、Wasmの抽象化レベルを損なうランタイムにこれらのフラグを伝播することを正当化する必要はありません。 この目標を達成するために必要なセマンティックバリアント命令を理解することは良いことです。 SIMDのコンテキストで識別されたいくつかの新しい命令があります。これらは、高速演算フラグを完全に表現するために必要な命令ツールと一致するように拡張する必要がある場合があります。 その方向を見続けます。

フィードバックをお寄せいただきありがとうございます。

CGディスカッションに使用されるコンテンツ。 Wasm ffast-math.pptx