指名

P-highで受け入れられ、＃10183と同じ理由

これは言語レベルで後方互換性がないと思います。 正常に機能していたコードが機能を停止することはありません。 指名。

P-highに変更、＃10183と同じ理由

これと＃10185をどのように解決することを提案しますか？ 動作が定義されているかどうかは、キャストされる数値の動的な値に依存するため、唯一の解決策は動的チェックを挿入することであるように思われます。 算術オーバーフローではこれを実行したくないことに同意しているようですが、キャストオーバーフローでは実行できますか？

「安全な変換」を実行する組み込み関数をLLVMに追加できます。 @zwarichは他のアイデアを持っているかもしれません。

現時点での唯一の解決策は、ターゲット固有の組み込み関数を使用することです。 少なくとも私が尋ねた誰かによると、それはJavaScriptCoreが行うことです。

ああ、それなら簡単です。

ping @pnkfelixこれは新しいオーバーフローチェックのものでカバーされていますか？

これらのキャストは、デバッグアサーションを使用したrustcによってチェックされません。

私はこれを喜んで処理しますが、具体的な解決策が必要です。 個人的には、非常によく似た問題なので、オーバーフローした整数演算と一緒にチェックする必要があると思います。 私は私たちが何をするかは本当に気にしません。

この問題は、特定の定数式で使用された場合、現在ICEを引き起こしていることに注意してください。

これにより、安全な錆でメモリの安全性を侵害することができます。このフォーラムの投稿の例：

Undefs、ハァッ？ Undefは楽しいです。 それらは伝播する傾向があります。 数分のラングリングの後..

#[inline(never)]
pub fn f(ary: &[u8; 5]) -> &[u8] {
    let idx = 1e100f64 as usize;
    &ary[idx..]
}

fn main() {
    println!("{}", f(&[1; 5])[0xdeadbeef]);
}

-Oを使用したシステムのセグメンテーション違反（毎晩遅く）。

安全な錆でのメモリ安全性の違反を考慮して、I-unsoundでマークします。

@bluss 、これは私にとってsegfualtではなく、アサーションエラーを与えるだけです。 私がそれを追加したのでタグを外します

ため息、-Oを忘れて、タグを付け直しました。

P-highに再指名。 どうやらこれはある時点でP-highでしたが、時間の経過とともに低くなりました。 これは正確さのためにかなり重要なようです。

編集：トリアージコメントに反応せず、手動でラベルを追加しました。

オーバーフローの前例（シフトなど）は、何らかの動作に落ち着くことであるように思われます。 Javaは範囲を法として結果を生成するようですが、これは不合理ではないようです。 それを処理するために必要なLLVMコードの種類がわかりません。

https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls -5.1.3によると、JavaはNaN値が0と無限大にマップされることも保証します最小/最大の表現可能な整数に。 さらに、変換のJavaルールは、単なるラッピングよりも複雑であり、飽和（ intまたはlongへの変換の場合）とラッピング（より小さな整数型への変換の場合）の組み合わせにすることができます。 、 必要に応じて）。 Javaから変換アルゴリズム全体を複製することは確かに可能ですが、キャストごとにかなりの量の操作が必要になります。 特に、LLVMでのfpto[us]i操作の結果が未定義の動作を示さないようにするには、範囲チェックが必要になります。

別の方法として、float-> intキャストは、元の値の切り捨てが宛先タイプの値（または[iu]size ？）として表される場合にのみ有効であることが保証されることをお勧めします。値が忠実に表現されていない場合にパニックを引き起こすデバッグビルドに関するアサーションがあります。

Javaアプローチの主な利点は、変換関数が完全であることですが、これは予期しない動作が忍び寄る可能性があることも意味します。未定義の動作は防止されますが、キャストが実際に意味があるかどうかをチェックしないようにだまされやすくなります。 （これは残念ながら他のキャストにも当てはまります：心配:)。

もう1つのアプローチは、現在算術演算に使用されているアプローチと一致します。リリースでのシンプルで効率的な実装、デバッグでの範囲チェックによってトリガーされるパニックです。 残念ながら、他のasキャストとは異なり、これによりそのような変換がチェックされます。これはユーザーにとって驚くべきことです（ただし、算術演算との類似性がここで役立つ場合があります）。 これも一部のコードを壊しますが、AFAICTは、現在未定義の動作に依存しているコードでのみ発生するはずです（つまり、未定義の動作を「任意の整数を返しましょう。明らかにどちらでもかまいません」をパニックに置き換えます）。

問題は「整数を返そう、どちらでもかまわない」ではなく、ランダムな値ではなく鼻の悪魔の値であるundefを引き起こし、LLVMはundefが発生しないと想定できることです。ひどい間違ったことをする最適化を可能にします。 それがランダムな値であるが、決定的にundefではない場合、それは健全性の問題を修正するのに十分です。 表現できない値がどのように表現されるかを定義する必要はありません。undefを防ぐ必要があります。

@ rust-lang / compilerミーティングで議論されました。 最も一貫した行動方針は残っています：

1. オーバーフローチェックが有効になっている場合は、不正なキャストやパニックをチェックします。
2. それ以外の場合は、フォールバック動作が必要です。有効な値の実行時コストが最小（理想的にはゼロ）である必要がありますが、LLVM undefでない限り、正確な動作はそれほど重要ではありません。

主な問題は、オプション2の具体的な提案が必要なことです。

トリアージ：P-medium

@nikomatsakis as現在、デバッグビルドでパニックになったことはありますか？ そうでない場合は、一貫性と予測可能性のために、そのままにしておくことが望ましいようです。 （算術と同じように、あるべきだと思いますが、それは別の過去の議論です。）

それ以外の場合は、フォールバック動作が必要です。有効な値の実行時コストが最小（理想的にはゼロ）である必要がありますが、LLVM undefでない限り、正確な動作はそれほど重要ではありません。

具体的な提案：数字と指数をu64として抽出し、数字を指数でビットシフトします。

fn f64_as_u64(f: f64) -> u64 {
    let (mantissa, exponent, _sign) = f.integer_decode();
    mantissa >> ((-exponent) & 63)
}

はい、それはゼロコストではありませんが、ある程度最適化可能であり（ integer_decode inlineとマークした方がよいでしょう）、少なくとも決定論的です。 float-> intキャストを拡張する将来のMIRパスは、floatがキャストしても問題ないことが保証されているかどうかを分析し、この重い変換をスキップする可能性があります。

LLVMには変換関数用のプラットフォーム組み込み関数がありませんか？

編集： @zwarichは言った（ずっと前に）：

現時点での唯一の解決策は、ターゲット固有の組み込み関数を使用することです。 少なくとも私が尋ねた誰かによると、それはJavaScriptCoreが行うことです。

なぜパニックにさえ悩むのですか？ AFAIK、 @ glaebhoerlは正しい、 asは切り捨て/拡張することになっている、オペランドをチェックしない。

2016年3月5日土曜日03:47:55 AM -0800に、GáborLehelは次のように書いています。

@nikomatsakis as現在、デバッグビルドでパニックになったことはありますか？ そうでない場合は、一貫性と予測可能性のために、そのままにしておくことが望ましいようです。 （算術と同じように、あるべきだと思いますが、それは別の過去の議論です。）

本当。 私はそれが説得力があると思います。

2016年3月9日水曜日02:31:05 AM -0800、Eduard-MihaiBurtescuは次のように書いています。

LLVMには変換関数用のプラットフォーム組み込み関数がありませんか？

編集：

現時点での唯一の解決策は、ターゲット固有の組み込み関数を使用することです。 少なくとも私が尋ねた誰かによると、それはJavaScriptCoreが行うことです。

なぜパニックにさえ悩むのですか？ AFAIK、 @ glaebhoerlは正しい、 asは切り捨て/拡張することになっている、オペランドをチェックしない。

はい、私は以前に間違っていたと思います。 asは「チェックされていない切り捨て」です
オペレーター、良くも悪くも、一貫性を保つのが最善のようです
その哲学で。 ターゲット固有の組み込み関数を使用することは完全に可能性があります
でも良い解決策？

@nikomatsakis ：動作はまだ定義されていないようですか？ それに関する計画についての最新情報を教えていただけますか？

はるかに少ない数でこれに遭遇しただけです

    let x: f64 = -1.0;
    x as u8

最適化に応じて0、16などの結果になりますが、255として定義されることを期待していたので、 x as i16 as u8を記述する必要はありません。

@gmorenz !0u8を試しましたか？

意味をなさないコンテキストでは、[-255、255]の範囲で、ネットワークを介して送信されたデータの変換からf64を取得していました。 私はそれがうまくラップすることを望んでいました（ <i32> as u8がラップするのとまったく同じ方法で）。

これが「killundef」 http://lists.llvm.org/pipermail/llvm-dev/2016-October/106182.htmlに対する最近のLLVMの提案ですが、これが自動的に解決されるかどうかを知るのに十分な知識はほとんどありません。この問題。

彼らはundefをpoisonに置き換えており、セマンティクスはわずかに異なります。 int-> floatが定義された動作をキャストすることはありません。

飽和キャストを行うための明示的な方法を提供する必要があります

https://github.com/rust-lang/rust/issues/10184#issuecomment -139858153を考えると、このようにI-crashとマークする必要があるようです。

今日#rust-beginnersこれについて質問がありましたが、誰かが野生でそれに遭遇しました。

私が@jimblandyで書いている本、_Programming Rust_は、このバグについて言及しています。

数種類のキャストが許可されています。

• 数値は、組み込みの数値タイプから他のタイプにキャストできます。

  （...）

  ただし、この記事の執筆時点では、大きな浮動小数点値を小さすぎて表現できない整数型にキャストすると、未定義の動作が発生する可能性があります。 これにより、安全なRustでもクラッシュが発生する可能性があります。 これは、コンパイラgithub.com/rust-lang/rust/issues/10184のバグ

この章の締め切りは5月19日です。最後の段落を削除したいのですが、少なくとも最初に何らかの計画を立てる必要があると思います。

どうやら現在のJavaScriptCoreはx86で使用しています。 彼らはCVTTSD2SI命令を使用し、値が範囲外の場合はいくつかのヘアリーC ++にフォールバックします。 現在、範囲外の値が爆発しているため、その命令を使用すると（フォールバックなしで！）、1つのアーキテクチャのみではありますが、現在の状態が改善されます。

正直なところ、 as数値キャストを廃止し、代わりにFromとTryFromまたはconvcrateのようなものを使用する必要があると思います。

たぶんそうかもしれませんが、それは私には直交しているようです。

OK、この会話全体を読み直しました。 この操作はパニックにならないという合意があると思います（ asとの一般的な一貫性のため）。 行動がどうあるべきかについては、2つの主要な候補があります。

• ある種の定義された結果
  
  
  
  • プロ：これは、これまでの私たちの一般的な哲学と最大限に一致していると思います。
  
  
  • 短所：この場合、特定の定義された結果を生成するための真にポータブルな方法はないようです。 これは、範囲外の値に対して何らかのフォールバックを伴うプラットフォーム固有の組み込み関数を使用することを意味します（たとえば、飽和状態へのフォールバック、@ oli-obkが提案したこの関数、 Javaの定義、または「ヘアリーC ++」へのフォールバック
  
  
  • 最悪の場合、「範囲外」の場合にいくつかのifを挿入することができます。
  
  
• 未定義の値（未定義の動作ではありません）
  
  
  
  • 長所：これにより、各プラットフォームで使用可能なプラットフォーム固有の組み込み関数を使用できます。
  
  
  • 短所：それは携帯性の危険です。 一般に、少なくとも言語では、未定義の結果をあまり頻繁に使用していないように感じ
  
  

最初のケースで結果がどうあるべきかについて明確な前例があるかどうかは私にはわかりませんか？

それを書き留めた後、私の好みは決定論的な結果を維持することです。 決定論の線を引くことができるすべての場所が勝利であるように私は感じます。 しかし、結果がどうあるべき

飽和は理解できて便利なように見えるので好きですが、 u64 as u32が切り捨てを行う方法とはどういうわけか一致していないようです。 したがって、おそらく切り捨てに基づくある種の結果は理にかなっています。これはおそらく@ oli-obkが提案したものだと思います。そのコードが何を意図しているのか完全には理解していません。 =）

私のコードは、0..2 ^ 64の範囲の値に正しい値を与え、それ以外のすべてには決定論的ですが偽の値を与えます。

浮動小数点数は仮数^指数で表されます。たとえば、 1.0は(2 << 52) ^ -52あり、ビットシフトと指数はバイナリで同じものであるため、シフトを逆にすることができます（したがって、指数と右の否定）シフト）。

決定論の場合は+1。

人間にとって意味のある2つのセマンティクスがあります。コンパイラーが計算を最適化できない場合は、範囲内の値に対してどちらか速い方を選択する必要があると思います。 （値が範囲内にあることをコンパイラーが認識している場合、両方のオプションで同じ結果が得られるため、同等に最適化できます。）

• 彩度（範囲外の値はIntType::max_value() / min_value() ）
• モジュロ（範囲外の値は、最初にbigintに変換してから、切り捨てることによって処理されます）

次の表は、両方のオプションを完全に指定することを目的としています。 Tは、任意のマシン整数型です。 TminとTmaxはT::min_value()とT::max_value()です。 RTZ（v）は、vの数学値を取り、ゼロに向かって丸めて数学整数を取得することを意味します。

v | v as T （彩度）| v as T （モジュロ）
---- | ---- | --------
範囲内（Tmin <= v <= Tmax）| RTZ（v）| RTZ（v）
負のゼロ| 0 | 0
NaN | 0 | 0
インフィニティ| Tmax | 0
-インフィニティ| Tmin | 0
v> Tmax | Tmax | Tに合うように切り捨てられたRTZ（v）
v <Tmin | Tmin | Tに合うように切り捨てられたRTZ（v）

ECMAScript標準では、操作ToInt32 、ToUint32、ToInt16、ToUint16、ToInt8、ToUint8が指定されています。上記の「モジュロ」オプションの目的は、すべての場合にこれらの操作を一致させることです。

ECMAScriptは、上記のどちらの場合にも一致しToInt8Clampも指定します

@ oli-obkの提案は、範囲内の値について、計算が高速かどうかを検討する価値のある3番目の方法です。

@ oli-obk符号付き整数型はどうですか？

関連https://github.com/rust-lang/rust/issues/41799

別の提案をミックスに投入する：u128がフロートにキャストすることを安全ではないとマークし、人々にそれを処理する方法を明示的に選択するように強制します。 u128は現在かなりまれです。

@Manishearth私は同様のセマンティクス整数→浮動小数点数として浮動小数点数→整数を望んでいます。 どちらもUBに対応しており、float→integerを安全でなくすることはできないため、integer→floatも安全でなくなることは避けてください。

float→integersaturatingの場合、AFAICTが高速になります（ andシーケンス、テスト+ジャンプフロートの比較とジャンプ、すべて最新のアーチで0.66または0.5 2-3サイクルになります）。 個人的には、範囲内の値が可能な限り高速である限り、決定する正確な動作を気にすることはできませんでした。

オーバーフローのように動作させるのは理にかなっていますか？ したがって、デバッグビルドでは、未定義の動作でキャストを行うとパニックになります。 次に、 1.04E+17.saturating_cast::<u8>() 、 unsafe { 1.04E+17.unsafe_cast::<u8>() }などのキャスト動作を指定するためのメソッドを作成できます。

ああ、問題はu128だけにあると思ったので、どちらの方法でも安全ではありません。

@cryze UBは、安全なコードのリリースモードでも存在してはなりません。 オーバーフローはまだ定義された動作です。

とはいえ、デバッグでパニックになり、リリース時に素晴らしいでしょう。

これは以下に影響します：

• f32 -> u8, u16, u32, u64, u128, usize （ -1f32 as _すべてのために、 f32::MAX as _すべてが、u128用）
• f32 -> i8, i16, i32, i64, i128, isize （すべてf32::MAX as _ ）
• f64 ->すべてのint（すべてf64::MAX as _ ）

f32::INFINITY as u128もUBです

@CryZe

オーバーフローのように動作させるのは理にかなっていますか？ したがって、デバッグビルドでは、未定義の動作でキャストを行うとパニックになります。

これは私が最初に考えたものですが、 as変換は現在パニックになることはないことを思い出しました（良くも悪くも、 asでオーバーフローチェックを行いません）。 したがって、最も類似したことは、「定義された何かを行う」ことです。

FWIW、「kill undef」は、実際には、メモリの安全性を修正する方法を提供しますが、結果は非決定的です。 重要なコンポーネントの1つは次のとおりです。

3）の伝播を停止する新しい命令 '％y = freeze％x'を作成します
毒。 入力がpoisonの場合、任意ですが固定された、
値。 （古いundefと同様ですが、使用するたびに
入力値を返すだけです。

undefが今日のメモリ安全性に違反するために使用される理由は、undefが使用間、特に境界チェックとそれに続くポインタ演算の間で値を魔法のように変更できるためです。 危険なキャストが行われるたびにrustcがフリーズを追加した場合、未知の値が得られますが、それ以外の場合は正常に動作します。 もちろん、キャストに対応するマシン命令は変動する値ではなく単一の値を生成するため、パフォーマンス面では、フリーズは基本的にここでは無料です。 オプティマイザが何らかの理由でキャスト命令を複製したいと感じた場合でも、範囲外の入力の結果は通常、特定のアーキテクチャで決定論的であるため、複製しても安全です。

...しかし、誰かが疑問に思っていたとしても、アーキテクチャ間で決定論的ではありません。 x86は、すべての不正な入力に対して0x80000000を返します。 ARMは範囲外の入力に対して飽和し、（この擬似コードを正しく読んでいる場合）NaNに対して0を返します。 したがって、目標が決定論的でプラットフォームに依存しない結果を生成することである場合、プラットフォームのfp-to-int組み込み関数を使用するだけでは十分ではありません。 少なくともARMでは、ステータスレジスタで例外をチェックする必要もあります。 これはそれ自体にいくらかのオーバーヘッドがあるかもしれません、そして確かに組み込みを使用することがまだしなかったという万が一のイベントでの自動ベクトル化を防ぎます。 または、通常の比較操作を使用して範囲内の値を明示的にテストしてから、通常のfloat-to-intを使用することもできます。 オプティマイザーの方がずっといいですね…

asコンバージョンは現在パニックになることはありません

ある時点で、 +をパニックに変更しました（デバッグモード）。 以前はUBだったケースで、 asパニックが発生しても、ショックを受けることはありません。

チェックに関心がある場合（これを行う必要があります）、 as非推奨にするか（これが唯一の良いオプションであるユースケースはありますか？）、少なくともそれを使用しないようにアドバイスし、人々を次のようなものに移す必要があります。代わりにTryFromとTryInto使用します。これは、 asをそのままにしておくことが決定されたときに、元に戻す予定であると述べたものです。 議論されているケースは、抽象的には、チェックを行わないようにasがすでに定義されているケースと質的に異なるとは思いません。 違いは、実際には、これらのケースの実装は現在不完全であり、UBがあることです。 あなたがに頼ることができない世界asチェックを行う（ほとんどの種類のために、それはないので）、そしてあなたはパニックではない、それに頼ることはできません（理由はいくつかのタイプのため、それはある）、およびそれは一貫性がなく、私たちはまだ非推奨ではありません。私にとってはそれらすべての中で最悪のようです。

したがって、この時点で、 @ jorendorffは基本的に、私にとって最良の計画であると思われるものを列挙し

• asには、決定論的な動作があります。
• それがどれほど賢明であるか、そしてそれがどれほど効率的であるかの組み合わせに基づいて行動を選びます

彼は3つの可能性を列挙しました。 残りの作業は、それらの可能性を調査すること、または少なくともそのうちの1つを調査することだと思います。 つまり、実際に実装して、それがどれほど「遅い」か「速い」かを感じ取ってみてください。

それを刺したいというモチベーションを感じている人はいますか？ 誰かを引き付けることを期待して、これにE-help-wantedタグを付けます。 （@ oli-obk？）

ええと、私はクロスプラットフォームの一貫性に代償を払うのではなく：/ガベージインです。どのガベージが出るかは気にしません（ただし、デバッグアサーションは非常に役立ちます）。

現在、Rustのすべての丸め/切り捨て関数は非常に遅いため（細心の注意をasて正確に実装された関数呼び出し）、

as裸のcvttss2si以外のものにする場合は、それだけの安定した代替手段も追加してください。

@pornelこれは理論的な種類のUBだけではなく、ubであることを無視すれば問題はありませんが、現実の世界に影響を及ぼします。 実世界のコード例から＃41799を抽出しました。

@ est31 UBのままにしておくのは間違っていることに同意しますが、UBの解決策としてfreeze提案されているのを見てきました。 それを定義された決定論的値にするAFAIK、あなたはただどちらを言うことができません。 その振る舞いは私には問題ありません。

たとえば場合、私は大丈夫と思いますので、 u128::MAX as f32決定論的に生成17.5 x86版、および999.0 x86-64の上、および-555 ARM上。

freezeは、定義された、決定論的な、指定されていない値を生成しません。 その結果は依然として「コンパイラーが好む任意のビットパターン」であり、同じ操作の使用全体でのみ一貫しています。 これは、人々が上記で収集したUB生成の例を回避する可能性がありますが、これは得られません。

f32としてのu128 :: MAXは、x86で17.5、x86-64で999.0、ARMで-555を決定論的に生成しました。

たとえば、LLVMがu128::MAX as f32がオーバーフローし、それをfreeze poisonに置き換えることに気付いた場合、x86_64でのfn foo() -> f32 { u128::MAX as f32 }有効な引き下げは次のようになります。

foo:
  ret

（つまり、リターンレジスタに最後に保存されたものを返すだけです）

そうですか。 それは私の使用にはまだ受け入れられます（範囲外の値を期待する場合は、事前にクランプを行います。範囲内の値を期待するがそうではない場合は、何があっても正しい結果が得られません） 。

値がフリーズされている限り、範囲外のフロートキャストが任意の値を返すことに問題はないので、それ以上の未定義の動作を引き起こすことはありません。

freezeようなものがLLVMで利用できますか？ それは純粋に理論的な構成だと思いました。

@nikomatsakis （ poisonとは異なり）そのように使用されるのを見たことがありません-これはpoison / undefの計画された改良です。

freezeは、今日のLLVMにはまったく存在しません。 提案されただけです（このPLDIペーパーは自己完結型ですが、メーリングリストでも多く議論されています）。 この提案にはかなりの賛同が得られているようですが、もちろんそれが採用される保証はなく、タイムリーに採用されることははるかに少ないです。 （ポインター型からのポインター型の削除は何年もの間受け入れられてきましたが、まだ行われていません。）

ここで提案されている変更についてより広範な議論を得るためにRFCを開きたいですか？ IMO、 asのパフォーマンスに影響を与える可能性のあるものはすべて論争になりますが、人々に彼らの声を聞かせる機会を与えなければ、二重に論争になります。

私はJulia開発者ですが、同じLLVMバックエンドを共有しているため、同様の問題が発生しているため、この問題をしばらく追跡しています。 興味がある場合は、これが私たちが決めたものです（私のマシンの単一の機能のおおよそのタイミングで）：

• unsafe_trunc(Int64, x)は、対応するLLVM組み込みfptosi （1.5 ns）に直接マップされます
• trunc(Int64, x)は、範囲外の値（3 ns）に対して例外をスローします
• convert(Int64, x)は、範囲外または整数以外の値（6 ns）に対して例外をスローします

また、メーリングリストで未定義の振る舞いをもう少し明確にすることについて

@bstrie RFCは問題ありませんが、データがあると間違いなく役立つと思います。 ただし、@ simonbyrneのコメントはその点で非常に役立ちます。

JSセマンティクス（前述のモジュロ@jorendorff ）と「飽和」列のように見えるJavaセマンティクスをいじってみました。 これらのリンクが期限切れになった場合、それはJSとJavaです。

また、Rustでの飽和の簡単な実装を作成しました。これは正しいと思います（？） また、いくつかのベンチマーク数値も取得しました。 興味深いことに、飽和実装は組み込みの実装より2〜3倍遅いことが@ simonbyrneが2倍遅いだけで見つけたものとは異なります。

Rustで「mod」セマンティクスを実装する方法が完全にはわかりません...

しかし、私には、パフォーマンスが必要な人のために、多数のf32::as_u32_unchecked()メソッドなどが必要になることは明らかです。

パフォーマンスが必要な人には、たくさんのf32::as_u32_unchecked()メソッドなどが必要になることは明らかです。

それは残念です-それとも、安全であるが実装定義のバリアントを意味しますか？

実装で定義された高速デフォルトのオプションはありませんか？

@eddyb私たちはただ持っているだろうと考えていたunsafe fn as_u32_unchecked(self) -> u32にf32何に直接アナログであると、このようなas今日です。

私が書いたRustの実装が最適であるとは断言できませんが、このスレッドを読むときは、ほとんどの場合、速度よりも決定論と安全性の方が重要であるという印象を受けました。 unsafeエスケープハッチはフェンスの向こう側にいる人のためのものです。

では、プラットフォームに依存する安価なバリアントはありませんか？ 私は速い何かが、不特定の値を与えるとき、境界の外で安全ですしたいです。 一部の入力にUBを使用したくないので、もっとうまくできれば、一般的な使用には危険すぎると思います。

私の知る限り、すべてではないにしてもほとんどのプラットフォームで、この変換を実装するための標準的な方法は、UBではない範囲外の入力に対して何かを行います。 しかし、LLVMには、UBよりもそのオプション（それが何であれ）を選択する方法がないようです。 LLVM開発者に、範囲外の入力で「指定されていないがundef / poison 」結果を生成する組み込み関数を導入するように説得できれば、それを使用できます。

しかし、このスレッドの誰かが説得力のあるRFC（llvm-devリストにある）を作成し、賛同を得て、それを実装する必要があると私は推測します（私たちが気にするバックエンドで、そして他のフォールバック実装でターゲット）。 llvm-devに既存のキャストを非UBにするよう説得するよりもおそらく簡単ですが（「これによりCおよびC ++プログラムが遅くなるか」などの質問を回避できるため）、それでもそれほど簡単ではありません。

これらから選択する場合に備えて：

彩度（範囲外の値はIntType :: max_value（）/ min_value（）になります）
モジュロ（範囲外の値は、最初にbigintに変換してから、切り捨てることによって処理されます）

浮動小数点の絶対精度は値が大きくなるとすぐに低下するため、IMOのみの飽和はここでは意味があります。したがって、ある時点で、モジュロはすべてのゼロのように役に立たないものになります。

私はこれをマークE-needs-mentorとし、それをタグ付けWG-compiler-middle IMPL期間は、これをさらにを調査する絶好の機会であるかもしれないと思われるので、！ 記録の計画に関する私の既存の

@nikomatsakis

IIRC LLVMは、最終的にfreeze実装することを計画しています。これにより、 freeze実行することでUBを処理できるようになります。

これまでの私の結果： https ：

_arrayバリアントは、1024個の値のループを実行します。
_cast： x as i32
_clip：x.min（MAX）.max（MIN）as i32
_panic：xが範囲外の場合はパニックになります
_zero：範囲外の場合、結果をゼロに設定します

test bench_array_cast       ... bench:       1,840 ns/iter (+/- 37)
test bench_array_cast_clip  ... bench:       2,657 ns/iter (+/- 13)
test bench_array_cast_panic ... bench:       2,397 ns/iter (+/- 20)
test bench_array_cast_zero  ... bench:       2,671 ns/iter (+/- 19)
test bench_cast             ... bench:           2 ns/iter (+/- 0)
test bench_cast_clip        ... bench:           2 ns/iter (+/- 0)
test bench_cast_panic       ... bench:           2 ns/iter (+/- 0)
test bench_cast_zero        ... bench:           2 ns/iter (+/- 0)

おそらく、個々の操作の結果を整数に丸める必要はありません。 明らかに、これらの2 ns / iterの背後にはいくつかの違いがあるはずです。 それとも、4つのバリアントすべてで_正確に_ 2 nsのようになっていますか？

@ sp-1234部分的に最適化されているのだろうか。

@ sp-1234測定するには速すぎます。 非アレイベンチマークは基本的に役に立たない。
単一値関数を#[inline(never)]経由の関数に強制すると、2ns対3nsになります。

@ arielb1
freezeに関していくつか予約があります。 私が正しく理解していれば、凍結されたundefは任意の値を含めることができ、使用しても変化しません。 実際には、コンパイラはおそらくレジスタまたはスタックスロットを再利用します。

ただし、これは、初期化されていないメモリを安全なコードから読み取ることができることを意味します。 これにより、Heartbleedのように、秘密のデータが漏洩する可能性があります。 これがRustの観点から本当にUBと見なされるかどうかは議論の余地がありますが、明らかに望ましくないようです。

@ s3bkのベンチマークをローカルで実行しました。 スカラーバージョンが完全に最適化されていることを確認できます。また、配列バリアントのasmも疑わしいほど適切に最適化されているように見えます。たとえば、ループはベクトル化されています。

残念ながら、 black_boxスパムすることは役に立たないようです。 asmが有用な作業を行っていることはわかりますが、ベンチマークを実行すると、スカラーベンチマークに対して一貫して0nsが得られます（1nsを示すcast_zeroを除く）。 @alexcrichtonがベンチマークで100回比較を実行したことがソースコード）：

test bench_cast             ... bench:          53 ns/iter (+/- 0)
test bench_cast_clip        ... bench:         164 ns/iter (+/- 1)
test bench_cast_panic       ... bench:         172 ns/iter (+/- 2)
test bench_cast_zero        ... bench:         100 ns/iter (+/- 0)

アレイのベンチマークは、私がそれらを信頼するにはあまりにも多様です。 まあ、正直なところ、私はとにかくtestベンチマークインフラストラクチャに懐疑的です。特に、以前に取得したフラットな0nsと比較して上記の数値を確認した後はそうです。 さらに、（ベースラインとしての） black_box(x); 100回の反復でも34nsかかるため、これらの数値を確実に解釈することはさらに困難になります。

注目に値する2つのポイント：

• NaNを具体的に処理していませんが（0ではなく-infを返しますか？）、 cast_clip実装は@alexcrichtonの飽和キャストよりも遅いようです（実行と私の実行のタイミングはasほぼ同じであることに注意してください）
• @ s3bkの配列の結果とは異なり、 cast_panicは他のチェックされたキャストよりも遅いことがわかります。 また、アレイベンチマークの速度がさらに低下していることもわかります。 たぶん、これらのものは、マイクロアーキテクチャの詳細やオプティマイザのムードに大きく依存していますか？

記録のために、私はrustc 1.21.0-nightly（d692a91fa 2017-08-04）、 -C opt-level=3 、軽負荷のi7-6700Kで測定しました。

結論として、これまでのところ信頼できるデータはなく、より信頼できるデータを取得するのは難しいように思われると結論付けています。 さらに、実際のアプリケーションが実時間の1％でもこの操作に費やしていることを強く疑っています。 したがって、 -Zフラグの背後で、 rustcに

編集：可能であれば、さまざまなアーキテクチャ（ARMなど）やマイクロアーキテクチャでこのようなベンチマークを実行することもお勧めします。

私はさびにあまり詳しくないことを認めますが、この行は微妙に間違っていると思います： std::i32::MAX （2 ^ 31-1）はFloat32として正確に表現できないため、 std::i32::MAX as f32は最も近い表現可能な値（2 ^ 31）に丸められます。 この値が引数xとして使用される場合、結果は技術的に未定義です。 厳密な不等式に置き換えると、このケースが修正されます。

ええ、私たちは以前サーボでまさにその問題を抱えていました。 最終的な解決策は、f64にキャストしてからクランプすることでした。

他の解決策もありますが、それらはかなりトリッキーであり、錆はこれをうまく処理するための優れたAPIを公開していません。

上限として0x7FFF_FF80i32を使用し、-0x8000_0000i32を使用すると、f64にキャストせずにこれを解決できます。
編集：正しい値を使用してください。

0x7fff_ff80を意味していると思いますが、厳密な不等式を使用するだけで、コードの意図が明確になる可能性があります。

x < 0x8000_0000u32 as f32 ？ それはおそらく良い考えでしょう。

提案されているすべての決定論的オプションについて考えると、とにかく頻繁に行われると思うので、クランプは一般的に最も有用なものです。 変換タイプが実際に飽和状態であると文書化される場合、手動クランプは不要になります。

提案された実装はマシン命令に適切に変換されず、分岐に大きく依存しているため、私は少しだけ心配しています。 分岐すると、パフォーマンスは特定のデータパターンに依存します。 上記のテストケースでは、同じ分岐が常に行われ、プロセッサには以前の多くのループ反復からの良好な分岐予測データがあるため、すべてが（比較的）高速に見えます。 現実の世界はおそらくそのようには見えないでしょう。 さらに、分岐は、コードをベクトル化するコンパイラーの機能を損ないます。 私は@rkruppeの意見に同意しません。この操作は、ベクトル化と組み合わせてテストするべきではないというものです。 高性能コードではベクトル化が重要であり、一般的なアーキテクチャで単純なキャストをベクトル化できることは重要な要件です。

上記の理由により、飽和セマンティクスと@simonbyrneの修正を使用した試してみました。 u16 、 i16 、 i32はすべてわずかに異なるケースをカバーする必要があるため、パフォーマンスが異なるため、実装しました。

結果：

test i16_bench_array_cast       ... bench:          99 ns/iter (+/- 2)
test i16_bench_array_cast_clip  ... bench:         197 ns/iter (+/- 3)
test i16_bench_array_cast_clip2 ... bench:         113 ns/iter (+/- 3)
test i16_bench_cast             ... bench:          76 ns/iter (+/- 1)
test i16_bench_cast_clip        ... bench:         218 ns/iter (+/- 25)
test i16_bench_cast_clip2       ... bench:         148 ns/iter (+/- 4)
test i16_bench_rng_cast         ... bench:       1,181 ns/iter (+/- 17)
test i16_bench_rng_cast_clip    ... bench:       1,952 ns/iter (+/- 27)
test i16_bench_rng_cast_clip2   ... bench:       1,287 ns/iter (+/- 19)

test i32_bench_array_cast       ... bench:         114 ns/iter (+/- 1)
test i32_bench_array_cast_clip  ... bench:         200 ns/iter (+/- 3)
test i32_bench_array_cast_clip2 ... bench:         128 ns/iter (+/- 3)
test i32_bench_cast             ... bench:          74 ns/iter (+/- 1)
test i32_bench_cast_clip        ... bench:         168 ns/iter (+/- 3)
test i32_bench_cast_clip2       ... bench:         189 ns/iter (+/- 3)
test i32_bench_rng_cast         ... bench:       1,184 ns/iter (+/- 13)
test i32_bench_rng_cast_clip    ... bench:       2,398 ns/iter (+/- 41)
test i32_bench_rng_cast_clip2   ... bench:       1,349 ns/iter (+/- 19)

test u16_bench_array_cast       ... bench:          99 ns/iter (+/- 1)
test u16_bench_array_cast_clip  ... bench:         136 ns/iter (+/- 3)
test u16_bench_array_cast_clip2 ... bench:         105 ns/iter (+/- 3)
test u16_bench_cast             ... bench:          76 ns/iter (+/- 2)
test u16_bench_cast_clip        ... bench:         184 ns/iter (+/- 7)
test u16_bench_cast_clip2       ... bench:         110 ns/iter (+/- 0)
test u16_bench_rng_cast         ... bench:       1,178 ns/iter (+/- 22)
test u16_bench_rng_cast_clip    ... bench:       1,336 ns/iter (+/- 26)
test u16_bench_rng_cast_clip2   ... bench:       1,207 ns/iter (+/- 21)

テストは、Intel Haswell i5-4570CPUとRust1.22.0で毎晩実行されました。
clip2は、新しいブランチレス実装です。 これは、2 ^ 32の可能なすべてのf32入力値でclipと一致します。

rngベンチマークでは、さまざまなケースに頻繁にヒットするランダムな入力値が使用されます。 これにより、分岐予測が失敗した場合に発生する_extreme_パフォーマンスコスト（通常のコストの約10倍!!!）が明らかになります。 これを考慮することは_非常に_重要だと思います。 これは実際の平均的なパフォーマンスでもありませんが、それでも可能性のあるケースであり、一部のアプリケーションはこれに遭遇します。 人々はf32キャストが一貫したパフォーマンスを持つことを期待するでしょう。

x86でのアセンブリの比較： https ：//godbolt.org/g/AhdF71
ブランチレスバージョンは、minss / maxss命令に非常にうまくマッピングされます。

残念ながら、RustからgodboltにARMアセンブリを生成させることはできませんでしたが、ClangとのメソッドのARM比較は次のとおりです： https ：//godbolt.org/g/s7ronw
コードをテストできず、ARMの多くを知らない場合：コードサイズも小さいように見え、LLVMはほとんどの場合有望に見えるvmax / vminを生成します。 たぶん、LLVMは、コードの大部分を1つの命令に折りたたむように最終的に教えられるでしょうか？

@ActuallyaDeviloper asmとベンチマークの結果はとても良さそうです！ さらに、あなたのようなブランチレスコードは、他のソリューションのネストされた条件よりもrustcで生成する方がおそらく簡単です（記録として、lang item関数を呼び出す代わりにインラインIRを生成したいと思います）。 これを書いてくれてありがとう。

u16_cast_clip2について質問があります：NaNを処理していないようです？！ NaNについてのコメントがありますが、関数はNaNを変更せずに通過させ、 f32にキャストしようとすると思います（そうでない場合でも、0ではなく境界値の1つを生成します） ）。

PS：明確にするために、私はキャストをベクトル化できるかどうかが重要でないことを暗示しようとしていませんでした。 周囲のコードがベクトル化可能であるかどうかは明らかに重要です。 ただし、ベクトル化は適用できないことが多く、私がコメントしたベンチマークではスカラーパフォーマンスについて何も述べていなかったため、スカラーパフォーマンスも重要です。 興味深いことに、 *array*ベンチマークのasmをチェックして、それらがまだ実装でベクトル化されているかどうかを確認しましたか？

@rkruppeそうです、私は誤ってifの側面を交換し、それを忘れてしまいました。 f32 as u16は、たまたま上位0x8000を切り捨てることで正しいことを行ったため、テストでもそれを検出できませんでした。 今回はブランチを再度交換し、すべてのメソッドをif (y.is_nan()) { panic!("NaN"); }テストすることで、問題を修正しました。

以前の投稿を更新しました。 x86コードはまったく変更されていませんが、残念ながら、この変更により、何らかの理由でLLVMがu16 ARMの場合にvmaxを生成できなくなります。 これは、そのARM命令のNaN処理に関する詳細に関係していると思います。あるいは、LLVMの制限である可能性があります。

それが機能する理由については、符号なしの値の下限値が実際には0であることに注意してください。 したがって、NaNと下限を同時にキャッチできます。

配列バージョンはベクトル化されます。
ゴッドボルト： https ：//godbolt.org/g/HnmsSV

Re： ARM asm 、 vmaxが使用されなくなった理由は、どちらかのオペランドがNaNの場合にNaNを返すためだと思いvmovgt 、以前のvcmpを0で参照）。

それが機能する理由については、符号なしの値の下限値が実際には0であることに注意してください。 したがって、NaNと下限を同時にキャッチできます。

ああ、そうだね。 いいね。

-Zフラグの後ろで、rustcのキャストとしてsaturatingを実装することで前進することをお勧めします

私はこれを実装しました。＃41799も修正してさらに多くのテストを行ったら、PRを提出します。

45134は、私が見逃したコードパスを指摘しています（LLVM定数式の生成–これはrustc自身の定数評価とは別のものです）。 その修正を同じPRにロールバックしますが、少し時間がかかります。

@rkruppe miriが同じ変更で終わるように、@ oli-obkと調整する必要があります。

プルリクエストがアップしています：＃45205

45205が統合されたため、 -Z saturating-float-castsを介してRUSTFLAGS -Z saturating-float-castsを渡すことで、誰でも（次の夜から）飽和のパフォーマンスへの影響を測定できるようになりました。 [1]このような測定は、この問題をどのように進めるかを決定するために非常に価値があります。

[1]厳密に言えば、これは標準ライブラリの非ジェネリック、非#[inline]部分には影響しないため、100％正確にするには、Xargoを使用してローカルでstdをビルドする必要があります。 ただし、これによって影響を受けるコードが多くなるとは思いません（たとえば、さまざまな変換特性の実装は#[inline]です）。

@rkruppe https://internals.rust-lang.org/t/help-us-benchmark-incremental-compilation/6153/と同じように、internals / usersページを開始してデータを収集することをお勧めし

@rkruppe追跡の問題を作成する必要があります。 この議論はすでに2つの問題に分かれています。 それは良いことではありません！

@Gankroはい、同意しますが、その投稿を適切に書く時間が見つかるまでに数日かかる可能性があるので、その間にこの問題を購読している人々からのフィードバックを求めると思いました。

@ est31うーん。 -Zフラグは両方のキャスト方向をカバーしますが（振り返ってみると、これは間違いだった可能性があります）、両方のスイッチを同時にオンにする可能性は低く、2つの間に必要なものの重複はほとんどありません。議論されます（たとえば、この問題は飽和のパフォーマンスに依存しますが、＃41799では正しい解決策が何であるかについて合意されています）。
主にこの問題を対象としたベンチマークが＃41799の修正の影響も測定するのは少しばかげていますが、それ

フラグの有用性がなくなったらフラグを削除するタスクの追跡の問題を検討しましたが、ここと＃41799で行われている議論をマージする必要はないと思います。

内部投稿を作成しました： https ：

それをコピーするか、私が投稿できるようにメモをください。 （ const fn動作について少し混乱していることに注意してください）

もう1つのヒントは、float-> int変換のコストは、基本的なものではなく、現在の実装に固有のものであるということです。 x86では、 cvtss2si cvttss2si戻ってあまりにも低では0x80000000、高すぎる、とナンの例では、1が実装できるよう-Zsaturating-float-castsとcvtss2si cvttss2si後に0x80000000の場合は特別なコードが続くため、一般的な場合は単一の比較および予測可能なブランチである可能性があります。 ARMでは、 vcvt.s32.f32はすでに-Zsaturating-float-castsセマンティクスがあります。 LLVMは現在、どちらの場合も余分なチェックを最適化しません。

@Gankro

素晴らしい、どうもありがとう！ 要旨にいくつかメモを残しました。 これを読んだ後、u128-> f32キャストを-Zフラグから分離することに挑戦したいと思います。 2つの直交する特徴をカバーする旗についての気が散る警告を取り除くためだけに。

（float-> intの問題のみをカバーするように-Zフラグを再フォーカスするために＃45900を提出しました）

マスベンチマークを要求する前に、 @ sunfishcode （少なくともx86の場合）でプラットフォーム固有の実装を取得できれば便利です。 それほど難しいことではないはずです。

問題は、私が知る限り、LLVMが現在これを行う方法を提供していないことです。ただし、リリースに必ずしも推奨しないインラインasmを使用する場合を除きます。

議論を反映するためにドラフトを更新しました（基本的に、u128-> f32のインライン言及を最後の追加セクションにリッピングします）。

@sunfishcodeよろしいですか？ llvm.x86.sse.cvttss2siあなたが探しているものではありませんか？

これを使用する遊び場のリンクは次のとおりです。

https://play.rust-lang.org/?gist=33cf9e0871df2eb2475b845af4f1b574&version=nightly

リリースモードでは、 float_to_int_with_intrinsicとfloat_to_int_with_as両方が1つの命令にコンパイルされます。 （デバッグモードでは、 float_to_int_with_intrinsicはいくつかの命令を無駄にしてゼロを高値にしますが、それほど悪くはありません。）

定数畳み込みも正しく行うようです。 例えば、

float_to_int_with_intrinsic(42.0)

になります

movl    $42, %eax

しかし、範囲外の値、

float_to_int_with_intrinsic(42.0e33)

折りたたまれない：

cvttss2si   .LCPI2_0(%rip), %eax

（理想的には、定数0x80000000にフォールドしますが、それは大したことではありません。重要なことは、undefを生成しないことです。）

かっこいい、イケてる。 それはうまくいくようです！

結局のところ、 cvttss2si基づいて構築する方法があることを知っておくのは素晴らしいことです。 ただし、ベンチマークを要求する前に、実装を変更して使用する方が明らかに良いということに同意しません。

ほとんどの人はx86でベンチマークを行うため、x86を特別な場合に使用すると、一般的な実装に関するデータがはるかに少なくなり、他のほとんどのターゲットで引き続き使用されます。 確かに、他のアーキテクチャについて何かを推測することはすでに困難ですが、まったく異なる実装により、それは完全に不可能になります。

次に、「単純な」ソリューションを使用してベンチマークを収集し、実際のコードにパフォーマンスの低下がないことがわかった場合（そして、それが私が期待していることです）、次のことを試みる手間をかける必要さえありません。このコードパスをさらに最適化します。

最後に、 cvttss2si構築が現在よりも速くなるかどうかさえわかりません（ただし、ARMでは、適切な命令を使用する方が明らかに優れています）。

• 変換が0x80000000を返すことに気付くには比較が必要です。その場合でも、int :: MINまたはint :: MAXのどちらを返す必要があるかを知るために（入力値の）別の比較が必要です。 また、符号付き整数型の場合、NaNを区別するために3回目の比較を回避する方法がわかりません。 したがって、最悪の場合：
  
  
  
  • 比較/選択の数を節約しません
  
  
  • フロート比較をint比較と交換していますが、これはOoOコアに適しているあります（比較を実行できるFUでボトルネックになっている場合は、比較的大きいように見えます）が、その比較もフロートに依存します-> int比較。現在の実装の比較はすべて独立しているため、これが成功であるかどうかは明らかではありません。
  
  
• ベクトル化はおそらくより困難または不可能になります。 ループベクトライザーがこの組み込み関数を処理することはまったく期待していません。
• （AFAIK）この戦略は一部の整数型にのみ適用されることにも注意してください。 たとえば、f32-> u8は、結果の追加の修正が必要になるため、この戦略は明らかに不採算になります。 どのタイプがこれの影響を受けるかはよくわかりませんが（たとえば、f32-> u32の命令があるかどうかはわかりません）、これらのタイプのみを使用するアプリケーションはまったくメリットがありません。
• ハッピーパスで1つの比較のみを使用して分岐ソリューションを実行できます（以前のソリューションのように2つまたは3つの比較、つまり分岐とは対照的です）。 ただし、 @ ActuallyaDeviloperが以前に論じたように、分岐は望ましくない場合があります。パフォーマンスは、ワークロード依存および分岐予測依存になります。

ベンチマークが何を示しているかに関係なく、多数のunsafe fn as_u32_unchecked(self) -> u32とその友人が必要になると想定しても安全ですか？ 彼らが減速を観察することになった場合、誰かが他にどのような潜在的な頼りになるでしょうか？

@bstrieそのような場合、構文をas <type> [unchecked]拡張し、 uncheckedがunsafeのみ存在することを要求するようなことを行う方が理にかなっていると思います。コンテキスト。

私が見ているように、 _uncheckedフォレストは、 asキャストのバリアントとして機能します。直感性と、クリーンで使用可能なドキュメントの生成の両方に関して、いぼになります。

@ssokolow構文の追加は常に最後の手段である必要があります。特に、これらすべてを10個の暗記関数で処理できる場合はなおさらです。 特に、 unsafeロックを解除するものの数を増やすのではなく減らす必要があるため、一般的なfoo.as_unchecked::<u32>()を持っていても、構文の変更（および付随する途方もないバイクシェッド）よりも望ましいでしょう。

ポイント。 ターボフィッシュはオプションを検討するときに頭を悩ませました。後から考えると、今夜もすべてのシリンダーで正確に発砲しているわけではないので、設計上の決定についてコメントすることについてもっと慎重にすべきでした。

とは言うものの、宛先タイプを関数名に焼き付けるのは間違っていると感じます...エレガントではなく、言語の将来の進化に潜在的な負担をかけます。 ターボフィッシュはより良い選択肢のように感じます。

ジェネリックメソッドは、 unsafe fnメソッドを使用したUncheckedFrom / UncheckedInto特性の新しいセットでサポートされ、 From / IntoとTryFrom / TryIntoコレクション。

@bstrieコードが遅くなった人のための1つの代替ソリューションは、組み込み（stdsimdなど）を使用して、基になるハードウェア命令にアクセスすることです。 これにはオプティマイザーの欠点があると以前に主張しました-自動ベクトル化はおそらく苦しみ、LLVMはそれを利用して範囲外の入力にundefを返すことはできません-しかしそれはなしでキャストを行う方法を提供します実行時の余分な作業。 これで十分かどうかはわかりませんが、少なくともそうかもしれないと思われます。

x86命令セットでの変換に関する注意事項：

SSE2は、実際には、提供する変換操作が比較的制限されています。 あなたが持っている：

• 32ビットレジスタを備えたCVTTSS2SIファミリ：単精度浮動小数点数をi32変換します
• 64ビットレジスタを備えたCVTTSS2SIファミリ：単精度浮動小数点数をi64変換します（x86-64のみ）
• CVTTPS2PIファミリ：2つのフロートを2つのi32s変換します

それらのそれぞれには、 f32とf64バリアントがあります（また、切り捨てる代わりに丸めるバリアントもありますが、ここでは役に立ちません）。

ただし、符号なし整数には何もありません。32より小さいサイズには何もありません。また、32ビットx86を使用している場合は、64ビットには何もありません。 後の命令セット拡張はより多くの機能を追加しますが、それらのためにコンパイルする人はほとんどいないようです。

その結果、既存の（「安全でない」）動作は次のようになります。

• u32に変換するために、コンパイラーはi64に変換し、結果の整数を切り捨てます。 （これにより、範囲外の値に対して奇妙な動作が発生しますが、それはUBなので、誰が気にします。）
• 16ビットまたは8ビットに変換するために、コンパイラはi64またはi32に変換し、結果の整数を切り捨てます。
• u64に変換するために、コンパイラーは一連の命令を生成します。 f32からu64の場合、GCCおよびLLVMは次と同等のものを生成します。

fn f32_to_u64(f: f32) -> u64 {
    const CUTOFF: f32 = 0x8000000000000000 as f32; // 2^63 exactly
    if !(f >= CUTOFF) { // less, or NaN
        // just use the signed conversion
        f as i64 as u64
    } else {
        0x8000000000000000u64 + ((f - CUTOFF) as i64 as u64)
    }
}

無関係な面白い事実：「切り捨てよりも変換」コード生成は、スーパーマリオ64で「パラレルユニバース」グリッチを引き起こす原因です。衝突検出コードは、最初にf32座標をi32に変換するMIPS命令で、次にi16に切り捨てます。 したがって、i16には収まるがi32の「ラップ」には収まらない座標。たとえば、座標65536.0に移動すると、0.0の衝突検出が得られます。

とにかく、結論：

• 「0x80000000をテストし、特別なハンドラーを使用する」は、i32およびi64への変換でのみ機能します。
• ただし、u32、u / i16、およびu / i8への変換の場合、「切り捨てられた/符号拡張された出力が元の出力と異なるかどうかをテストする」ことは同等です。 （これにより、元の変換では範囲内であったが最終タイプでは範囲外であった整数と、フロートがNaNであるか、元の変換では範囲外であったことを示す0x8000000000000000の両方の整数がすくい上げられます。）
• しかし、その場合のブランチと大量の追加コードのコストはおそらくやり過ぎです。 分岐を避けられれば大丈夫かもしれません。

• @ActuallyaDeviloperのminss / maxssベースのアプローチはそれほど悪くありません！ 最小限の形、

minss %xmm2, %xmm1
maxss %xmm3, %xmm1
cvttss2si %rax, %xmm1

たった3つの命令（適切なコードサイズとスループット/レイテンシーを持っています）であり、ブランチはありません。

しかしながら：

• pure-Rustバージョンでは、NaNの追加テストが必要です。 32ビット以下への変換の場合、64ビットcvttss2siを使用して結果を切り捨てることにより、組み込み関数を使用して回避できます。 入力がNaNでない場合、最小/最大は整数が切り捨てによって変更されないことを保証します。 入力がNaNの場合、整数は0x8000000000000000であり、0に切り捨てられます。
• 2147483647.0と-2148473648.0をレジスタにロードするコストは含めませんでした。通常はそれぞれメモリから1移動します。
• f32の場合、2147483647.0を正確に表すことができないため、実際には機能しません。別のチェックが必要です。 それは事態をさらに悪化させます。 f64からu / i64についても同様ですが、f64からu / i32まではこの問題はありません。

2つのアプローチの間の妥協案を提案します。

• f32 / f64からu / i16およびu / i8、およびf64からu / i32の場合、上記のように、最小/最大+切り捨てを使用します。例：

    let f = if f > 32767.0 { 32767.0 } else { f };
    let f = if f < -32768.0 { -32768.0 } else { f };
    cvttss2si(f) as i16

（u / i16およびu / i8の場合、元の変換はi32にすることができます。f64からu / i32の場合、i64にする必要があります。）

• f32 / 64からu32の場合、

    let r = cvttss2si64(f) as u32;
    if f >= 4294967296.0 { 4294967295 } else { r }

いくつかの指示であり、ブランチはありません。

    cvttss2si   %xmm0, %rcx
    ucomiss .LCPI0_0(%rip), %xmm0
    movl    $-1, %eax
    cmovbl  %ecx, %eax

• f32 / 64からi64の場合、多分

    let r = cvttss2si64(f);
    if f >= 9223372036854775808. {
        9223372036854775807 
    } else if f != f {
        0
    } else {
        r
    }

これにより、より長い（まだブランチのない）シーケンスが生成されます。

    cvttss2si   %xmm0, %rax
    xorl    %ecx, %ecx
    ucomiss %xmm0, %xmm0
    cmovnpq %rax, %rcx
    ucomiss .LCPI0_0(%rip), %xmm0
    movabsq $9223372036854775807, %rax
    cmovbq  %rcx, %rax

…しかし、 fが小さすぎるかのように、単純なアプローチと比較して少なくとも1つの比較を保存します。これは、0x8000000000000000がすでに正解です（つまり、i64 :: MIN）。

• f32からi32の場合、前と同じことを行うのが望ましいのか、それとも最初にf64に変換してから、より短い最小/最大のことを行うのが望ましいのかわからない。

• u64は、私が考えたくない混乱です。 ：p

ベンチマークの募集がアップしています： https ：

https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231/14で、誰かが画像クレートを使用したJPEGエンコーディングの測定可能で大幅な速度低下を報告しました。 プログラムを最小化して、自己完結型にし、主にスローダウンに関連する部分に焦点を合わせました： https ：

キャストは、f32-> u8（ rgb_to_ycbcr ）とf32-> i32（ encode_rgb 、「量子化」ループ）の比率が等しいことに注意してください。 また、入力がすべて範囲内にあるように見えます。つまり、飽和が実際に発生することはありませんが、f32-> u8の場合、これは、多項式の最小値と最大値を計算し、丸め誤差を考慮することによってのみ確認できます。質問することがたくさんあります。 f32-> i32キャストは明らかにi32の範囲内にありますが、これはself.tablesの要素がゼロ以外であるためです。これは、特に元のプログラムでは、オプティマイザーが表示するのがそれほど簡単ではないためです。 tl; dr：飽和チェックはそのままで、唯一の希望はそれらを高速化することです。

また、LLVM IRをいくつか調べました。文字通り、唯一の違いは、飽和キャストからの比較と選択です。 簡単に見ると、asmには対応する指示があり、もちろん、より多くのライブ値があります（これにより、より多くの流出が発生します）。

@comex CVTTSS2SIを使用すると、f32-> u8およびf32-> i32のキャストをかなり速くできると思いますか？

マイナーアップデート、 rustc 1.28.0-nightly (952f344cd 2018-05-18)時点で、 -Zsaturating-float-castsフラグを使用すると、 https： //github.com/rust-lang/rust/issues/10184#issuecomment-345479698のコードは約20になり

| フラグ| タイミング|
| ------- | -------：|
| -Copt-level = 3 -Ctarget-cpu = native | 325,699 ns / iter（+/- 7,607）|
| -Copt-level = 3 -Ctarget-cpu = native -Zsaturating-float-casts | 386,962 ns / iter（+/- 11,601）
（19％遅い）|
| -コプトレベル= 3 | 331,521 ns / iter（+/- 14,096）|
| -Copt-level = 3 -Zsaturating-float-casts | 413,572 ns / iter（+/- 19,183）
（25％遅い）|

@kennytm LLVM 6が何かを変えることを期待していましたか？ 彼らは、このユースケースに役立つ特定の拡張機能について話し合っていますか？ もしそうなら、チケット番号は何ですか？

@insanitybitそれは...まだ開いているようです...？

ウェルプ、私が何を見ていたかの手がかりはありません。 ありがとう！

@rkruppeは、float
（ドキュメントを変更することにより）？

2018年7月20日4:31 AM、「Colin」 [email protected]は次のように書いています。

ウェルプ、私が何を見ていたかの手がかりはありません。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/10184#issuecomment-406462053 、
またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AApc0v3rJHhZMD7Kv7RC8xkGOiIhkGB1ks5uITMHgaJpZM4BJ45C
。

@nagisaたぶんあなたはf32::from_bits(v: u32) -> f32 （そして同様にf64 ）を考えていますか？ 以前はNaNの正規化を行っていましたが、現在はtransmuteです。

この問題は、数値を概算しようとするas変換に関するものです。

@nagisa float-> float castについて考えているかもしれません。 ＃15536​​とください。

ああ、はい、それはフロートからフロートでした。

金、2018年7月20日には、午前12時24分ロビンKruppeの[email protected]は書きました：

@nagisa https://github.com/nagisa float-> floatを考えているかもしれません
キャスト、＃15536​​https ：//github.com/rust-lang/rust/issues/15536および
rust-lang-nursery / nomicon＃65
https://github.com/rust-lang-nursery/nomicon/pull/65 。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/10184#issuecomment-406542903 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AApc0gA24Hz8ndnYhRXCyacd3HdUSZjYks5uIaHegaJpZM4BJ45C
。

LLVM7リリースノートには次のような記述があります。

浮動小数点キャストの最適化が改善されました。 これにより、オーバーフローしたキャストの未定義の動作に依存しているコードに驚くべき結果が生じる可能性があります。 関数属性 "strict-float-cast-overflow" = "false"を指定すると、最適化を無効にできます。 この属性は、clangオプション-fno-strict-float-cast-overflowによって作成できます。 コードサニタイザーを使用して、影響を受けるパターンを検出できます。 この問題を単独で検出するためのclangオプションは-fsanitize = float-cast-overflowです。

それはこの問題と関係がありますか？

安全でない未定義の振る舞いでない限り、LLVMがキャストのオーバーフローに対して何をするかを気にする必要はありません。 不健全な動作を引き起こさない限り、結果はゴミになる可能性があります。

それはこの問題と関係がありますか？

あんまり。 UBは変更されませんでした。LLVMはそれを悪用することについてさらに積極的になり、実際に影響を受けやすくなりましたが、健全性の問題は変わりません。 特に、新しい属性はUBを削除したり、LLVM7より前に存在していた最適化に影響を与えたりすることはありません。

@rkruppeは好奇心から、この種のhttps://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231/14は十分にうまくいき、実装にはあまり多くのバグがなかったようです。 わずかなパフォーマンスの低下が常に予想されていたようですが、正しくコンパイルすることは価値のあるトレードオフのようです。

これはフィニッシュラインを越えてプッシュされるのを待っているだけですか？ または、他の既知のブロッカーはありますか？

ほとんどの場合、私は他のことに気を取られて忙しいですが、RBG JPEGエンコーディングのx0.82回帰は「わずか」ではなく、飲み込むのにかなり苦い薬のようです（他の種類のワークロードは影響を受けていないようですが） 。 デフォルトでサチュレーションをオンにすることに反対するほど深刻ではありませんが、「サチュレーションよりも高速であるが（安全な）ガベージを生成する可能性のある変換関数も提供する」を試す前に、自分でそれをプッシュすることを躊躇します。 "前に説明したオプション。 私はそれに到達していません、そして明らかに他の誰も持っていないので、これは道端に落ちました。

@rkruppeのアップデートに感謝します。 安全なガベージオプションの実装が実際にあるかどうかは気になりますか？ unsafe fn i32::unchecked_from_f32(...)などを簡単に提供できると想像できますが、それは安全な機能だと思っているようです。 今日のLLVMでそれは可能ですか？

freezeまだありませんが、インラインアセンブリを使用して、floatを整数に変換するためのターゲットアーキテクチャの命令にアクセスすることができます（たとえば、飽和asへのフォールバックを使用）。 これにより一部の最適化が妨げられる可能性がありますが、一部のベンチマークではほとんどの場合回帰を修正するのに十分な場合があります。

この問題のUBを維持する（そして今日のasと同じ方法でコード生成される） unsafe関数は別のオプションですが、魅力的ではありません。 d仕事を成し遂げることができるなら、安全な機能を好む。

また、floatからintへの安全な飽和シーケンスにはます。 今日のLLVMにはこれに特化したものはありませんが、インラインasmソリューションがテーブルにある場合、次のようなことを行うのは難しくありません。

     cvttsd2si %xmm0, %eax   # x86's cvttsd2si returns 0x80000000 on overflow and invalid cases
     cmp $1, %eax            # a compact way to test whether %eax is equal to 0x80000000
     jno ok
     ...  # slow path: check for and handle overflow and invalid cases
ok:

これは、 rustcが現在実行しているものよりも大幅に高速であるはずです。

わかりました、ありがとうございます！ インラインasmソリューションは、他の最適化を過度に阻害するため、デフォルトとして機能しないと考えましたが、自分で試したことはありません。 私は個人的に、いくつかの合理的な振る舞いを定義することによって、この不健全な穴を塞ぐことを望んでいます（まさに今日の飽和キャストのように）。 必要に応じて、今日の高速/不健全な実装を安全でない関数として常に保持できます。また、無限のリソースが与えられた時間の制限内で、デフォルトを大幅に改善したり、他の特殊な変換関数を追加したりすることもできます（範囲外の安全な変換など） UBではなく、単なるガベージビットパターン）

他の人はそのような戦略に反対するでしょうか？ それまでの間、これを修正するほど重要ではないと思いますか？

インラインアセンブリはcvttsd2si （または同様の命令）に耐えられるはずだと思います。特に、インラインasmはメモリにアクセスしたり副作用がなかったりするため、未使用の場合は削除できる不透明なブラックボックスであり、その周りの最適化@ sunfishcodeが飽和を示唆するコードシーケンスにインラインasmを使用することに懐疑的である理由です。飽和のために導入されたチェックは、冗長である場合、今日削除されることがありますが、インラインasmブロックのブランチは削除できます。単純化する。

他の人はそのような戦略に反対するでしょうか？ それまでの間、これを修正するほど重要ではないと思いますか？

私は今飽和状態に切り替えて、おそらく後で代替案を追加することに反対しません、私はそれについてのコンセンサスを鼓舞し、コードが遅くなったユーザーにそれを正当化する必要がある人になりたくありません😅

LLVMでfloatをintキャストに飽和させるための組み込み関数を実装するための作業を開始しました： https ：

それがどこかに行けば、飽和セマンティクスを取得するための比較的オーバーヘッドの少ない方法を提供します。

この未定義の振る舞いをどのように再現しますか？ コメントの例を試しましたが、結果は255 。これは、私には問題ないようです。

println!("{}", 1.04E+17 as u8);

未定義の振る舞いをそのように確実に観察することはできません。期待どおりの動作が得られる場合もありますが、より複雑な状況では機能しなくなります。

要するに、私たちが使用するコード生成エンジン（LLVM）は、これが起こらないと想定することが許可されているため、この想定に依存すると、不良コードが生成される可能性があります。

@ AaronM04再現可能な未定義の動作の例が、本日redditに

fn main() {
    let a = 360.0f32;
    println!("{}", a as u8);

    let a = 360.0f32 as u8;
    println!("{}", a);

    println!("{}", 360.0f32 as u8);
}

（遊び場を参照）

前のコメントを参照し@ AaronM04向けだったと思います。

「ああ、それならそれで十分簡単だ」

• @ pcwalton 、2014

申し訳ありませんが、私はこの6年間の善意の歴史をすべて注意深く読みました。 しかし、真剣に、10のうち6つの長い年!!! もしそれが政治家のフォーラムだったとしたら、この辺りで燃えるような妨害行為が予想されたでしょう。

では、誰かが簡単な言葉で、解決策を探すプロセスが解決策自体よりも興味深いものになる理由を説明できますか？

当初の見た目よりも難しく、LLVMの変更が必要なためです。

わかりましたが、2週目にこのLLVMを作成したのは神ではありませんでした。同じ方向に進むと、この根本的な問題を解決するのにさらに15年かかる可能性があります。

本当に、誰かを傷つけることに注意を払っていません。突然助けてくれるRustインフラストラクチャは初めてですが、このケースについて知ったとき、私はただびっくりしました。

この課題追跡システムは、この問題を解決する方法を議論するためのものであり、明らかなことを述べることはその方向に進展がありません。 したがって、問題の解決を支援したり、貢献する新しい情報が必要な場合は、そうしてください。そうしないと、コメントによって修正が魔法のように表示されることはありません。 :)

これにはLLVMの変更が必要であるという仮定は時期尚早だと思います。

最小限のパフォーマンスコストで言語でそれを行うことができると思います。 それは* *いや破壊変更されますが、それを行うことができ、かつ実行する必要があります。

私の解決策は、floatからintへのキャストをunsafeとして定義し、標準ライブラリにいくつかのヘルパー関数を提供して、 Resultタイプにバインドされた結果を提供することです。

これはセクシーではない修正であり、重大な変更ですが、最終的には、既存のUBを回避するためにすべての開発者が自分でコーディングする必要があります。 これは正しい錆のアプローチです。

@RalfJung 、私にそれを理解させてくれてありがとう。 私は誰かを侮辱したり、生産的なブレインストーミングプロセスに軽蔑的に介入したりするつもりはありませんでした。 さびで新しいので、それは本当です、私ができることはそれほど多くありません。 それにもかかわらず、それは私とおそらく錆び始めようとする他の人たちがその未解決の欠陥についてもっと学び、関連する出力をするのを助けます：もっと深く掘り下げる価値があるか、今のところ何か他のものを選ぶ方が良いですか？ しかし、「私の役に立たないコメント」の削除がはるかに簡単になることはすでに嬉しいです。

スレッドの前半で述べたように、関連するチームがずっと前に同意したように、これは必要なセマンティクスをサポートするようにllvmを修正することにより、ゆっくりとしかし確実に正しい方法で修正されています。

この議論に実際に追加できるものはこれ以上ありません。

https://reviews.llvm.org/D54749

@nikic LLVM側の進捗が停滞しているようですが、可能であれば簡単な更新をお願いします。 ありがとう。

飽和キャストは、ユーザーが健全性を得るために何らかの優先回帰を行うことをいとわない場合、ユーザーがオプトインできるライブラリ関数として実装できますか？ 私はコンパイラの実装を読んでいますが、それは非常に微妙なようです：

https://github.com/rust-lang/rust/blob/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/librustc_codegen_ssa/mir/rvalue.rs#L774 -L901

-Zフラグとは関係なく、飽和のためにLLVM IRを生成する組み込み関数（現在のオープンコード化されたIRまたは将来のllvm.fpto[su]i.sat ）を公開できます。 それはまったく難しいことではありません。

しかし、それが最善の行動かどうか心配です。 （もし？）飽和がasキャストのデフォルトのセマンティクスになると、そのようなAPIは冗長になります。 また、一時的なものであっても、健全性とパフォーマンスのどちらが必要かを自分で選択する必要があることをユーザーに伝えるのは素晴らしいことではないようです。

同時に、現在の状況は明らかにさらに悪化しています。 ライブラリAPIの追加を検討している場合、デフォルトで飽和を有効にし、NaNにUBがあり、範囲外の数値を持つunsafe組み込み関数を提供するように警告することがますます増えていますプレーンなfpto[su]i ）。 それでも基本的に同じ選択肢が提供されますが、デフォルトでは健全性が維持され、新しいAPIは将来冗長になることはないでしょう。

デフォルトでサウンドに切り替えるのは良いことです。 私たちは、最初からではなく、要求に応じて本質的なものを怠惰に提供できると思います。 また、この場合、const evalは飽和も行いますか？ （cc @RalfJung @eddyb @ oli -obk）

私たちがすでに飽和状態にあり、何年にもわたってそうしていることを評価してください。miriの前でさえそう思います（古いllvm::Constantベースのエバリュエーターで変更したことをはっきりと覚えています）。

@rkruppe素晴らしい！ 問題のコードに精通しているので、デフォルトの切り替えを先導しますか？

@rkruppe

飽和のためにLLVMIRを生成する組み込み関数を公開できます

これは、ソースタイプと宛先タイプの組み合わせごとに、10個または12個の個別の組み込み関数である必要がある場合があります。

@Centril

デフォルトでサウンドに切り替えるのは良いことです。 私たちは、最初からではなく、要求に応じて本質的なものを怠惰に提供できると思います。

他のコメントとは異なり、コメントの「本質的な」とは、 asが飽和状態になったときに設定の回帰が少ないものを意味すると思います。

これは、既知の重大な回帰に対処するための良いアプローチではないと思います。 一部のユーザーにとっては、パフォーマンスの低下が実際の問題になる可能性がありますが、アルゴリズムによって入力が常に範囲内にあることが保証されます。 このスレッドにサブスクライブしていない場合は、変更がStableチャネルに到達したときにのみ影響を受けることに気付く可能性があります。 その時点で、リクエストに応じて安全でないAPIをすぐに提供したとしても、6〜12週間スタックする可能性があります。

むしろ、非推奨の警告に対してすでに確立されているパターンに従うことをお勧めします。代替がStableでしばらく利用可能になった後でのみ、Nightlyで切り替えを行ってください。

これは、ソースタイプと宛先タイプの組み合わせごとに、10個または12個の個別の組み込み関数である必要がある場合があります。

いいでしょう、あなたは私を手に入れました、しかし私はそれがどのように関連しているかわかりませんか？ 30の組み込み関数としましょう。それらを追加するのは、まだ簡単です。 しかし実際には、N個の薄いラッパーで使用される単一の汎用組み込み関数を使用する方がさらに簡単です。 「 asサウンドを作成してunsafeキャストAPIを導入する」オプションを選択しても、数値は変わりません。

これは、_既知の_重大な回帰に対処するための良いアプローチではないと思います。 一部のユーザーにとっては、パフォーマンスの低下が実際の問題になる可能性がありますが、アルゴリズムによって入力が常に範囲内にあることが保証されます。 このスレッドにサブスクライブしていない場合は、変更がStableチャネルに到達したときにのみ影響を受けることに気付く可能性があります。 その時点で、リクエストに応じて安全でないAPIをすぐに提供したとしても、6〜12週間スタックする可能性があります。

+1

すべてのリリースチャネルで警告なしを維持するよりも、すべてのリリースチャネルでパフォーマンス回帰のない状態を維持することの方が重要ではないように思われるため、非推奨の警告の手順（交換が安定したら毎晩非推奨にする）が必要かどうかはわかりません。 、しかし、繰り返しになりますが、さらに12週間待つことは、基本的に、この問題がどのくらい続いているかという丸め誤差です。

-Zsaturating-float-castsそのままにしておくこともできます（デフォルトを変更するだけです）。これは、夜間のユーザーがしばらくの間、カンジからオプトアウトできることを意味します。

（はい、組み込み関数の数は単なる実装の詳細であり、何かに賛成または反対する議論を意味するものではありませんでした。）

私はここのコメントのすべてを消化していると主張することはできませんが、私はLLVMは、という印象の下で午前@rkruppe今、右ここUBを排除する「最短経路」を阻止する項目を凍結命令を、持っています

freezeは非常に新しいので、私たち自身のバージョンのLLVMでは利用できないかもしれませんね。 それでも、おそらく2020年の前半に、開発を模索する必要があるように思われますか？

この時点で私たちの希望する道について大まかなコンセンサスを得るために、Tコンパイラ会議での議論に指名します。

freezeは、ここで参照されているすべての理由から、依然として問題がありfreezeは、ランダムなガベージまたは秘密鍵のいずれか悪い方を返すことを期待します。 （私はこれをどこかでオンラインで読んでいて、要約があるのが本当に好きです。：D）

そしてとにかく、ランダムなゴミを返すことでさえ、 asキャストにとってはかなり悪いようです。 unchecked_addと同様に、必要に応じて速度を上げるために高速な操作を行うことは理にかなっていますが、ます。

@SimonSapinは、最初に反対のアプローチを提案しました（デフォルトでは、不健全/「奇妙な」セマンティクスになり、明示的に健全なメソッドを提供します）。 後のコメントから、（適切な移行期間の後の）健全性をデフォルトにすることも合理的/より良いと思うかどうかはわかりませんか？

@pnkfelix

私は、LLVMにフリーズ命令があるという印象を受けています。これは、ここでUBを排除するための「最短パス」をブロックするアイテムでしたね。

いくつかの注意点があります。 最も重要なことは、私たちが気にしているのがUBを取り除くことだけであり、バンドルされたLLVMを更新してfreezeを含める場合でも（いつでも実行できます）、いくつかの古いバージョンをサポートします（瞬間）そして、すべてのユーザーのUBを実際に取り除くには、フォールバックの実装が必要です。

第二に、もちろん、私たちが気にしているのは「UBではない」だけなのかという問題です。 特に、 freeze(fptosi %x)は非常に直感に反する動作をすることをもう一度強調したいと思います。これは非決定論的であり、実行されるたびに異なる結果（ @RalfJungが言ったように機密メモリから取得したものでも）を返す可能性があります。 今はこれについて再び議論したくはありませんが、飽和状態をデフォルトのチェックされていない（安全でないまたはfreeze使用する）変換にするためにもう少し作業を行うかどうかを会議で検討する価値がありますデフォルト以外のオプション。

@RalfJung私の立場では、 asは、入力と出力のタイプに応じてセマンティクス（切り捨て、飽和、丸めなど）が大きく異なる可能性があり、常にそうであるとは限らないため、この問題に関係なく完全に回避するのが最善です。コードを読むと明らかです。 （後者でもfoo as _で推測できます。）したがって、 asが今日（そしておそらくそれ以上）行うケースをカバーする、明示的に名前が付けられたさまざまな変換方法を提案するためのドラフトpre-RFCがあります。 。

asは、 unsafe外部で使用できるため、絶対にUBを含めるべきではないと思います。 ゴミを返すのも良くありません。 しかし、キャストの飽和によって引き起こされるパフォーマンスの低下の既知のケースについては、おそらく何らかの緩和/移行/代替策が必要です。 その移行でこのドラフトRFCをブロックしないために、飽和キャストのライブラリ実装についてのみ質問しました。

@SimonSapin

私の立場は、この問題に関係なく完全に回避するのが最善であるということです。これは、セマンティクス（切り捨て、飽和、丸めなど）が大きく異なる可能性があるためです。

同意しました。 しかし、それはこの問題については実際には役に立ちません。

（また、 asが不要になるように取り組んでいることを嬉しく思います。それを楽しみにしています。：D）

安全でない場所で使用できるので、絶対にUBを持ってはいけないと思います。 ゴミを返すのも良くありません。 しかし、キャストの飽和によって引き起こされるパフォーマンスの低下の既知のケースについては、おそらく何らかの緩和/移行/代替策が必要です。 その移行でこのドラフトRFCをブロックしないために、飽和キャストのライブラリ実装についてのみ質問しました。

したがって、最終的な状態は、float-to-int as飽和することであることに同意しているようです。 それが私たちが目指している最終目標である限り、私はどんな移行計画にも満足しています。

その最終目標は私には良いと思います。

これは、_既知の_重大な回帰に対処するための良いアプローチではないと思います。 一部のユーザーにとっては、パフォーマンスの低下が実際の問題になる可能性がありますが、アルゴリズムによって入力が常に範囲内にあることが保証されます。 このスレッドにサブスクライブしていない場合は、変更がStableチャネルに到達したときにのみ影響を受けることに気付く可能性があります。 その時点で、リクエストに応じて安全でないAPIをすぐに提供したとしても、6〜12週間スタックする可能性があります。

私の見解では、これらのユーザーが6〜12週間、rustcのアップグレードを待つ場合、世界の終わりではありません。どちらの場合も、今後のリリースから何も必要ないか、ライブラリにMSRVの制約がある可能性があります。支持する。

一方、スレッドにサブスクライブしていないユーザーは、パフォーマンスが低下するのと同じように、誤コンパイルが発生する可能性があります。 どちらを優先する必要がありますか？ 私たちは安定性について保証し、安全性についても保証しますが、私の知る限り、パフォーマンスについてはそのような保証はありません（たとえば、RFC 1122はperfについてまったく言及していません）。

むしろ、非推奨の警告に対してすでに確立されているパターンに従うことをお勧めします。代替がStableでしばらく利用可能になった後でのみ、Nightlyで切り替えを行ってください。

非推奨の警告の場合、安定した代替手段が見つかるまで非推奨で待機した結果は、少なくとも私が知る限り、待機期間中の健全性の穴ではありません。 （また、ここでは組み込み関数を提供できますが、一般的な場合、健全性の穴を修正するときに代替案を合理的に提供できない可能性があります。したがって、安定版に代替案を用意することは難しい要件ではないと思います。）

いいでしょう、あなたは私を手に入れました、しかし私はそれがどのように関連しているかわかりませんか？ 30の組み込み関数としましょう。それらを追加するのは、まだ簡単です。 しかし実際には、N個の薄いラッパーで使用される単一の汎用組み込み関数を使用する方がさらに簡単です。 「 asサウンドを作成してunsafeキャストAPIを導入する」オプションを選択しても、数値は変わりません。

その単一の汎用組み込み関数は、それらの12/30固有の単相インスタンス化のためにコンパイラーで個別の実装を必要としませんか？

LLVMはすでにほとんどの作業を行っているため、コンパイラに組み込み関数を追加するのは簡単かもしれませんが、それも完全なコストにはほど遠いです。 さらに、Miri、Craneliftでの実装、および仕様で必要となる最終的な作業があります。 したがって、誰かが必要とするオフチャンスに組み込み関数を追加するべきではないと思います。

しかし、私はより多くの組み込み関数を公開することに反対していませんが、誰かがそれらを必要とする場合は、提案を行い（たとえば、いくつかの詳細な説明を含むPRとして）、いくつかのベンチマーク番号などで追加を正当化する必要があります。

-Zsaturating-float-castsそのままにしておくこともできます（デフォルトを変更するだけです）。これは、夜間のユーザーがしばらくの間、カンジからオプトアウトできることを意味します。

これは私には問題ないように思えますが、すでにこのフラグを使用している人のセマンティクスが不健全になるのを避けるために、フラグの名前を-Zunsaturating-float-castsに変更することをお勧めします。

@Centril

その単一の汎用組み込み関数は、それらの12/30固有の単相インスタンス化のためにコンパイラーで個別の実装を必要としませんか？

いいえ、ほとんどの実装は、送信元と宛先のビット幅をパラメータ化することで共有でき、すでに共有されています。 大文字と小文字を区別する必要があるのはほんの数ビットです。 同じことがmiriの実装にも当てはまり、おそらく他の実装や仕様にも当てはまります。

（編集：明確にするために、この共有は、N個の異なる組み込み関数がある場合でも発生する可能性がありますが、単一の汎用組み込み関数は、組み込み関数ごとに必要なボイラープレートを削減します。）

したがって、誰かが必要とするオフチャンスに組み込み関数を追加するべきではないと思います。

しかし、私はより多くの組み込み関数を公開することに反対していませんが、誰かがそれらを必要とする場合、彼らは提案を行い（たとえば、いくつかの詳細な説明を含むPRとして）、いくつかのベンチマーク番号などで追加を正当化する必要があります。 その間、それが健全性の穴の修正を妨げるべきではないと思います。

すでにいくつかのベンチマーク数値があります。 ずっと前のベンチマークの要求から、キャストが飽和しているx86_64では@nikicが取り組んだLLVM組み込み関数）はそれを根本的に変えるでしょう。 将来について確信するのは難しいですが、私の知識に基づく推測では、そのパフォーマンスを取り戻すための唯一のもっともらしい方法は、 unsafe変換や、 freezeを使用するものなど、範囲チェックなしでコードを生成するものを使用することです。

さて、既存のベンチマークの数値から、前述の組み込み関数に対する積極的な欲求があるようです。 もしそうなら、私は次の行動計画を提案します：

1. 同時に：
   
   
   
   • #[unstable(...)]関数を使用して、毎晩公開される組み込み関数を紹介します。
   
   
   • 削除-Zsaturating-float-castsと紹介-Zunsaturating-float-casts 。
   
   
   • デフォルトを-Zsaturating-float-casts機能に切り替えます。
   
   
2. しばらくすると、組み込み関数が安定します。 少し早送りできます。
3. しばらくして-Zunsaturating-float-casts削除します。

いいですね。 組み込み関数が一部のパブリックAPIの実装の詳細であることを除いて、おそらくf32とf64メソッドです。 それらは次のいずれかである可能性があります。

• ジェネリックトレイトのメソッド（変換の整数戻り値の型のパラメーターを使用）、オプションでプレリュード内
• さまざまな戻り値の型をサポートするための、サポート特性（ str::parseおよびFromStrと同様）を持つ固有のメソッド
• 名前にターゲットタイプが含まれる複数の非ジェネリック固有メソッド

ええ、私はメソッドなどを介して組み込み関数を公開することを意味しました。

名前にターゲットタイプが含まれる複数の非ジェネリック固有メソッド

これは私たちが行う通常のことのように感じます-このオプションに異議はありますか？

でも？ メソッドの名前の一部として（署名の）型の名前がある場合、それはアドホックな「一種の」変換（ Vec::as_sliceや[T]::to_vec ）だと思いVec::as_slice 、または違いがタイプではない一連の変換（ to_ne_bytes 、 to_be_bytes 、 to_le_bytes ）。 しかし、 std::convertの特性の動機の一部は、 u8::to_u16 、 u8::to_u32 、 u8::to_u64などの数十の個別のメソッドを回避すること

私の疑問は、メソッドがunsafe fn必要があることを考えると、これが特性に自然に一般化できるかどうかです。 固有のメソッドを追加する場合は、トレイトの実装などでいつでも委任できます。

安全でない変換の特性を追加するのは奇妙に思えますが、おそらくSimonは、浮動小数点と整数型の組み合わせごとに異なるメソッドが必要になる可能性があるという事実を考えていると思います（例： f32::to_u8_unsaturated 、 f32::to_u16_unsaturatedなど）。

私が完全に無知で読んだことのない長いスレッドに重きを置くのではありませんが、それは望ましいですか、それともu32などに変換されるf32::to_integer_unsaturatedがあれば十分ですか？ 安全でない変換のターゲットタイプに明らかな選択はありますか？

たとえば、i32 / u32にのみ安全でない変換を提供すると、値の範囲が厳密に小さくないすべての整数型が完全に除外されます。これが必要になる場合があります。 小さくすること（JPEGエンコーディングのようにu8まで）も必要になることがよくありますが、より広い整数型に変換し、 as （通常は無料ではありませんが安価です）で切り捨てることでエミュレートできます。

しかし、最大の整数サイズへの変換だけを提供することはできません。 これらは常にネイティブにサポートされているわけではなく（したがって、遅い）、最適化で修正することはできません。後者にはUB（LLVM IR）があるため、「大きいintに変換してから、切り捨てる」を「小さいintに直接変換する」に最適化するのは適切ではありません。 /切り捨て時に元の変換結果がラップアラウンドされた場合の、異なる結果（マシンコードレベル、ほとんどのアーキテクチャ）。

128ビット整数を実用的に除外し、64ビット整数に焦点を合わせても、一般的な32ビットターゲットには依然として悪いことに注意してください。

私はこの会話は初めてですが、プログラミングは初めてです。 飽和変換とNaNのゼロへの変換が妥当なデフォルトの動作であると人々が考える理由について興味があります。 Javaがこれを行うことは理解していますが（ラップアラウンドの方がはるかに一般的ですが）、NaNが実際に正しい変換であると言える整数値はありません。 同様に、たとえば、1000000.0を65535（u16）に変換するのは間違っているようです。 明らかに正しい答えであるu16はありません。 少なくとも、16960に変換する現在の動作よりも優れているとは思いません。これは、少なくともC / C ++、C＃、goなどと共有される動作であり、少なくとも多少驚くことではありません。

オーバーフローチェックとの類似性については色々な方からコメントがあり、賛成です。 また、ゼロによる整数除算にも似ています。 無効な変換は、無効な算術と同じようにパニックになるはずだと思います。 NaN-> 0および1000000.0-> 65535（または16960）に依存することは、整数オーバーフローまたは仮想のn / 0 == 0に依存することと同じようにエラーが発生しやすいように見えます。これはデフォルトでエラーを生成するようなものです。 （リリースビルドでは、整数演算の場合と同様に、錆によってエラーチェックが不要になることがあります。）また、まれに、NaNをゼロに変換したり、浮動小数点が飽和したりする場合は、整数オーバーフローを選択する必要があります。

パフォーマンスに関しては、一般的なパフォーマンスが最も高いのは、単純な変換を実行し、ハードウェアの障害に依存することから来るようです。 たとえば、x86とARMはどちらも、浮動小数点から整数への変換を正しく表現できない場合（NaNと範囲外の場合の両方を含む）にハードウェア例外を発生させます。 このソリューションは、無効な変換を除いてゼロコストです。ただし、デバッグビルドで浮動小数点から小整数型に直接変換する場合（まれなケース）は、比較的安価であるはずです。 （これらの例外をサポートしない理論上のハードウェアでは、ソフトウェアでエミュレートできますが、デバッグビルドでのみエミュレートできます。）ハードウェア例外は、まさに今日のゼロによる整数除算の検出方法であると思います。 LLVMの話をたくさん見たので、ここで制約を受けているかもしれませんが、本質的に無効な変換に対して疑わしい代替動作を提供するために、リリースビルドでもすべての浮動小数点変換でソフトウェアエミュレーションを使用するのは残念です。

@admilazz LLVMでできることには制約があり、現在LLVMは、未定義の動作のリスクなしに浮動小数点数を整数に効率的に変換するメソッドを公開していません。

飽和状態は、言語がasキャストを常に成功するように定義しているため、代わりに演算子をパニックに変更することはできません。

同様に、たとえば、1000000.0を65535（u16）に変換するのは間違っているようです。 明らかに正しい答えであるu16はありません。 少なくとも、16960に変換する現在の動作よりも優れているとは思いません。

それは私には明らかではなかったので、指摘する価値があると思います。16960は、1000000.0を十分な幅の整数に変換し、16個の下位ビットを保持するために切り捨てた結果です。

これは〜このスレッドで以前に提案されたオプションではなく、〜（編集：ここで間違っていた、申し訳ありませんが見つかりませんでした）現在の動作でもありません。 Rustの現在の動作は、範囲外の浮動小数点から整数への変換が未定義の動作であるというものです。 実際には、これはしばしばゴミの価値につながり、原則として、誤コンパイルや脆弱性を引き起こす可能性があります。 このスレッドはそれを修正するためのものです。 以下のプログラムをRust1.39.0で実行すると、毎回異なる値が得られます。

fn main() {
    dbg!(1000000.0 as u16);
}

遊び場。 出力例：

[src/main.rs:2] 1000000.0 as u16 = 49072

個人的には、整数のような切り捨ては彩度よりも良くも悪くもないと思います。どちらも範囲外の値に対して数値的に間違っています。 UBではなく決定論的である限り、間違いのない変換がその場所を占めます。 アルゴリズムから、値が範囲内にあることをすでに知っているか、そのような場合を気にしないかもしれません。

Resultを返すフォールブルコンバージョンAPIも追加する必要があると思いますが、RFC以前のドラフトの作成を完了する必要があります:)

「数学整数に変換してから、ターゲット幅に切り捨てる」または「ラップアラウンド」セマンティクスは、このスレッド（https://github.com/rust-lang/rust/issues/10184#issuecomment-299229143）で以前に提案され

• 私はそれが飽和よりも少し賢明ではないと思います。 飽和は、通常、範囲外の数値に対して適切な結果をもたらしませんが、次のようになります。
  
  
  
  • 数値がわずかに範囲外の場合（たとえば、累積丸め誤差のため）、ラップアラウンドよりも賢明に動作します。 対照的に、ラップアラウンドするキャストは、float計算での軽度の丸め誤差を、整数領域で可能な最大の誤差に増幅する可能性があります。
  
  
  • これはデジタル信号処理である程度一般的に使用されているため、実際に必要なアプリケーションが少なくともいくつかあります。 対照的に、ラップアラウンドセマンティクスの恩恵を受ける単一のアルゴリズムを私は知りません。
  
  
• ラップアラウンドセマンティクスを好む唯一の理由は、ソフトウェアエミュレーションの効率ですが、これは私には証明されていない仮定のようです。 間違っていることが証明されれば幸いですが、一見すると、ラップアラウンドにはALU命令の長いチェーン（および無限大とNaNを個別に処理するためのブランチ）が必要であるため、どちらかが明らかに優れているとは思えません。他よりもパフォーマンス。
• NaNをどうするかという問題は整数への変換にとって醜い問題ですが、飽和は少なくとも無限大のために特別な大文字小文字の区別を必要としません（セマンティクスでもほとんどの実装でも）。 しかし、ラップアラウンドの場合、同等の整数は+/-無限大とは何でしょうか？ JavaScriptはそれが0だと言っており、NaNでasパニックを起こした場合、無限大でもパニックになる可能性があると思いますが、どちらにしても、正常な数値と非正規化数を見るよりもラップアラウンドを高速化するのが難しくなるようです一人で提案するでしょう。

変換の飽和セマンティクスによって回帰されたコードのほとんどは、SIMDを使用した方がよいと思います。 したがって、残念ながら、この変更によって高性能コードの記述が妨げられることはなく（特に、異なるセマンティクスを持つ組み込みが提供されている場合）、一部のプロジェクトをより高速な（移植性が低い場合）実装に向けて動かす可能性さえあります。

もしそうなら、いくつかのわずかなパフォーマンスの低下は、健全性の穴を閉じることを避けるための正当化として使用されるべきではありません。

https://github.com/rust-lang/rust/pull/66841は、値がわかっている場合に備えて、LLVMのfptouiおよびfptosiで変換するunsafe fnメソッドを追加します範囲内にあり、飽和していることは、測定可能なパフォーマンスの低下です。

その後、デフォルトをasに切り替える（そしてオプトアウトするために別の-Zフラグを追加する）のは問題ないと思いますが、それはおそらく正式なLangチームの決定であるはずです。

その後、デフォルトをasに切り替える（そしてオプトアウトするために別の-Zフラグを追加する）のは問題ないと思いますが、それはおそらく正式なLangチームの決定であるはずです。

だから私たち（言語チーム、少なくともそこにいた人々と）はhttps://github.com/rust-lang/lang-team/blob/master/minutes/2019-11-21.mdでこれについて議論しました新しい組み込み関数を追加する+ -Zunsaturated-float-castsを追加することは良い最初のステップです。

その一部として、またはその直後に、必要に応じてFCPを使用して、デフォルトを切り替えるとよいと思います。

新しい組み込み関数とは、 https：//github.com/rust-lang/rust/pull/66841のようなものを意味すると思い

デフォルトを変更せずに-Z unsaturated-float-castsを追加するとはどういう意味ですか？ 「エラー：不明なデバッグオプション」を発行するのではなく、no-opとして受け入れますか？

新しい組み込み関数とは、＃66841のようなものを意味すると思います

うん👍-それを先導してくれてありがとう。

デフォルトを変更せずに-Z unsaturated-float-castsを追加するとはどういう意味ですか？ 「エラー：不明なデバッグオプション」を発行するのではなく、no-opとして受け入れますか？

ええ基本的に。 また、我々は削除-Z saturated-float-castsの賛成で-Z unsaturated-float-castsと直接デフォルトの切り替えが、それは少ないのPRを超える同じ結果につながるはずです。

私は「不飽和」の提案を本当に理解していません。 新しいデフォルトをオプトアウトするためのノブを提供することが目標である場合は、既存のフラグのデフォルトを変更するだけで、それ以上何もしない方が簡単です。 トレードオフ（不健全）についてより明確な新しい名前を選択することが目標である場合、「不飽和」はそれでひどいです—代わりに「安全でない」または「UB」または同様のものを含む名前を提案します怖い言葉、例えば-Z fix-float-cast-ub 。

uncheckedは、API名にいくつかの前例がある用語です。

@admilazz LLVMでできることには制約があり、現在LLVMは、未定義の動作のリスクなしに浮動小数点数を整数に効率的に変換するメソッドを公開していません。

ただし、整数オーバーフローの場合と同様に、デバッグビルドでのみランタイムチェックを追加できると思われます。

ラップアラウンドセマンティクスを好む唯一の理由は、ソフトウェアエミュレーションの効率です。

どちらも間違っているので、ラップアラウンドとサチュレーションのどちらかを選ぶべきではないと思いますが、ラップアラウンドには、少なくともrustに似た多くの言語で使用される方法であるという利点があります：C / C ++、C＃、go、おそらくD、そして確かにより多く、そしてまた錆の現在の振る舞いである（少なくとも時々）。 とはいえ、整数オーバーフローやゼロ除算などの無効な演算の場合と同じように、「無効な変換でのパニック（おそらくデバッグビルドのみ）」が理想的だと思います。

（興味深いことに、私は遊び場で16960を取得しました。しかし、投稿された他の例から、錆が異なる場合があることがわかります...）

飽和状態は、言語が常に成功するキャストとして定義されているため、代わりに演算子をパニックに変更することはできません。

操作の評価対象を変更することは、すでにこれを行っている人々の結果を気にする限り、すでに重大な変更です。 このパニックのない動作も変わる可能性があります。

NaNでパニックになった場合、無限大でもパニックになる可能性があると思いますが、どちらにしても、ラップアラウンドを高速化するのが難しくなるようです。

整数オーバーフローのように、デバッグビルドでのみチェックされる場合は、両方の長所を活用できると思います。変換は正しいことが保証されており（デバッグビルドでは）、ユーザーエラーが検出される可能性が高いため、オプトインできます。必要に応じて、ラップアラウンドやサチュレーションなどの奇妙な動作を行い、パフォーマンスは可能な限り良好です。

また、コマンドラインスイッチを介してこのようなものを制御するのは奇妙に思えます。 それは大きなハンマーです。 確かに、範囲外の変換の望ましい動作はアルゴリズムの詳細に依存するため、変換ごとに制御する必要があります。 f.to_u16_sat（）およびf.to_u16_wrap（）またはオプトインと同様のものをお勧めします。コードのセマンティクスを変更するコマンドラインオプションはありません。 それは、異なるコードを混ぜ合わせて一致させるのを難しくし、それを読んで何かが何をするのか理解することはできません...

また、「無効な場合はパニック」をデフォルトの動作にすることが本当に受け入れられない場合は、それを実装するが、デバッグビルドでのみ有効性チェックを実行する組み込みメソッドがあると便利です。これにより、（広大な）変換が正しいことを確認できます。大多数？）変換後に同じ数を取得することを期待しているが、リリースビルドでペナルティを支払わない場合。

興味深いことに、私は遊び場で16960を取得しました。

これが未定義の振る舞いの仕組みです。プログラムの正確な定式化、正確なコンパイラバージョン、および正確なコンパイルフラグによっては、決定論的な振る舞い、実行ごとに変化するガベージ値、または誤コンパイルが発生する可能性があります。 コンパイラは何でもできます。

ラップアラウンドには、少なくともrustに似た多くの言語で使用される方法であるという利点があります：C / C ++、C＃、go、おそらくD、そして確かにそれ以上、

本当に？ 少なくともCとC ++では、Rustと同じ未定義の動作があります。 これは偶然ではありません。主にCおよびC ++を実装するclang用に構築されたLLVMを使用します。 C＃についてよろしいですか？

C11標準https://port70.net/~nsz/c/c11/n1570.html#6.3.1.4

実際の浮動型の有限値が_Bool以外の整数型に変換されると、小数部分は破棄されます（つまり、値はゼロに向かって切り捨てられます）。 整数部分の値を整数型で表すことができない場合、動作は定義されていません。

整数型の値が符号なし型に変換されるときに実行される残りの演算は、実際の浮動型の値が符号なし型に変換されるときに実行する必要はありません。 したがって、ポータブル実浮動値の範囲は（-1、Utype_MAX + 1）です。

C ++ 17標準http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.7.10

浮動小数点型のprvalueは、整数型のprvalueに変換できます。 変換は切り捨てられます。つまり、小数部分は破棄されます。 切り捨てられた値を宛先タイプで表すことができない場合、動作は未定義です。

C＃リファレンスhttps://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/numeric-conversions

doubleまたはfloat値を整数型に変換すると、この値はゼロに向かって最も近い整数値に丸められます。 結果の整数値が宛先タイプの範囲外である場合、結果はオーバーフローチェックコンテキストに依存します。 チェックされたコンテキストでは、OverflowExceptionがスローされますが、チェックされていないコンテキストでは、結果は宛先タイプの未指定の値になります。

つまり、UBではなく、単なる「不特定の値」です。

@admilazzこれと整数オーバーフローには大きな違いがあります。整数オーバーフローは望ましくありませんが、明確に定義されています。 浮動小数点キャストは未定義の動作です。

あなたが求めているのは、リリースモードでVec境界チェックをオフにするのと似ていますが、それは未定義の動作を可能にするので間違っています。

安全なコードで未定義の動作を許可することは、リリースモードでのみ発生する場合でも、受け入れられません。 したがって、修正はリリースモードとデバッグモードの両方に適用する必要があります。

もちろん、デバッグモードでより制限的な修正を行うことは可能ですが、リリースモードの修正は明確に定義する必要があります。

@admilazzこれと整数オーバーフローには大きな違いがあります。整数オーバーフローは望ましくありませんが、明確に定義されています。 浮動小数点キャストは未定義の動作です。

もちろんですが、このスレッドは動作の定義に関するものです。 Amanieuが上記で参考に参照したC＃仕様のように、「宛先タイプの不特定の値」を生成するものとして定義されている場合、（危険な方法で）未定義ではなくなります。 デバッグビルドではパニックが発生するため、実際のプログラムで整数オーバーフローの明確に定義された性質を簡単に利用することはできません。 同様に、リリースビルドで無効なキャストによって生成された値は、デバッグビルドでパニックになった場合、プログラムが実際にそれを利用できなかったため、予測可能または特に有用である必要はありません。 これにより、実際には最適化の範囲がコンパイラに最大になりますが、飽和などの動作を選択するとコンパイラが制約され、ネイティブの飽和変換命令がないハードウェアでは大幅に遅くなる可能性があります。 （そして、彩度が明らかに正しいわけではありません。）

あなたが求めているのは、リリースモードでVec境界チェックをオフにするのと似ていますが、それは未定義の動作を可能にするので間違っています。 安全なコードで未定義の動作を許可することは受け入れられません...

すべての未定義の動作が似ているわけではありません。 未定義の動作は、何が起こるかを決定するのはコンパイラの実装者次第であることを意味します。 フロートをintにキャストすることによって錆の安全保証に違反する方法がない限り、それは人々が任意のメモリ位置に書き込むことを許可することに似ているとは思いません。 それでも、もちろん、必ずしも予測可能でなくても、安全が保証されるという意味で定義されるべきであることに同意します。

本当に？ 少なくともCとC ++では、Rustと同じ未定義の動作があります... C＃についてよろしいですか？

けっこうだ。 私は彼らのすべての仕様を読んだわけではありません。 さまざまなコンパイラをテストしました。 「私が試したすべてのコンパイラーがこのように実行した」と言うことは、「言語仕様でこのように定義されている」と言うこととは異なります。 しかし、私はとにかくオーバーフローを支持することを主張しているのではなく、それが最も一般的であるように思われることを指摘するだけです。 1）整数オーバーフローから保護するのと同じ理由で、1000000.0が65535または16960になるなどの「間違った」結果から保護する変換を使用することに賛成です。これはバグである可能性が高いため、ユーザーはオプトインする必要があります。 、および2）リリースビルドで最大のパフォーマンスを実現します。

すべての未定義の動作が似ているわけではありません。 未定義の動作は、何が起こるかを決定するのはコンパイラの実装者次第であることを意味します。 フロートをintにキャストすることによって錆の安全保証に違反する方法がない限り、それは人々が任意のメモリ位置に書き込むことを許可することに似ているとは思いません。 それにもかかわらず、もちろん私はそれが定義されるべきであることに同意します：定義されますが、必ずしも予測可能ではありません。

未定義の動作とは、オプティマイザー（CおよびC ++に焦点を当てたLLVM開発者によって提供される）が、それが決して起こらないと自由に想定し、未定義のキャストを通過することによってのみ到達可能なコードのチャンクを削除するなど、その想定に基づいてコードを変換することを意味しますまたは、としてこの例が示すように、割り当てが最初に呼び出さずに呼び出されるコードを呼び出すので、それは未定義の動作になり、それは実際にはなかったにもかかわらず、と呼ばれていなければならないと仮定。

さまざまな最適化パスを作成しても危険な緊急動作が発生しないことを証明するのが合理的で

未定義の振る舞いはすべて、それに基づいて似ていると私は主張します。

さまざまな最適化パスを作成しても危険な緊急動作が発生しないことを証明するのが合理的であったとしても、LLVM開発者はそれを維持するための意識的な努力をしません。

LLVMがこのように錆の設計に影響を与えるのは残念ですが、LLVM命令リファレンスの一部を読んだだけで、上記の「フリーズ」操作について言及しています（「...もう1つは、LLVMがフリーズを追加するのを待つことですコンセプト… "）これは、LLVMレベルでの未定義の動作を防ぎます。 錆は古いバージョンのLLVMに結びついていますか？ そうでない場合は、それを使用できます。 ただし、彼らのドキュメントは正確な動作については明確ではありません。

引数がundefまたはpoisonの場合、「freeze」は任意ですが固定されたタイプ「ty」の値を返します。 それ以外の場合、この命令はノーオペレーションであり、入力引数を返します。 同じ「freeze」命令によって返される値のすべての使用は、常に同じ値を監視することが保証されていますが、異なる「freeze」命令は異なる値を生成する可能性があります。

「固定値」または「同じ「フリーズ」命令」が何を意味するのかわかりません。 理想的には、no-opにコンパイルされ、予測できない整数が返されると思いますが、おそらく何か高価なことをする可能性があるようです。 誰かがこのフリーズ操作を試しましたか？

さて、LLVMがこのように錆の設計に影響を与えるのは残念です

LLVM開発者がオプティマイザーを作成するだけではありません。 それは、たとえrustc開発者がオプティマイザーを書いたとしても、オプティマイザーを連鎖させるという新たな特性のために、不明確でいちゃつくことは本質的に巨大なフットガンであるということです。 問題の丸めが最適化パスの連鎖によって構築された緊急の動作である場合、人間の脳は単に「丸め誤差の潜在的な大きさを直感的に理解する」ようには進化しませんでした。

私はそこであなたに反対するつもりはありません。 :-)このLLVMの「フリーズ」命令が、この未定義の動作を回避するためのゼロコストの方法を提供することを願っています。

それは上で議論され、結論は、キャストしてからフリーズすることは定義された振る舞いですが、それはまったく合理的な振る舞いではないということでした。 リリースモードでは、このようなキャストは、（完全に安全なコードで）範囲外の入力に対して任意の結果を返します。 これは、 asように無邪気に見えるものには適したセマンティクスではありません。

IMOのようなセマンティクスは、私たちがむしろ避けたい悪い言語設計になります。

私の立場では、 asは、入力と出力のタイプに応じてセマンティクス（切り捨て、飽和、丸めなど）が大きく異なる可能性があるため、この問題に関係なく完全に回避するのが最善です。コードを読む。 （後者でもfoo as _で推測できます。）したがって、 asが今日（そしておそらくそれ以上）行うケースをカバーする、明示的に名前が付けられたさまざまな変換方法を提案するためのドラフトpre-RFCがあります。 。

そのドラフトを完成させました！ https://internals.rust-lang.org/t/pre-rfc-add-explicitly-named-numeric-conversion-apis/11395

フィードバックは大歓迎ですが、ここではなく内部スレッドでフィードバックしてください。

リリースモードでは、このようなキャストは、（完全に安全なコードで）範囲外の入力に対して任意の結果を返します。 これは、見た目が無邪気なものにとっては良いセマンティクスではありません。

繰り返して申し訳ありませんが、これと同じ議論が整数オーバーフローにも当てはまると思います。 いくつかの数値を乗算して結果がオーバーフローすると、実行しようとした計算がほぼ確実に無効になる非常に間違った結果が得られますが、デバッグビルドでパニックが発生するため、バグが検出される可能性があります。 非常に間違った結果をもたらす数値変換も、ユーザーのコードのバグを表す可能性が非常に高いため、パニックになるはずです。 （典型的な浮動小数点の不正確さのケースはすでに処理されています。計算で65535.3が生成された場合、それをu16に変換することはすでに有効です。範囲外の変換を取得するには、通常、コードにバグが必要です。バグ修正できるように通知したい。）

無効な変換に対して任意であるが定義された結果を提供するリリースビルドの機能により、最大のパフォーマンスも可能になります。これは、数値変換と同じくらい基本的なものにとって重要であると私は考えています。 常に飽和すると、パフォーマンスに大きな影響があり、バグが隠され、予期せずそれに遭遇して正しい結果が得られる計算を行うことはめったにありません。

繰り返して申し訳ありませんが、これと同じ議論が整数オーバーフローにも当てはまると思います。 いくつかの数値を乗算して結果がオーバーフローすると、実行しようとしていた計算がほぼ確実に無効になる、非常に間違った結果が得られます。

しかし、私たちは乗算について話しているのではなく、キャストについて話しているのです。 はい、同じことが整数オーバーフローにも当てはまります。intからintへのキャストは、オーバーフローしてもパニックになることはありません。 これは、 asは、設計上、デバッグビルドでもパニックにならないためです。 安全でないコードの正確性と安全性は、パニックにならない特定の操作に依存する可能性があるため、浮動小数点キャストでこれから逸脱することは、せいぜい驚くべきことであり、最悪の場合は危険です。

asの設計に欠陥があると主張したい場合は、適切な変換が常に可能であるとは限らないタイプ間で確実に変換できるため、ほとんどの人が同意すると思います。 しかし、それはこのスレッドの範囲外です。これは、 asキャストの既存のフレームワーク内でfloatからintへの変換を修正することに関するものです。 これらは間違いのないものでなければならず、デバッグビルドであってもパニックにならないようにする必要があります。 したがって、float-to-intキャストの合理的な（ freeze ）非パニックセマンティクスを提案するか、パニックを許可するためのas再設計に関する新しい議論を開始してみてください。キャストが不可逆である場合（およびintからintへのキャストとfloatからintへのキャストで一貫してそうします）-しかし、後者はこの問題ではトピックから外れているので、新しいスレッドを開いてください（RFC以前のスタイル）そのために。

どのようにして私たちは実装することによって開始freeze UBを修正するために、今の意味を、我々は選択した任意の意味はとの後方互換性になりますので、その後、私たちは実際に何をしたいのセマンティクスに同意する世界ではすべての時間を持つことができますfreezeセマンティクス。

freezeセマンティクスを_now_実装してUBを修正することから始めて、選択したセマンティクスはfreezeと下位互換性があるため、世界中で実際に必要なセマンティクスについて合意することができます。

1. パニックはフリーズとの下位互換性がないため、少なくともパニックを伴うすべての提案を拒否する必要があります。 UBからパニックへの移行は、明らかに互換性がありませんが、上記で説明したように、 asパニックにしない理由は他にもいくつかあります。
2. 前に書いたように、
   >いくつかの古いバージョン（現時点ではLLVM 6に戻る）をサポートしており、すべてのユーザーのUBを実際に取り除くには、フォールバックの実装が必要です。

@RalfJungに同意しasキャストだけをパニックにすることは非常に望ましくありませんが、 @ admilazzが行ったこの点は明らかに正しいとは思いません。

（典型的な浮動小数点の不正確さのケースはすでに処理されています。計算で65535.3が生成された場合、それをu16に変換することはすでに有効です。範囲外の変換を取得するには、通常、コードにバグが必要です。バグ修正できるように通知したい。）

f32-> u16の場合、丸め誤差だけでu16の範囲から外れるには、非常に大きな丸め誤差が必要になる場合がありますが、f32から32ビット整数への変換の場合はそれほど明白ではありません。 i32::MAXはf32で正確に表現できません。最も近い表現可能な数は、 i32::MAXから47オフです。 したがって、数学的に最大i32::MAX数値になるはずの計算がある場合、ゼロから1 ULP以上離れたエラーは、範囲外になります。 また、低精度の浮動小数点数（IEEE 754 binary16、または非標準のbfloat16）を検討すると、さらに悪化します。

掛け算については話していませんが、キャストについて話しているのです

浮動小数点から整数への変換は、乗算とほぼ同じコンテキストで使用されます。数値計算です。整数オーバーフローの動作と並行して役立つと思います。

そして、はい、同じことが整数オーバーフローにも当てはまります。intからintへのキャストは、オーバーフローしてもパニックになることはありません...浮動小数点キャストでこれから逸脱することは、安全でないコードの正確性と安全性として、せいぜい驚くべきことであり、最悪の場合危険です。パニックにならない特定の操作に依存する可能性があります。

ここでの矛盾は一般的な慣行によって正当化され、それほど驚くことではないと私は主張します。 シフト、マスク、およびキャストを使用して整数を切り捨てて切り刻む-ビット単位のANDとサイズ変更の形式としてキャストを効果的に使用する-は非常に一般的であり、システムプログラミングで長い歴史があります。 それは私が少なくとも週に数回行うことです。 しかし、過去30年以上にわたって、NaN、Infinity、または範囲外の浮動小数点値を整数に変換することで妥当な結果が得られると期待していたことを思い出せません。 （私が思い出すことができるすべてのインスタンスは、値を生成する計算のバグでした。）したがって、整数->整数キャストと浮動小数点->整数キャストの場合を同じように扱う必要はないと思います。 とはいえ、すでにいくつかの決定が確定していることは理解できます。

お願いします…floatからintへのキャストのための合理的な（フリーズを含まない）、パニックにならないセマンティクスを提案してください

さて、私の提案は次のとおりです。

1. セマンティクスに大幅な変更を加えるグローバルコンパイルスイッチは使用しないでください。 （-Zsaturating-float-castsはコマンドラインパラメーターなどであると思います。）たとえば、飽和動作に依存するコードは、それなしでコンパイルすると壊れます。 おそらく、異なる期待を持つコードを同じプロジェクトに混在させることはできませんでした。 計算で目的のセマンティクスを指定するためのローカルな方法があるはずです。おそらくこのRFC以前のようなものです。
2. キャストから予想されるように、 asキャストがデフォルトで最大のパフォーマンスを持つようにします。
   
   
   
   • これは、サポートしているLLVMバージョンではフリーズし、サポートしていないLLVMバージョンでは他の変換セマンティクス（切り捨て、飽和など）を介して行う必要があると思います。 「フリーズは機密メモリから値をリークする可能性がある」という主張は純粋に架空のものだと思います。 （または、 y = freeze(fptosi(x))がy変更せずにそのままにして、初期化されていないメモリをリークする場合は、最初にyクリアすることで修正できます。）
   
   
   • asがデフォルトで比較的遅い場合（たとえば、飽和しているため）、最大のパフォーマンスを得る方法を提供します（たとえば、フリーズを使用する方法-必要に応じて安全ではない-）。
   
   

1. セマンティクスに大幅な変更を加えるグローバルコンパイルスイッチは使用しないでください。 （-Zsaturating-float-castsはコマンドラインパラメーターなどであると思います。）

明確にするために、私は誰もが反対するとは思わない。 このフラグは、ライブラリが更新されてパフォーマンスの低下を修正しているときに、パフォーマンスの低下をより簡単に測定して回避するための短期的なツールとしてのみ提案されました。

f32-> u16の場合、丸め誤差だけでu16の範囲から外れるには、非常に大きな丸め誤差が必要になる場合がありますが、f32から32ビット整数への変換の場合はそれほど明白ではありません。 i32 :: MAXはf32で正確に表現できません。最も近い表現可能な数は、i32 :: MAXから47オフです。 したがって、数学的にi32 :: MAXまでの数値になるはずの計算がある場合、ゼロから1ULP以上離れたエラーは範囲外になります。

これは少し話題から外れていますが、2 ^ 31-1までのf32を数学的に生成することになっているこの架空のアルゴリズムがあるとします（ただし、丸め誤差が原因である場合を除いて、2 ^ 31以上を生成するべきではありません）。 すでに欠陥があるようです。

1. 最も近い表現可能なi32は実際にはi32 :: MAXより127低いと思います。したがって、浮動小数点の不正確さがない完全な世界でも、2 ^ 31-1までの値を生成すると予想されるアルゴリズムは、実際には（合法的な）しか生成できません。 ）2 ^ 31-128までの値。 おそらくそれはすでにバグです。 2 ^ 31-1から測定された誤差について、その数値を表すことができない場合に説明するのが理にかなっているのかわかりません。 範囲外に出るには、（丸めを考慮して）最も近い表現可能な数から64だけ離れている必要があります。 確かに、2 ^ 32に近い場合、それはそれほどパーセンテージではありません。
2. 最も近い表現可能な値が128離れている場合、1離れている値（つまり、2 ^ 31-1であるが2 ^ 31ではない）の識別を期待するべきではありません。 さらに、i32の3.5％のみがf32として表現できます（およびu32の2％未満）。 f32でそのような精度を持ちながら、そのような範囲を取得することはできません。 アルゴリズムは、ジョブに間違ったツールを使用しているように聞こえます。

あなたが説明することを実行する実用的なアルゴリズムは、何らかの形で整数に密接に結びついていると思います。 たとえば、ランダムなi32をf32に変換して元に戻す場合、i32 :: MAX-64を超えると失敗する可能性があります。 しかし、それはあなたの精度をひどく低下させます、そして私はあなたがなぜそのようなことをするのか分かりません。 i32の全範囲を出力するほとんどすべてのi32-> f32-> i32計算は、整数演算でより速く、より正確に表現できます。そうでない場合は、f64があります。

とにかく、範囲外の変換を実行するアルゴリズムが飽和によって修正されるケースを見つけることは可能だと確信していますが、それらはまれだと思います-それらに対応するためにすべての変換を遅くするべきではないほどまれです。 そして、そのようなアルゴリズムはおそらくまだ欠陥があり、修正する必要があると私は主張します。 また、アルゴリズムを修正できない場合は、範囲外の可能性のある変換の前に、常に境界チェックを実行できます（または飽和変換関数を呼び出します）。 そうすれば、結果を制限する費用は必要な場合にのみ支払われます。

PSみんなに感謝祭を遅らせました。

明確にするために、私は誰もが反対するとは思わない。 このフラグは、短期的なツールとしてのみ提案されました...

私は主に、-Zsaturated-float-castsを-Zunsaturated-float-castsに置き換える提案について言及していました。 飽和がデフォルトになったとしても、-Zunsaturated-float-castsのようなフラグは互換性に悪いように見えますが、それが一時的なものでもある場合は、大丈夫です。気にしないでください。 :-)

とにかく、私がこの問題について十分に言ったことを誰もが望んでいると確信しています-私も含めて。 Rustチームは伝統的に、パフォーマンスと安全性の間で人々が自分で選択できるように、物事を行うための複数の方法を提供しようとしてきたことを知っています。 私は私の見解を共有し、皆さんが最終的に良い解決策を思い付くと信じています。 気を付けて！

-Zunsaturated-float-castsは一時的にしか存在せず、ある時点で削除されると思いました。 少なくとも、 -Cではなく-Zオプション（Nightlyでのみ利用可能）であることを示唆しています。

その価値については、彩度とUBだけが選択肢ではありません。 もう1つの可能性は、LLVMを変更して、CPUのネイティブオーバーフロー動作を使用するfptosiバリアントを追加することです。つまり、オーバーフロー時の動作はアーキテクチャ間で移植できませんが、特定のアーキテクチャで明確に定義されます（たとえば、x86で0x80000000を返す）、ポイズンや初期化されていないメモリを返すことはありません。 デフォルトが飽和状態になったとしても、それをオプションとして持つとよいでしょう。 結局のところ、飽和キャストにはデフォルトの動作ではないアーキテクチャに固有のオーバーヘッドがありますが、「CPUが行うことを実行する」には、特定のコンパイラの最適化が妨げられる場合にのみオーバーヘッドがあります。 よくわかりませんが、floatからintへのオーバーフローをUBとして扱うことで有効になる最適化はニッチであり、ほとんどのコードには適用できないと思います。

とはいえ、1つの問題は、オーバーフロー時に異なる値を返す複数のfloat-to-int命令がアーキテクチャにある場合です。 この場合、コンパイラがどちらかを選択すると、観察可能な動作に影響します。これ自体は問題ではありませんが、単一のfptosiが複製され、2つのコピーの動作が異なる場合は1になる可能性があります。 しかし、この種の相違が実際に人気のあるアーキテクチャに存在するかどうかはわかりません。 また、同じ問題が、浮動小数点の縮小を含む他の浮動小数点の最適化にも当てはまります...

const fn （miri）は、Rust 1.26以降、飽和キャスト動作をすでに選択しています（CTFEとRTFEの結果を一貫させたいと仮定）（1.26より前では、オーバーフローしたコンパイル時キャストは0を返します）

const fn g(a: f32) -> i32 {
    a as i32
}

const Q: i32 = g(1e+12);

fn main() {
    println!("{}", Q); // always 2147483647
    println!("{}", g(1e+12)); // unspecified value, but always 2147483647 in miri
}

Miri / CTFEは、apfloatのto_u128 / to_i128メソッドを使用して変換を行います。 しかし、これが安定した保証であるかどうかはわかりません。特に、以前に変更されたように見えることを考えると（Miriでそのようなものを実装するときに気づいていませんでした）。

これは、最終的に選択するcodegenに合わせて調整できると思います。 しかし、LLVMのapfloat（Rustバージョンが直接ポートである）が飽和を使用しているという事実は、これが何らかの「合理的なデフォルト」であることを示す良い指標です。

観察可能な動作の1つの解決策は、コンパイラーのビルド時に使用可能なメソッドの1つ、または結果のバイナリーをランダムに選択することです。
次に、特定の動作を必要とするユーザー向けにa.saturating_cast::<i32>()ような関数を用意します。

@ dns2utf8

「ランダムに」という言葉は、再現可能なビルドを取得するための努力に反するものであり、コンパイラバージョン内で予測可能である場合、誰かがそれを変更しないことに依存することを決定することを知っています。

@comexが説明したIMO（このスレッドIIRCにとって目新しいものではなく、古いものはすべて新しいものです）これは、飽和を望まない場合の次善のオプションです。 それをテストするためにLLVMの変更さえ必要ないことに注意してください。インラインasmを使用できます（そのような命令が存在するアーキテクチャーで）。

とはいえ、1つの問題は、オーバーフロー時に異なる値を返す複数のfloat-to-int命令がアーキテクチャにある場合です。 この場合、コンパイラがどちらかを選択すると、観察可能な動作に影響します。これ自体は問題ではありませんが、単一のfptosiが複製され、2つのコピーの動作が異なる場合は1になる可能性があります。

IMOのような非決定論は、 freezeと比較してほとんどすべての実用的な利点を放棄します。 これを行う場合、決定論と、プログラムが意味のあるときに命令の動作に実際に依存できるようにするために、アーキテクチャごとに1つの命令を選択してそれに固執する必要があります。 一部のアーキテクチャでこれが不可能な場合は、ソフトウェアの実装にフォールバックすることができます（ただし、あなたが言うように、これは完全に架空のものです）。

これは、この決定をLLVMに委任せず、代わりにインラインasmを使用して操作を実装する場合に最も簡単です。 ちなみに、LLVMを変更して新しい組み込み関数を追加し、すべてのバックエンドでそれらを下げるよりもはるかに簡単です。

@rkruppe

[...]ちなみに、LLVMを変更して新しい組み込み関数を追加し、すべてのバックエンドでそれらを下げるよりもはるかに簡単です。

さらに、LLVMは、ターゲットに依存するセマンティクスを持つ組み込み関数に完全に満足しているわけではありません。

ただし、キャストを適切に定義する場合は、キャストの動作を定義する必要があります。 「何か速いことをする」というのは実際には定義ではなく、ターゲットに依存しない構造にターゲットに依存する動作を与えるべきだとは思いません。

https://groups.google.com/forum/m/#!msg/llvm -dev / cgDFaBmCnDQ / CZAIMj4IBAA

＃10184をT-langのみとして再タグ付けします。解決すべき問題には、 float as int意味に関するセマンティックな選択があると思います。

（つまり、パニックセマンティクスを許可するかどうか、 freezeベースの仕様不足を許可するかどうかなど）

これらは、少なくとも最初の議論であるIMOについては、Tコンパイラではなく、T-langチームを対象とした質問です。

この問題が発生しただけで、再コンパイルしなくても_実行間で再現できない_結果が生成されます。 このような場合、 as演算子はメモリからガベージをフェッチするようです。

「floatasint」にasを使用することを完全に禁止し、代わりに特定の丸め方法に依存することをお勧めします。 理由： asは、他のタイプでは損失がありません。

理由：他のタイプでは損失がないように。

それは...ですか？

Rust Bookに基づいて、特定の場合（つまり、タイプYに対してFrom<X>が定義されている場合）にのみロスレスであると想定する場合があります。つまり、 u8をu32キャストできます。 Fromを使用しますが、その逆は使用しません。

「損失がない」とは、収まるほど小さい値をキャストすることを意味します。 例： 1_u64 as u8は損失がないため、 u8 as u64 as u8は損失がありません。 フロートの場合、 20000000000000000000000000000_u128 as f32は損失がないのに対し、 20000001_u32 as f32は損失がないため、「適合」の簡単な定義はありません。したがって、 float as intもint as floatも損失がありません。

ただし、 256u64 as u8は損失があります。

しかし、 <anything>_u8 as u64 as u8はそうではありません。

喪失感は正常であり、ギプスで予想されるものであり、問​​題ではないと思います。 キャストを使用した整数の切り捨て（例： u32 as u8 ）は、私が知っているすべてのCのような言語で一貫している、よく理解されている意味を持つ一般的な操作です（少なくとも、2の補数の整数表現を使用するアーキテクチャでは基本的に最近はそれらすべてです）。 有効な浮動小数点変換（つまり、積分部分が宛先に適合する場合）にも、十分に理解され、合意されたセマンティクスがあります。 1.6 as u32は不可逆ですが、私が知っているすべてのCに似た言語は、結果が1になるはずであることに同意しています。 -キャストする言語のように、「自分が何をしているのか知っている」種類の演算子である高性能でなければなりません。

したがって、無効な浮動小数点変換と同じように問題があると考える必要はないと思います。Cのような言語やハードウェアで合意されたセマンティクスがないためです（ただし、通常はエラー状態になります）またはハードウェアの例外）、ほとんどの場合（私の経験では）バグを示しているため、通常、正しいコードには存在しません。

この問題が発生しただけで、再コンパイルしなくても実行間で再現できない結果が生成されます。 このような場合、 as演算子はメモリからガベージをフェッチするようです。

個人的には、変換が無効な場合にのみ発生し、ガベージ値を生成する以外に副作用がない限り、問題ないと思います。 コードの一部で無効な変換が本当に必要な場合は、必要と思われるセマンティクスを使用して、無効なケースを自分で処理できます。

ガベージ値を生成する以外に副作用はありません

副作用は、ガベージ値がメモリのどこかで発生し、いくつかの（おそらく機密性の高い）データを明らかにすることです。 float自体からのみ計算された「ランダム」値を返すことは問題ありませんが、現在の動作はそうではありません。

有効な浮動小数点変換（つまり、積分部分が宛先に適合する場合）にも、十分に理解され、合意されたセマンティクスがあります。

明示的なtrunc() 、 round() 、 floor()またはceil()伴わないfloatからintへの変換のユースケースはありますか？ asの現在の丸め戦略は「未定義」であり、 asは丸められていない数値にはほとんど使用できません。 ほとんどの場合、 x as u32を書いている人は、実際にはx.round() as u32望んでいると思います。

喪失感は正常であり、ギプスで予想されるものであり、問​​題ではないと思います。

私は同意しますが、損失が簡単に予測できる場合に限ります。 整数の場合、不可逆変換の条件は明らかです。 フロートの場合、それらはあいまいです。 非常に大きな数の場合は損失がありませんが、小さい数の場合は丸くても損失があります。 私の個人的な好みは、誤って不可逆変換を導入することを避けるために、不可逆変換と可逆変換の2つの異なる演算子を使用することですが、損失があるかどうかを判断できる場合は、1つの演算子だけでも問題ありません。

副作用は、ガベージ値がメモリのどこかで発生し、いくつかの（おそらく機密性の高い）データを明らかにすることです。

宛先を変更せずにそのままにしておくことを期待しますが、それが本当に問題である場合は、最初にゼロにすることができます。

明示的なtrunc（）、round（）、floor（）、またはceil（）を伴わないfloatからintへの変換のユースケースはありますか？ asの現在の丸め戦略は「未定義」であり、丸められていない数値にはほとんど使用できません。

丸め戦略が本当に定義されていない場合、それは私にとって驚きです。すでに整数を指定していない限り、演算子はほとんど役に立たないことに同意します。 ゼロに向かって切り捨てられると思います。

ほとんどの場合、 x as u32を書いている人は、実際にはx.round() as u32望んでいると思います。

ドメインにもよると思いますが、 x.trunc() as u32もかなり一般的に望まれていると思います。

私は同意しますが、損失が簡単に予測できる場合に限ります。

私は間違いなく同意します。 たとえば、 1.6 as u32が1になるか2になるかは未定義ではありません。

https://doc.rust-lang.org/nightly/reference/expressions/operator-expr.html#type -cast-expressions

フロートから整数にキャストすると、フロートはゼロに向かって丸められます
注：現在、丸められた値をターゲットの整数型で表すことができない場合、これにより未定義の動作が発生します。 これには、InfとNaNが含まれます。 これはバグであり、修正される予定です。

メモはここにリンクしています。

「適合する」値の丸めは明確に定義されていますが、それはこの問題の目的ではありません。 このスレッドはすでに長いので、すでに確立され文書化されている事実についての接線を推測することにそれを取り入れないのは良いことです。 ありがとう。

決定する必要があるのは、次の場合にf as $Intを定義する方法です。

• f.trunc() > $Int::MAX （正の無限大を含む）
• f.trunc() < $Int::MIN （負の無限大を含む）
• f.is_nan()

Nightlyで-Z saturating-castsコンパイラフラグを使用してすでに実装され利用可能なオプションの1つは、それぞれを返すように定義することです： $Int::MAX 、 $Int::MIN 、およびゼロ。 ただし、他の動作を選択することは可能です。

私の見解では、動作は間違いなく決定論的であり、（たとえばパニックではなく）整数値を返す必要がありますが、正確な値はそれほど重要ではなく、これらのケースを気にするユーザーは、私が個別に提案している変換方法を使用する必要があります追加： https ：

ドメインにもよると思いますが、 x.trunc() as u32もかなり一般的に望まれていると思います。

正しい。 一般に、 x.anything() as u32 、おそらくround()ですが、 trunc() 、 floor() 、 ceil()ます。 具体的な丸め手順を指定せずにx as u32だけで、間違いである可能性が高くなります。

私の見解では、動作は確実に決定論的であり、（たとえばパニックではなく）整数値を返す必要がありますが、正確な値はそれほど重要ではありません

「未定義」の値でも、フロート自体に依存せず、最も重要なこととして、無関係なレジスタとメモリの内容を公開しない限り、個人的には問題ありません。

Nightlyで-Z saturating-castsコンパイラフラグを使用してすでに実装され利用可能なオプションの1つは、それぞれを返すように定義することです： $Int::MAX 、 $Int::MIN 、およびゼロ。 ただし、他の動作を選択することは可能です。

f.trunc() > $Int::MAXとf.trunc() < $Int::MINで期待される動作は、浮動小数点数の虚数が無限サイズの整数に変換され、その最下位ビットが返される場合と同じです（整数型の変換のように）。 技術的には、これは指数に応じて左にシフトされた有意のビットになります（正の数の場合、負の数は2の補数に従って反転する必要があります）。

したがって、たとえば、非常に大きな数が0に変換されることを期待します。

無限大とNaNが何に変換されるかを定義するのは難しい/より恣意的であるように思われます。

WebAssemblyは、次のセマンティクスで飽和キャストを安定させました。

https://github.com/WebAssembly/nontrapping-float-to-int-conversions/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md#design

@CryZeだから、私がそれを正しく読んだら、それは-Z saturating-casts （そしてMiriがすでに実装しているもの）と一致しますか？

@RalfJungその通りです。

素晴らしいです。https：//github.com/WebAssembly/testsuite/blob/master/conversions.wast （トラップを指定された結果に置き換えて）をMiriのテストスイートにコピーし

@RalfJung最新バージョンのconversions.wastに更新してください。これは、新しい飽和変換演算子のテストを含むように更新されたばかりです。 新しい演算子の名前には「_sat」が含まれており、トラップがないため、何も置き換える必要はありません。

@sunfishcode更新してくれてありがとう！ とにかくテストをRustに変換する必要があるので、まだ多くのものを置き換える必要があります。 ;）

_satテストは、テストされる値に関して何か違いがありますか？ （編集：値が同じであるというコメントがあります。）Rustの飽和キャストについては、これらの値の多くを取得してhttps://github.com/rust-lang/miri/pull/1321に追加しました

UB組み込みの場合、wasm側のトラップは、Miriでのコンパイル失敗テストになるはずです。

入力値はすべて同じですが、唯一の違いは、 _sat演算子が、トラップ演算子がトラップを予期している入力で出力値を期待していることです。

Miri（したがってRust CTFEエンジン）のテストがhttps://github.com/rust-lang/miri/pull/1321に追加されましたrustc -Zmir-opt-level=0 -Zsaturating-float-castsもそのファイルのテストに合格することをローカルで確認しました。
また、Miriにチェックされていない組み込み関数も実装しました。https：//github.com/rust-lang/miri/pull/1325を参照して

https://github.com/rust-lang/rust/pull/71269#issuecomment -615537137を投稿しました

このスレッドの長さを考えると、コメントの内容を見逃していると思われる場合は、PRにコメントを送るか、マイナーな場合は、ZulipまたはDiscord（simulacrum）で気軽にpingしてください。 PRスレッドでの不要なノイズを避けるために問題を修正します。

言語チームの誰かがすぐにそのPRでFCP提案を開始し、それをマージするとこの問題が自動的に解決されることを期待しています:)

チェックされたコンバージョンの計画はありますか？ fn i32::checked_from(f64) -> Result<i32, DoesntFit>ようなもの？

i32::checked_from(4.5)何を返すかを検討する必要があります。