Rust: LLVMループの最適化により、安全なプログラムがクラッシュする可能性があります

最適化されたコードのLLVMIRは

; Function Attrs: noreturn nounwind readnone uwtable
define internal void @_ZN4main20h5ec738167109b800UaaE() unnamed_addr #0 {
entry-block:
  unreachable
}

この種の最適化は、通常は無人のタイプに当てはまるはずの主な仮定を破ります。そのタイプの値を持つことは不可能であるはずです。
rust-lang / rfcs＃1216は、Rustでそのようなタイプを明示的に処理することを提案しています。 LLVMがそれらを処理する必要がないことを保証し、必要に応じて発散を確実にするために適切なコードを挿入するのに効果的かもしれません（IIUICこれは適切な属性または固有の呼び出しで達成できます）。
このトピックは、最近LLVMメーリングリストでも議論されています： http ：

トリアージ：I-ノミネート

悪いようです！ LLVMに「はい、このループは本当に無限です」と言う方法がない場合でも、上流の議論が解決するのを待つ必要があるかもしれません。

無限ループが最適化されないようにする方法は、ループ内にunsafe {asm!("" :::: "volatile")}を追加することです。 これは、LLVMメーリングリストで提案されているllvm.noop.sideeffect組み込み関数に似ていますが、一部の最適化が妨げられる可能性があります。
パフォーマンスの低下を回避し、発散する関数/ループが最適化されないことを保証するために、無人の値が含まれている場合は、最適化できない空のループ（つまり、 loop { unsafe { asm!("" :::: "volatile") } } ）を挿入するだけで十分だと思います。範囲。
LLVMがコードを最適化して、それ以上分岐しないようにする必要がある場合、そのようなループにより、制御フローを続行できなくなります。
LLVMが発散コードを最適化できない「幸運な」場合、そのようなループはDCEによって削除されます。

これは＃18785に関連していますか？ それはUBであるという無限再帰についてですが、根本的な原因は似ているように思われます。LLVMは停止しないことを副作用とは見なさないため、関数に停止しない以外の副作用がない場合は、最適化できます。それを離れて。

@geofft

同じ問題です。

はい、同じように見えます。 その問題のさらに下に、彼らはundefを取得する方法を示しています。そこから、（一見安全な）プログラムをクラッシュさせるのは難しくないと思います。

：+1：

クラッシュ、またはおそらくさらに悪いハートブリードhttps://play.rust-lang.org/?gist=15a325a795244192bdce&version=stable

だから私は誰かがこれを報告するまでどれくらいの期間疑問に思っていました。 :)私の意見では、最善の解決策はもちろん、LLVMに潜在的に無限ループについてそれほど積極的ではないように指示できるかどうかです。 そうでなければ、私たちにできると思う唯一のことは、Rust自体で保守的な分析を行って次のことを判断することです。

1. ループは終了しますOR
2. ループには副作用があります（I / O操作など、これがCでどのように定義されているかを正確に忘れています）

未定義の動作を回避するには、どちらでも十分です。

トリアージ：P-medium

私たちの側に多くの努力を費やす前に、LLVMが何をするかを見たいのですが、これが実際に問題を引き起こす可能性は比較的低いようです（コンパイラーの開発中にも個人的にこれにぶつかりましたが）。 気になる後方互換性の問題はありません。

LLVMメーリングリストの議論からの引用：

 The implementation may assume that any thread will eventually do one of the following:
   - terminate
   - make a call to a library I/O function
   - access or modify a volatile object, or
   - perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

@dotdash引用している抜粋は、C ++仕様からのものです。 これは基本的に「[副作用がある]がCでどのように定義されているか」に対する答えです（標準委員会でも確認されています：http：//www.open-std.org/jtc1/sc22/wg14/www/docs/n1528 .htm）。

LLVM IRの予想される動作については、いくつかの混乱があります。 https://llvm.org/bugs/show_bug.cgi?id=24078は、LLVMIRの無限ループのセマンティクスの正確で明示的な仕様がないように見えることを示しています。 これは、おそらく歴史的な理由と利便性のために、C ++のセマンティクスと一致しています（私はhttps://groups.google.com/forum/#!topic/llvm-dev/j2vlIECKkdEを追跡することしかできませんでしたが、これは明らかに時間を参照しています無限ループが最適化されていない場合、C / C ++仕様が更新されてそれが可能になるまでしばらく前）。

スレッドから、C ++コードを可能な限り効果的に最適化する（つまり、無限ループを削除する機会も考慮に入れる）ことが望まれることは明らかですが、同じスレッドで、複数の開発者（LLVMに積極的に貢献する開発者を含む）が他の言語で必要とされる無限ループを保持する機能に関心を示しました。

@ ranma42私はそれを知っています、参考のために引用しました。これを回避する1つの可能性は、錆びたループを検出し、上記の1つを追加して、LLVMがこの最適化を実行しないようにすることです。

これは健全性の問題ですか？ もしそうなら、そのようにタグ付けする必要があります。

はい、 @ ranma42の例に従って、この方法は、配列境界チェックを簡単に遊び場リンク

@bluss

ポリシーは、健全性の問題でもある間違ったコードの問題（つまりそれらのほとんど）にI-wrongタグを付ける必要があるというものです。

したがって、前の議論を要約すると、ここで私が見ることができる実際には2つの選択肢があります。

• LLVMが解決策を提供するのを待ちます。
• 無限ループまたは無限再帰がある可能性がある場合は常に、no-op asmステートメントを導入します（＃18785）。

後者は最適化を阻害する可能性があるため、やや悪いので、やや控えめに実行したいと思います。基本的に、自分で終了を証明できない場合はどこでも。 LLVMの最適化方法にもう少し結び付けることもできます。つまり、LLVMが無限ループ/再帰と見なすシナリオを検出できる場合にのみ導入しますが、（a）LLVMの追跡が必要であり、（b ）少なくとも私が持っているよりも深い知識が必要です。

LLVMが解決策を提供するのを待ちます。

この問題を追跡するLLVMバグとは何ですか？

補足： while true {}はこの動作を示します。 たぶん、lintはデフォルトでエラーにアップグレードされ、これが現在未定義の動作を示す可能性があることを示すメモを取得する必要がありますか？

また、これはCでは無効であることに注意してください。この引数を作成するLLVMは、clangにバグがあることを意味します。

void foo() { while (1) { } }

void create_null() {
        foo();

        int i = 0;
        while (i < 100) { i += 1; }
}

__attribute__((noreturn))
void use_null() {
        __builtin_unreachable();
}


int main() {
        create_null();
        use_null();
}

これは最適化でクラッシュします。 これは、C11標準では無効な動作です。

An iteration statement whose controlling expression is not a constant
expression, [note 156] that performs no  input/output  operations,
does  not  access  volatile  objects,  and  performs  no synchronization or
atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be   assumed   by   the
implementation to terminate. [note 157]

156: An omitted controlling expression is replaced by a nonzero constant,
     which is a constant expression.
157: This  is  intended  to  allow  compiler  transformations  such  as
     removal  of  empty  loops  even  when termination cannot be proven. 

「制御式が定数式ではない」- while (1) { } 、 1は定数式であるため、削除できないことに注意してください。

ループの削除は、簡単に削除できる最適化パスですか？

@ubsan

LLVMのbugzillaでそのバグレポートを見つけましたか、それとも埋めましたか？ C ++では、決して終了できない無限ループは未定義の動作であるように見えますが、Cでは定義された動作です（安全に削除できる場合とできない場合があります）。

@gnzlbg現在バグを報告しています。

https://llvm.org/bugs/show_bug.cgi?id=31217

＃42009から繰り返します。このバグにより、状況によっては、マシン命令をまったく含まない外部から呼び出し可能な関数が出力される可能性があります。 これは決して起こらないはずです。 LLVMがpub fnを正しいコードで呼び出すことはできないと推測した場合、その関数の本体として少なくともトラップ命令を発行する必要があります。

これは、今日このブログ投稿で取り上げられました： https ：

より簡単な複製： https ：

このためのLLVMバグはhttps://bugs.llvm.org/show_bug.cgi?id=965（2006年にオープン）です。

@zackw LLVMにはそのためのフラグがあります： TrapUnreachable 。 私はこれをテストしていませんが、 Options.TrapUnreachable = true;をLLVMRustCreateTargetMachine追加することで、あなたの懸念に対処できるはずです。 私は何も測定していませんが、これはデフォルトで実行できるほど十分に低いコストである可能性があります。

@ oli-obk残念ながら、これは単なるループ削除パスではありません。 この問題は、たとえば、（a）ブランチに副作用がない、（b）副作用のある命令を含まない関数に副作用がない、（c）副作用のない関数の呼び出しを移動できる、または削除されました。

パッチがあるようです： https ：

@ sunfishcode 、 https： //reviews.llvm.org/D38336のLLVMパッチが10月3日に「承認」されたようですが、LLVMのリリースプロセスに関してそれが何を意味するのかについての最新情報を教えてください。 受け入れを超えた次のステップは何ですか？また、将来のLLVMリリースにこのパッチが含まれるかどうかについての考えはありますか？

llvmdevスレッドがあることを提案したオフラインの人と話をしました。 スレッドはここにあります：

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html

これで結論が出ました。その結果、追加の変更を加える必要があります。 少し時間がかかりますが、変更は良いと思います。

アップデートしてくれてありがとう、そしてあなたの努力に感謝します！

https://reviews.llvm.org/rL317729がLLVMに到達したことに注意して

@zackwコードを含まない関数の問題を修正するために＃45920を作成しました。

@bstrieはい、最初のステップが

私は今これを再現できませんでした： https ：//play.rust-lang.org/？gist = 529bd5ab326f7b627e559f64d514312f

@jsgfまだ再現。 リリースモードを選択しましたか？

@kennytmうわー、気にしないで。

https://reviews.llvm.org/rL317729がLLVMに到達したことに注意して

このコメントから数ヶ月が経ちました。 フォローアップパッチが発生したのか、それとも今後も発生するのか、誰か知っていますか？

あるいは、使用しているLLVMバージョンにllvm.sideeffect組み込み関数が存在するようです。Rust無限ループを副作用固有値を含むLLVMループに変換することで、これを自分で修正できますか？

https://github.com/rust-lang/rust/issues/38136とhttps://github.com/rust-lang/rust/issues/54214に見られるように、これは次のpanic_implementation特に悪いですloop {}になります。これにより、 unsafeコードなしでpanic! UBがすべて出現します。 これは…おそらく起こりうる最悪の事態です。

別の観点からこの問題に遭遇したばかりです。 次に例を示します。

pub struct Container<'f> {
    string: &'f str,
    num: usize,
}

impl<'f> From<&'f str> for Container<'f> {
    #[inline(always)]
    fn from(string: &'f str) -> Container<'f> {
        Container::from(string)
    }
}

fn main() {
    let x = Container::from("hello");
    println!("{} {}", x.string, x.num);

    let y = Container::from("hi");
    println!("{} {}", y.string, y.num);

    let z = Container::from("hello");
    println!("{} {}", z.string, z.num);
}

この例は、stable、beta、nightlyで確実にセグメンテーション違反を起こし、任意のタイプの初期化されていない値を作成するのがいかに簡単かを示しています。 ここは遊び場にあります。

@SergioBenitezそのプログラムは最小限の作業例。

リリースビルドでは、LLVMは無限再帰がないと想定し、それを最適化します（ mwe ）。 これはループAFAICTとは関係ありませんが、 https： //stackoverflow.com/a/5905171/1422197とは関係ありません

@gnzlbg申し訳ありませんが、あなたは正しくありません。

プログラムはリリースモードでセグメンテーション違反を起こします。 それが全体のポイントです。 最適化によって不健全な動作が発生すること（LLVMとRustのセマンティクスがここで一致しないこと）、初期化されていないメモリの使用、任意のメモリの検査、および型間での任意のキャストを可能にするrustcを使用して安全なRustプログラムを記述およびコンパイルできます。言語のセマンティクス。 これは、このスレッドで説明されているのと同じポイントです。 元のプログラムもデバッグモードでセグメンテーション違反を起こさないことに注意してください。

また、ここで「異なる」非ループ最適化が行われていることを提案しているようです。 それが事実である場合、それが別の問題を正当化するかもしれないとしても、それは大部分は無関係ですが、ありそうにありません。 私の推測では、LLVMは末尾再帰に気づき、それを無限ループとして扱い、それを最適化して、まさにこの問題が何であるかを示しています。

@gnzlbgさて、無限再帰（ここ）から最適化のmweを少し変更すると、初期化されていない値NonZeroUsizeが生成されます（これは…0であるため、無効な値になります）。

そして、それは@SergioBenitezが彼らの例で行ったことですが、ポインターを使用していることを除いて、セグメンテーション違反を生成します。

@SergioBenitezプログラムのデバッグとリリースの両方でスタックオーバーフローが発生することに同意しますか？

もしそうなら、 @ SergioBenitezの例でloop見つけることができないので、この問題がどのように適用されるかわかりません（この問題は結局無限のloopです）。 私が間違っている場合は、例のloopを教えてください。

前述のように、LLVMは無限再帰が発生しないことを前提としています（すべてのスレッドが最終的に終了することを前提としています）が、これはこれとは異なる問題になります。

LLVMが行う最適化や、どちらのプログラムに対しても生成されたコードは調べていませんが、セグメンテーション違反がすべて発生する場合は、セグメンテーション違反が発生しないことに注意してください。 特に、（スタックプロービング+スタック終了後のマップされていないガードページによって）キャッチされ、メモリ安全性の問題を引き起こさないスタックオーバーフローも、セグメンテーション違反として表示されます。 もちろん、セグメンテーション違反は、メモリの破損、ワイルドな書き込み/読み取り、またはその他の健全性の問題を示している

@rkruppeランダムなメモリ位置への参照の作成が許可され、その後参照が読み取られたため、プログラムがセグメンテーション違反になりました。 プログラムは、代わりにランダムなメモリ位置を書き込むように簡単に変更でき、それほど困難なく、_特定の_メモリ位置を読み取り/書き込みします。

@gnzlbgプログラムは、リリースモードでスタックオーバーフローを_しません_。 リリースモードでは、プログラムは関数呼び出しを行いません。 スタックは、純粋にローカルを割り当てるために、有限回数にプッシュされます。

プログラムは、リリースモードでオーバーフローをスタックしません。

そう？ 重要なのは、基本的にfn foo() { foo() }であるサンプルプログラムには無限再帰があり、LLVMでは許可されていないことだけです。

重要なのは、基本的にfn foo（）{foo（）}であるサンプルプログラムには、LLVMでは許可されていない無限再帰があるということだけです。

それが何かを解決するようにあなたがこれを言っている理由はわかりません。 LLVMは、無限再帰を考慮し、UBをループし、それに応じて最適化しますが、Rustで安全であることが、この問題全体の要点です。

https://reviews.llvm.org/rL317729の作成者はここにあり、フォローアップパッチをまだ実装していないことを確認しています。

今日@llvm.sideeffect呼び出しを挿入して、ループが最適化されないようにすることができます。 それはいくつかの最適化を無効にするかもしれませんが、主要な最適化はそれを理解する方法を教えられているので、理論的にはそれほど多くはありません。 @llvm.sideeffect呼び出しをすべてのループまたはループに変わる可能性のあるもの（再帰、巻き戻し、インラインasmなど）に入れると、理論的にはここで問題を解決するのに十分です。

明らかに、2番目のパッチを配置しておくとよいので、これを行う必要はありません。 いつ実装に戻るかわかりません。

若干の違いはありますが、素材かどうかはわかりません。

再帰

#[allow(unconditional_recursion)]
#[inline(never)]
pub fn via_recursion<T>() -> T {
    via_recursion()
}

fn main() {
    let a: String = via_recursion();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* <strong i="9">@rust_eh_personality</strong> {
_ZN4core3ptr13drop_in_place17h95538e539a6968d0E.exit:
  ret void
}

ループ

#[inline(never)]
pub fn via_loop<T>() -> T {
    loop {}
}

fn main() {
    let b: String = via_loop();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 {
start:
  unreachable
}

メタ

Rust 1.29.1、リリースモードでコンパイル、LLVMIRを表示。

一般に、再帰（トレイトオブジェクト、C FFIなど）を検出できるとは思わないため、呼び出しを証明できない限り、ほとんどすべての呼び出しサイトでllvm.sideeffectを使用する必要があります。サイトは再帰しません。 証明できる場合に再帰がないことを証明するには、 fn main() { main() }ような最も些細なプログラムを除いて、手続き間の分析が必要です。 この修正を実装することの影響と、この問題に対する代替ソリューションがあるかどうかを知ることは良いことかもしれません。

@gnzlbgそれは本当ですが、@ llvm.sideeffectsを呼び出しサイトではなく、関数のエントリに配置することもできます。

不思議なことに、 @ SergioBenitezのテストケースで

また、スタックオーバーフローの場合、別のエラーメッセージが表示されるべきではありませんか？ 「スタックがオーバーフローした」などを出力するコードがあると思いましたか？

@RalfJungはデバッグモードで試しましたか？ （私のマシンと遊び場では、デバッグモードでスタックオーバーフローを確実に再現できるので、そうでない場合はバグを埋める必要があるかもしれません）。 --release 、すべてのコードが誤って最適化されているため、スタックオーバーフローは発生しません。

@sunfishcode

それは本当ですが、@ llvm.sideeffectsを呼び出しサイトではなく、関数のエントリに配置することもできます。

llvm.sideeffectsがどの最適化を妨げるかを正確に知らなければ、前進するための最善の方法を判断するのは困難です。 できるだけ少ない@llvm.sideeffectsを生成しようとする価値はありますか？ そうでない場合は、それをすべての関数呼び出しに入れるのが最も簡単なことかもしれません。 それ以外の場合、IIUCは、 @llvm.sideeffectが必要かどうかは、呼び出しサイトの機能によって異なります。

trait Foo {
    fn foo(&self) { self.bar() }
    fn bar(&self);
}

struct A;
impl Foo for A {
    fn bar(&self) {} // not recursive
}
struct B;
impl Foo for B {
    fn bar(&self) { self.foo() } // recursive
}

fn main() {
    let a = A;
    a.bar(); // Ok - no @llvm.sideeffect needed anywhere
    let b = B;
    b.bar(); // We need @llvm.sideeffect on this call site
    let c: &[&dyn Foo] = &[&a, &b];
    for i in c {
        i.bar(); // We need @lvm.sideeffect here too
    }
}

AFAICT、関数内に@llvm.sideeffect入れて、関数が削除されないようにする必要があるため、これらの「最適化」に価値があるとしても、現在のモデルで簡単に実行できるとは思いません。 たとえそうであったとしても、これらの最適化は、再帰がないことを証明できることに依存します。

デバッグモードで試しましたか？ （私のマシンと遊び場では、デバッグモードでスタックオーバーフローを確実に再現できるので、そうでない場合はバグを埋める必要があるかもしれません）

もちろんですが、デバッグモードではLLVMはループの最適化を行わないため、問題はありません。

プログラムがデバッグモードでオーバーフローした場合、それはUBを作成するためのLLVMライセンスを与えるべきではありません。 問題は、最終的なプログラムにUBがあるかどうかを把握することであり、IRを見つめているとわかりません。 セグメンテーション違反ですが、理由はわかりません。 しかし、スタックオーバーフロープログラムをセグメンテーション違反のプログラムに「最適化」することは、私にはバグのように思えます。

プログラムがデバッグモードでオーバーフローした場合、それはUBを作成するためのLLVMライセンスを与えるべきではありません。

しかし、スタックオーバーフロープログラムをセグメンテーション違反のプログラムに「最適化」することは、私にはバグのように思えます。

Cでは、実行スレッドは、終了、揮発性メモリアクセス、I / O、または同期アトミック操作を実行すると想定されています。 LLVM-IRが、偶然または設計によって同じセマンティクスを持つように進化しなかったとしたら、私は驚きます。

Rustコードには、終了することのない実行スレッドが含まれており、これがCでUBにならないようにするために必要な操作は実行されません。未定義の動作を持つCプログラムと同じLLVM-IRを生成するのではないかと思います。ですから、LLVMがこのRustプログラムを誤って最適化していることは驚くべきことではないと思います。

セグメンテーション違反ですが、理由はわかりません。

LLVMは無限再帰を削除するため、前述の@SergioBenitezのように、プログラムは次の

ランダムなメモリ位置への参照を作成することが許可され、その後、参照が読み取られました。

それを行うプログラムの部分はこれです：

let x = Container::from("hello");  // invalid reference created here
println!("{} {}", x.string, x.num);  // invalid reference dereferenced here

ここで、 Container::fromは無限再帰を開始し、LLVMはこれが発生することはないと結論付け、ランダムな値に置き換えて、参照を解除します。 これが誤って最適化される多くの方法の1つをここで見ることができます： https ：//rust.godbolt.org/z/P7Snex遊び場（https://play.rust-lang.org/?gist=f00d41cc189f9f6897d429350f3781ec&version=stable&mode = release＆edition = 2015）この最適化により、デバッグビルドからのリリースで別のパニックが発生しますが、UBはUBです。

Rustコードには、終了することのない実行スレッドが含まれており、これがCでUBにならないようにするために必要な操作は実行されません。未定義の動作を持つCプログラムと同じLLVM-IRを生成するのではないかと思います。ですから、LLVMがこのRustプログラムを誤って最適化していることは驚くべきことではないと思います。

これは無限ループの問題と同じバグではないとあなたが上で主張した印象を受けました。 その時、私はあなたのメッセージを読み間違えたようです。 混乱させて申し訳ありません。

それで、良い次のステップは、私たちが生成するIRにいくつかのllvm.sideffectを振りかけ、いくつかのベンチマークを行うことだと思われますか？

Cでは、実行スレッドは、終了、揮発性メモリアクセス、I / O、または同期アトミック操作を実行すると想定されています。

ところで、これは完全には正しくありません。条件付きのループ（ while (true) { /* ... */ } ）は、副作用が含まれていない場合でも、標準で明示的に許可されています。 これはC ++では異なります。 LLVMはここでC標準を正しく実装していません。

これは無限ループの問題と同じバグではないとあなたが上で主張した印象を受けました。

非終了のRustプログラムの動作は常に定義されますが、非終了のLLVM-IRプログラムの動作は、特定の条件が満たされた場合にのみ定義されます。

この問題は、生成されたLLVM-IRの動作が定義されるように、無限ループのRustの実装を修正することに関するものだと思いました。このため、 @llvm.sideeffectはかなり良い解決策のように聞こえました。

@SergioBenitezは、再帰を使用して非終了のRustプログラムを作成することもできると述べ、 @ rkruppeは、無限再帰と無限ループは同等であるため、これらは両方とも同じバグであると主張しました。

これらの2つの問題が関連していること、または同じバグであることに異論はありませんが、私にとっては、これら2つの問題は少し異なって見えます。

• ソリューションに関しては、最適化バリア（ @llvm.sideeffect ）を非終了ループに排他的に適用することから、すべてのRust関数に適用するようにします。

• 値的には、プログラムが終了しないため、無限のloopが役立ちます。 無限再帰の場合、プログラムが終了するかどうかは最適化レベル（LLVMが再帰をループに変換するかどうかなど）に依存し、プログラムがいつどのように終了するかはプラットフォーム（スタックサイズ、保護されたガードページなど）によって異なります。 Rust実装を健全にするためには両方を修正する必要がありますが、無限再帰の場合、ユーザーがプログラムを永久に再帰することを意図した場合、健全な実装は常に永久に再帰するとは限らないという意味で「間違った」ままです。

ソリューションに関しては、最適化バリア（@ llvm.sideeffect）を非終了ループにのみ適用することから、すべてのRust関数に適用します。

ループ本体には実際に副作用があり（外部関数の呼び出しの場合のように潜在的にだけでなく）、したがってllvm.sideeffect挿入する必要がないことを示すために必要な分析は、おそらくほぼ同じ順序で、非常に注意が必要です。無限再帰の一部である可能性のある関数について同じことを示す大きさ。 ほとんどのRustループにはイテレーターが含まれるため、最初に多くの最適化を行わずにループが終了していることを証明することも困難です。 したがって、 llvm.sideeffectをループの大部分に配置することになります。 確かに、ループを含まない関数はかなりありますが、それでも私には質的な違いのようには思えません。

問題を正しく理解していれば、無限ループの場合を修正するには、ループの本体にwhile <compile-time constant true> { ... }が含まれていないbreak loop { ... }とwhile <compile-time constant true> { ... }にllvm.sideeffectを挿入するだけで十分です。 break式。 これにより、無限ループのC ++セマンティクスとRustセマンティクスの違いがわかります。Rustでは、C ++とは異なり、コンパイラーは、コンパイル時にループが終了することがわかっているときにループが終了すると想定することはできません。 （体がパニックになる可能性のあるループに直面して、正確さについてどれだけ心配する必要があるかはわかりませんが、それは後でいつでも改善できます。）

無限再帰についてどうすればよいかわかりませんが、無限再帰を無関係のセグメンテーション違反に最適化することは望ましくない動作であるというRalfJungに同意します。

@zackw

問題を正しく理解していれば、無限ループのケースを修正するには、llvm.sideeffectをループ{...}に挿入するだけで十分です。{...}ここで、ループの本体にはブレーク式が含まれていません。

それほど単純ではないと思います。たとえば、 loop { if false { break; } }はbreak式を含む無限ループですが、llvmが削除しないように@llvm.sideeffectを挿入する必要があります。 AFAICTループが常に終了することを証明できない限り、 @llvm.sideeffectを挿入する必要があります。

@gnzlbg

loop { if false { break; } }はブレーク式を含む無限ループですが、llvmがそれを削除しないように、 @llvm.sideeffectを挿入する必要があります。

うーん、はい、それは面倒です。 しかし、私たちは_完璧_である必要はなく、控えめに正しいだけです。 のようなループ

while spinlock.load(Ordering::SeqCst) != 0 {}

（ std::sync::atomicドキュメントから）制御条件が一定ではないため、 @llvm.sideeffectを必要としないことが簡単にわかります（そして、アトミックロード操作はLLVMの目的で副作用としてカウントする方がよいでしょう） 、またはより大きな問題があります）。 プログラムジェネレータによって放出される可能性のある種類の有限ループ、

loop {
    if /* runtime-variable condition */ { break }
    /* more stuff */
}

また、面倒なことではありません。 実際、「ループの本体にブレーク式がない」ルールが間違っている場合はありますか？

loop {
    if /* provably false at compile time */ { break }
}

？

この問題は、生成されたLLVM-IRの動作が定義されるように、無限ループのRustの実装を修正することに関するものだと思いました。このため、@ llvm.sideeffectはかなり良い解決策のように聞こえました。

けっこうだ。 ただし、あなたが言ったように、問題（RustセマンティクスとLLVMセマンティクスの不一致）は、実際にはループではなく、非終了に関するものです。 ですから、ここで追跡する必要があるのはそれだと思います。

@zackw

問題を正しく理解していれば、無限ループのケースを修正するには、llvm.sideeffectをループ{...}に挿入するだけで十分です。{...}ここで、ループの本体にはブレーク式が含まれていません。 これにより、無限ループのC ++セマンティクスとRustセマンティクスの違いがわかります。Rustでは、C ++とは異なり、コンパイラーは、コンパイル時にループが終了していないことがわかっている場合に、ループが終了すると想定することはできません。 （体がパニックになる可能性のあるループに直面して、正確さについてどれだけ心配する必要があるかはわかりませんが、それは後でいつでも改善できます。）

あなたが説明することはCにも当てはまります。Rustでは、どのループも発散することができます。 他のすべてを行うのは不健全です。

だから、例えば

while test_fermats_last_theorem_on_some_random_number() { }

はRustでは問題ないプログラムです（ただし、CでもC ++でもありません）。副作用を引き起こすことなく、永久にループします。 したがって、終了することが証明できるものを除いて、すべてのループである必要があります。

@zackw

「ループの本体にブレーク式がない」ルールが間違っている場合はありますか？

if /*compile-time condition */だけでwhile 、 match 、 for 、...）、実行時の条件も影響を受けます。

しかし、私たちは完璧である必要はなく、控えめに正しいだけです。

考えてみましょう：

fn foo(x: bool) { loop { if x { break; } } }

ここで、 xは実行時の条件です。 ここで@llvm.sideeffect発行しない場合、ユーザーがfoo(false)どこかに書き込むと、 fooがインライン化され、定数の伝播とデッドコードの除去により、ループが最適化されます。副作用のない無限ループ。最適化の誤りが発生します。

それが理にかなっている場合、LLVMで実行できる変換の1つは、 fooをfoo_opt置き換えることです。

fn foo_opt(x: bool) { if x { foo(true) } else { foo(false) } }

ここで、両方のブランチは個別に最適化され、 @llvm.sideeffect使用しないと、2番目のブランチは最適化されません。

つまり、 @llvm.sideeffectを省略できるようにするには、LLVMがどのような状況でもそのループを誤って最適化できないことを証明する必要があります。 これを証明する唯一の方法は、ループが常に終了することを証明するか、ループが終了しない場合は、最適化の誤りを防ぐことの1つを無条件に実行することを証明することです。 それでも、ループ分割/ピーリングなどの最適化は、1つのループを一連のループに変換する可能性があり、最適化の誤りが発生するためには、そのうちの1つに@llvm.sideeffectがないだけで十分です。

このバグに関するすべては、 rustcからよりもLLVMから解決する方がはるかに簡単であるように私には聞こえます。 （免責事項：私はこれらのプロジェクトのいずれかのコードベースを本当に知りません）

私が理解しているように、LLVMからの修正は、最適化を実行中（非終了を証明する||どちらも証明できない）から、非終了を証明できる場合にのみ実行する（またはその逆）に変更することです。 これが（とにかく）簡単だと言っているわけではありませんが、LLVMにはすでに（おそらく）ループの（非）終了を証明しようとするコードが含まれています。

一方、 rustcは、 @llvm.sideeffect追加することによってのみこれを実行できます。これは、非終了を不適切に使用する最適化を「単に」無効にするよりも、最適化に大きな影響を与える可能性があります。 また、 rustcは、ループの（非）終了を検出するために新しいコードを埋め込む必要があります。

したがって、今後の道は次のようになると思います。

1. 問題を修正するために、すべてのループと関数呼び出しに@llvm.sideeffectを追加します
2. 非終了ループで誤った最適化を実行しないようにLLVMを修正し、 @llvm.sideeffectsを削除します

これについてあなたはどう思いますか？ ステップ1のパフォーマンスへの影響は、2が実装されると消えることを意図しているとしても、それほどひどいものではないことを願っています…

@Ekleogは、 @ sunfishcodeの2番目のパッチの内容https ： //lists.llvm.org/pipermail/llvm-dev/2017-October/118595.html

関数属性の提案の一部は
LLVM IRのデフォルトのセマンティクスを変更して、
無限ループし、potential-UBにオプトインする属性を追加します。 そう
そうすれば、@ llvm.sideeffectの役割は少しなります
微妙-Cのような言語のフロントエンドが選択する方法になるでしょう
機能の潜在的なUBに、しかしその後個人をオプトアウト
その関数のループ。

LLVMに公平を期すために、コンパイラーの作成者は、「ループが終了しないことを証明する最適化を作成して、それらを根本的に最適化できるようにする」という観点からこのトピックにアプローチしません。 代わりに、ループが終了するか、副作用があるという仮定は、いくつかの一般的なコンパイラアルゴリズムで自然に発生します。 これを修正することは、既存のコードを微調整するだけではありません。 かなりの量の新しい複雑さが必要になります。

関数本体に「副作用がない」かどうかをテストするために、次のアルゴリズムを検討してください。本体の命令に潜在的な副作用がある場合、関数本体に副作用がある可能性があります。 素晴らしくてシンプル。 その後、「副作用のない」関数の呼び出しは削除されます。 涼しい。 ただし、分岐命令には副作用がないと見なされるため、無限ループが含まれている場合でも、分岐のみを含む関数には副作用がないように見えます。 おっと。

修正可能です。 他の誰かがこれを調べることに興味があるなら、私の基本的な考えは、「副作用がある」という概念を「実際の副作用がある」と「終わらないかもしれない」という独立した概念に分割することです。 次に、オプティマイザー全体を調べて、「副作用がある」ことに関心のあるすべての場所を見つけ、実際に必要な概念を見つけます。 次に、ペシミゼーションを回避するために、ループの一部ではないブランチにメタデータを追加するようにループパスを教えるか、ループが含まれているループが有限であることを証明します。

考えられる妥協案は、ユーザーが文字通り空のloop { } （または同様のもの）または無条件の再帰（すでに糸くずが出ている）を書き込んだときに、rustcに@ llvm.sideeffectを挿入させることです。 この妥協により、実際に無限の効果のない回転ループを意図している人々は、他のすべての人のオーバーヘッドを回避しながら、それを取得することができます。 もちろん、この妥協によって安全なコードをクラッシュさせることは不可能ではありませんが、偶発的に発生する可能性は低くなる可能性があり、実装は簡単なはずです。

代わりに、ループが終了するか、副作用があるという仮定は、いくつかの一般的なコンパイラアルゴリズムで自然に発生します。

あなたがそれらの変換の正しさについて考え始めさえすれば、それは完全に不自然です。 率直に言って、この仮定を許可することはCの大きな間違いだったと思いますが、まあ。

ボディ内の命令に潜在的な副作用がある場合、関数ボディに副作用がある可能性があります。

あなたが物事を正式に見始めたとき、「非終了」が通常効果と見なされるのには十分な理由があります。 （Haskellは純粋ではありません。2つの効果があります：非終了と例外です。）

考えられる妥協案は、ユーザーが文字通り空のループ{}（または同様のもの）または無条件の再帰（すでに糸くずが出ている）を書き込んだときに、rustcに@ llvm.sideeffectを挿入させることです。 この妥協により、実際に無限の効果のない回転ループを意図している人々は、他のすべての人のオーバーヘッドを回避しながら、それを取得することができます。 もちろん、この妥協によって安全なコードをクラッシュさせることは不可能ではありませんが、偶発的に発生する可能性は低くなる可能性があり、実装は簡単なはずです。

ご指摘のとおり、これはまだ正しくありません。 間違っていることが

ここで起こったことは、「コンパイラに何を求めているか」から始めてそれを仕様にするのではなく、コンパイラが行ったことを中心に正当性の概念が構築されたことです。 正しいコンパイラは、常に分岐するプログラムを終了するプログラムに変換しません。 これはかなり自明だと思いますが、Rustが合理的な型システムを持っているので、これは型でもはっきりと目撃されています。そのため、問題は定期的に表面化しています。

使用している制約（つまり、LLVM）を考えると、最初に、十分な場所にllvm.sideeffectを追加して、すべての分岐実行がそれらの多くを無限に「実行」することが保証されるようにします。 次に、妥当な（健全で正しい）ベースラインに到達し、これらの注釈が不要であることを保証できる場合は、これらの注釈を削除することで改善について話し合うことができます。

私の主張をより正確に言うと、以下は健全なRustクレートであり、 pick_a_number_greater_2 （非決定論的に）ある種のbig-intを返していると思います。

fn test_fermats_last_theorem() -> bool {
  let x = pick_a_number_greater_2();
  let y = pick_a_number_greater_2();
  let z = pick_a_number_greater_2();
  let n = pick_a_number_greater_2();
  // x^n + y^n = z^n is impossible for n > 2
  pow(x, n) + pow(y, n) != pow(z, n)
}

pub fn diverge() -> ! {
  while test_fermats_last_theorem() { }
  // This code is unreachable, as proven by Andrew Wiles
  unsafe { mem::transmute(()) }
}

その分岐ループをコンパイルすると、それはバグであり、修正する必要があります。

これを素朴に修正するのにどれだけのパフォーマンスが必要かについては、これまでのところ数値さえありません。 そうするまで、上記のようなプログラムを故意に中断する理由はありません。

実際には、 fn foo() { foo() }は常にリソースの枯渇により終了しますが、Rust抽象マシンには無限に大きなスタックフレーム（AFAIK）があるため、そのコードをfn foo() { loop {} }に変換することは有効です。終了します（または、はるか後に、宇宙が凍結したとき）。 この変換は有効である必要がありますか？ はいと思います。そうしないと、終了を証明できない限り末尾呼び出しの最適化を実行できません。これは残念なことです。

与えられたループ、再帰、...が常に終了することを示すunsafe組み込みを持つことは意味がありますか？ N1528は、リンクリストが循環している可能性があるため、ループが終了すると想定できない場合、リンクリストをトラバースするポインタコードにループ融合を適用できないことを示しています。リンクリストが循環していないことを証明することは、最新のコンパイラでは不可能です。行う。

私は、この健全性の問題を永久に修正する必要があることに絶対に同意します。 ただし、「不要であることを証明できない場所にllvm.sideeffect追加する」と、今日正しくコンパイルされているプログラムのコード品質が低下する可能性があることに注意する必要があります。 このような懸念は、サウンドコンパイラの必要性によって最終的には無効になりますが、パフォーマンスの低下を回避し、平均的なRustプログラマの生活の質を向上させる代わりに、適切な修正を少し遅らせる方法で進めるのが賢明かもしれません。時間。 私が提案する：

• 長年の健全性バグに対する他の潜在的にパフォーマンス低下の修正（＃10184）と同様に、実際のコードベースへのパフォーマンスの影響を評価できるように、-Zフラグの背後にある修正を実装する必要があります。
• 影響が無視できるほど大きいことが判明した場合は、デフォルトで修正をオンにすることができます。
• しかし、そこから実際のリグレッションがある場合は、そのデータをLLVMの人々に渡して、最初にLLVMの改善を試みることができます（または、リグレッションを食べて後で修正することもできますが、いずれにせよ、情報に基づいた決定を下します）
• リグレッションのためにデフォルトで修正をオンにしないことにした場合は、少なくとも構文的に空のループにllvm.sideeffectを追加することができます。それらはかなり一般的であり、誤ってコンパイルされると、複数の人が惨めな支出をすることになります。奇妙な問題（＃38136、＃47537、＃54214、そして確かにもっとあります）のデバッグに何時間もかかるので、この緩和策は健全性のバグとは関係ありませんが、適切な問題を解決している間、開発者にとって具体的なメリットがありますバグ修正。

確かに、この見方は、この問題が何年も続いているという事実によって知らされています。 それが新たな退行であった場合、私はそれをより迅速に修正するか、それを導入したPRを元に戻すことにもっとオープンになります。

一方、この問題が未解決である限り、これはhttps://doc.rust-lang.org/beta/reference/behavior-considered-undefined.htmlで言及する必要がありますか？

与えられたループ、再帰、...が常に終了することを示すunsafe組み込みを持つことは意味がありますか？

std::hint::reachable_unchecked ？

ちなみに、私はTCPメッセージシステムの実際のコードを書くことに遭遇しました。 停止するための実際のメカニズムを導入するまで、一時停止として無限ループがありましたが、スレッドはすぐに終了しました。

誰かがテストケースコードゴルフをしたい場合：

fn main() {
    (|| loop {})()
}

`` `
$カーゴラン-リリース
不正な命令（コアダンプ）

誰かがテストケースコードゴルフをしたい場合：

pub fn main() {
   (|| loop {})()
}

https://github.com/rust-lang/rust/pull/59546の@sfanxiangによって追加された-Z insert-sideeffect rustcフラグを使用すると、ループし続けます:)

前：

main:
  ud2

後：

main:
.LBB0_1:
  jmp .LBB0_1

ちなみに、これを追跡しているLLVMのバグはhttps://bugs.llvm.org/show_bug.cgi?id=965ですが、このスレッドにはまだ投稿されていません。

このスレッドにはまだ投稿されていません。

https://github.com/rust-lang/rust/issues/28728#issuecomment-331460667およびhttps://github.com/rust-lang/rust/issues/28728#issuecomment-263956134

@RalfJungは、ハイパーリンクの更新ができますhttps://github.com/simnalamburt/snippets/blob/master/rust/src/bin/infinite.rsをに問題の説明にhttps://github.com/simnalamburt/snippets/blob / 12e73f45f3 / rust / infinite.rs this？ 以前のハイパーリンクは、パーマリンクではなかったため、長い間壊れていました。 ありがとう！ 😛

@simnalamburt完了、ありがとう！

MIR optレベルを上げると、次の場合の最適化の誤りを回避できるように見えます。

pub fn main() {
   (|| loop {})()
}

--emit=llvm-ir -C opt-level=1

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  unreachable
}

--emit=llvm-ir -C opt-level=1 -Z mir-opt-level=2

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  br label %bb1, !dbg !10

bb1:                                              ; preds = %bb1, %start
  br label %bb1, !dbg !11
}

https://godbolt.org/z/N7VHnj

rustc 1.45.0-nightly (5fd2f06e9 2020-05-31)

pub fn oops() {
   (|| loop {})() 
}

pub fn main() {
   oops()
}

それはその特別な場合には役立ちましたが、一般的に問題を解決しません。 https://godbolt.org/z/5hv87d

一般に、この問題は、関連する最適化を使用する前に、rustcまたはLLVMのいずれかが純粋関数が完全であることを証明できる場合にのみ解決できます。

確かに、私はそれが問題を解決したと主張していませんでした。 微妙な効果は他の人にとって十分に興味深いものだったので、ここでも言及する価値があるように思われました。 -Z insert-sideeffectは、引き続き両方のケースを修正します。

LLVM側で何かが動いています。進行状況の保証を制御するために関数レベルの属性を追加する提案があります。 https://reviews.llvm.org/D85393

なぜ誰もが（こことLLVMスレッドで）前進についての条項を強調しているように見えるのかわかりません。

ループの排除は、メモリモデルの直接的な結果のようです。値の計算は、値を使用する前に、発生する限り移動することができます。 さて、値を使用できないという証拠があれば、それは前に起こったことがないという証拠であり、コードは無限に遠くまで移動でき、それでもメモリモデルを満たします。

または、メモリモデルに精通していない場合は、ループ全体が抽象化されて値を計算する関数になることを検討してください。 ここで、ループ外の値のすべての読み取りをその関数の呼び出しに置き換えます。 この変換は確かに有効です。 ここで、値の使用がない場合、無限ループを実行する関数の呼び出しはありません。

値の計算は、それらが発生する限り、値を使用する前に移動できます。 さて、値を使用できないという証拠があれば、それは前に起こったことがないという証拠であり、コードは無限に遠くまで移動でき、それでもメモリモデルを満たします。

このステートメントは、その計算が終了することが保証されている場合にのみ正しいです。 非終了は副作用であり、stdoutに出力する計算を削除できないのと同じように（「純粋ではない」）、終了しない計算を削除することはできません。

結果が使用されていない場合でも、次の関数呼び出しを削除することはできません。

fn sideeffect() -> u32 {
  println!("Hello!");
  42
}

fn main() {
  let _ = sideffect(); // May not be removed.
}

これはあらゆる種類の副作用に当てはまり、印刷物をloop {}置き換えても当てはまります。

副作用としての非終了についての主張は、それがそうであるという合意（つまり、物議を醸すものではない）だけでなく、それがいつ守られるべきかについての合意も必要とします。

ループが値を計算する場合、非終了は確実に観察されます。 ループの結果に依存しない計算を並べ替えることが許可されている場合、非終了は観察されません。

LLVMスレッドの例のように。

x = y % 42;
if y < 0 return 0;
...

部門の終了プロパティは、並べ替えとは何の関係もありません。 最新のCPUは、分割、比較、分岐予測、および成功した分岐のプリフェッチを並行して実行しようとします。 したがって、 yが負の場合、 0返されるのを観察したときに完了した除算を観察することは保証されません。 （ここで「観察する」とは、プログラムではなく、CPUが置かれているオシロメーターで実際に測定することを意味します）

分割が完了したことを確認できない場合、分割が開始されたことを確認することはできません。 したがって、上記の例の除算は通常、並べ替えが許可されます。これは、コンパイラーが実行する可能性のあることです。

if y < 0 return 0;
x = y % 42;
...

これが許可されていない言語があるかもしれないので、私は「通常」と言います。 Rustがそのような言語であるかどうかはわかりません。

純粋なループも例外ではありません。

私はそれが問題ではないと言っているのではありません。 私が言っているのは、前進保証はそれを可能にするものではないということだけです。

副作用としての非終了についての主張は、それがそうであるという合意（つまり、物議を醸すものではない）だけでなく、それがいつ観察されるべきかについての合意も必要とします。

私が表現しているのは、プログラミング言語とコンパイラの研究分野全体のコンセンサスです。 確かにあなたは自由に反対することができますが、それなら「コンパイラの正しさ」のような用語を再定義したほうがよいでしょう-それは他の人との議論には役立ちません。

許容される観測値は、常にソースレベルで定義されます。 言語仕様は「抽象マシン」を定義します。これは、プログラムの許容される観察可能な動作が何であるかを（理想的には数学的詳細で）記述します。 このドキュメントでは、最適化については説明していません。

次に、コンパイラの正確さは、コンパイラが生成するプログラムが、ソースプログラムが持つことができると仕様が述べている観察可能な動作のみを示すかどうかで測定されます。 これは、正確さを真剣に受け止めるすべてのプログラミング言語がどのように機能するかであり、コンパイラーが正しい場合に正確な方法でキャプチャする方法を知る唯一の方法です。

各言語の責任は、ソースレベルで観察可能と見なされるものと、「未定義」と見なされるためコンパイラによって発生しないと見なされるソースの動作を正確に定義することです。 この問題は、C ++が他の副作用（「サイレントダイバージェンス」）のない無限ループは未定義の動作であると言っているが、Rustはそのようなことを言っていないために発生します。 これは、Rustでの非終了が常に監視可能であり、コンパイラーによって保持される必要があることを意味します。 C ++を選択すると、未定義の動作（したがって重大なバグ）がプログラムに誤って導入されやすくなるため、ほとんどのプログラミング言語でこの選択が行われます。 Rustは、安全なコードから未定義の動作が発生しないことを約束します。安全なコードには無限ループが含まれる可能性があるため、Rustの無限ループは定義された（したがって保持された）動作である必要があります。

これらが紛らわしい場合は、背景を読むことをお勧めします。 ベンジャミン・ピアスの「タイプとプログラミング言語」をお勧めします。 著者が実際にどれほど十分な情報を持っているかを判断するのは難しいかもしれませんが、おそらくそこにはたくさんのブログ投稿もあります。

具体的には、除算の例を次のように変更した場合

x = 42 % y;
if y <= 0 { return 0; }

次に、yがゼロの場合（クラッシュからゼロを返す）に観察可能な動作が変わるため、条件付きを除算の上に上げることができないことに同意していただければ幸いです。

同じように、

x = if y == 0 { loop {} } else { y % 42 };
if y < 0 { return 0; }

Rust抽象マシンでは、これを次のように書き直すことができます。

if y == 0 { loop {} }
else if y < 0 { return 0; }
x = y % 42;

ただし、最初の条件とループは破棄できません。

ラルフ、私はあなたがしていることの半分を知っているふりをしません、そして私は新しい意味を紹介したくありません。 私は、正しさの定義に完全に同意します（実行順序はプログラム順序に対応している必要があります）。 私は、非終了が観察できる「いつ」がその一部であると思っただけです。ループの結果を監視していない場合、その終了の目撃者はいない（したがって、その不正確さを主張することはできません）。 。 実行モデルを再検討する必要があります。

よろしくお願いします

@zackwありがとうございます。 これは別のコードであり、もちろん別の最適化になります。

除算に欠陥があるのと同じ方法でループが最適化されるという私の前提（除算の結果を見ることができない==ループの終了を見ることができない）なので、残りは重要ではありません。

@olotenko 「ループの結果を監視する」とはどういう意味かわかりません。 ループが終了しないと、プログラム全体が発散します。これは、観察可能な動作と見なされます。つまり、プログラムの外部で観察可能です。 のように、ユーザーはプログラムを実行して、それが永遠に続くことを確認できます。 永久に続くプログラムは、ユーザーがプログラムについて観察できる内容を変更するため、終了するプログラムにコンパイルされない場合があります。

そのループが何を計算していたか、またはループの「戻り値」が使用されているかどうかは関係ありません。 重要なのは、プログラムの実行時にユーザーが観察できることです。 コンパイラーは、この観察可能な動作が同じままであることを確認する必要があります。 非終了は観察可能と見なされます。

別の例を挙げると：

fn main() {
  loop {}
  println!("Hello");
}

ループがあるため、このプログラムは何も出力しません。 しかし、ループを最適化した場合（または印刷でループを並べ替えた場合）、プログラムは突然「Hello」を印刷します。 したがって、これらの最適化はプログラムの観察可能な動作を変更し、許可されません。

@RalfJungそれは大丈夫です、私は今それを手に入れました。 私の最初の問題は、ここで「前進保証」がどのような役割を果たすかということでした。 最適化は完全にデータ依存性から可能です。 私の間違いは、実際にはデータの依存関係はプログラムの順序の一部ではないということでした。文字通り、言語のセマンティクスに従って完全に順序付けられた式です。 プログラムの順序が合計の場合、前方進行保証（「プログラムの順序のサブパスは有限である」と言い換えることができます）がなければ、終了として_証明_できる式のみを（実行順序で）並べ替えることができます（および同期アクション、OS呼び出し、IOなどの可観測性など、他のいくつかのプロパティを保持します。

もう少し考える必要がありますが、 x = y % 42の例では、一部の入力に対して実際に実行されなくても、除算が「ふり」できる理由がわかると思いますが、同じことが任意のループに当てはまらない理由。 つまり、全体（プログラム）の順序と部分（実行）の順序の対応の微妙さです。

無限再帰はスタックオーバーフローのクラッシュ（「ユーザーが結果を観察する」という意味で「終了」）を引き起こすため、「観察可能な動作」はそれよりも少し微妙かもしれませんが、末尾呼び出しの最適化それを非終了ループに変えます。 少なくともこれは、Rust / LLVMが行うもう1つのことです。 しかし、それは私の問題の内容ではないので、その質問について議論する必要はありません（あなたが望むのでない限り！それが期待されるかどうかを理解してうれしいです）。

スタックオーバーフロー

スタックオーバーフローは確かにモデル化するのが難しい、良い質問です。 メモリ不足の状況でも同じです。 最初の概算として、私たちは正式にそれらが起こらないふりをします。 より良いアプローチは、関数を呼び出すたびに、スタックオーバーフローが原因でエラーが発生するか、プログラムが続行する可能性があると言うことです。これは、各呼び出しで行われる非決定論的な選択です。 このようにして、実際に何が起こっているかをしっかりと概算できます。

終了として証明できる式のみを（実行順序で）並べ替えることができます

確かに。 さらに、それらは「純粋」である必要があります。つまり、副作用がない必要があります。2つのprintln!並べ替えることはできません。 そのため、通常、非終了も効果と見なされます。これは、すべて「純粋な式を並べ替えることができる」、「非終了の式は不純である」（不純=副作用がある）ためです。

除算も潜在的に不純ですが、0で除算した場合にのみ、パニック、つまり制御効果が発生します。 これは直接観察可能ではなく、間接的に観察可能です（たとえば、パニックハンドラーにstdoutに何かを出力させ、それを観察可能にすることによって）。 したがって、除算は、0で除算していないことが確実な場合にのみ並べ替えることができます。

この問題の可能性があると思われるデモコードがいくつかありますが、完全にはわかりません。 必要に応じて、これを新しいバグレポートに入れることができます。
そのコードをhttps://github.com/uglyoldbob/rust_demoのgitリポジトリに配置しました

私の無限ループ（副作用あり）が最適化され、トラップ命令が生成されます。

それがこの問題のインスタンスなのか他の何かなのかわかりません...組み込みデバイスは私の専門ではなく、これらすべての外部クレート依存関係があるため、そのコードが他に何をしているのかわかりません。^^しかし、あなたのプログラムは安全ではなく、ループ内で揮発性のアクセスがあるため、別の問題だと思います。 あなたの例を遊び場に

ループ内のすべてがローカル変数への参照であるようです（他のスレッドにエスケープされたものはありません）。 このような状況では、揮発性のストアがなく、観察可能な影響がないことを簡単に証明できます（同期できるストアがありません）。 Rustが揮発性物質に特別な意味を追加しない場合、このループは純粋な無限ループに減らすことができます。

@uglyoldbob llvm-objdumpが見事に役に立たなかった（そして不正確だった）場合、あなたの例で実際に起こっていることはより明確になります。 ここでのbl #4 （実際には有効なアセンブリ構文ではありません）は、 bl命令の終了後、別名main関数の終了後の4バイトへの分岐を意味します。次の機能の開始。 次の関数は（私がビルドしたときに） _ZN11broken_loop18__cortex_m_rt_main17hbe300c9f0053d54dEと呼ばれ、それが実際のmain関数です。 マングルされていない名前main関数はあなたの関数ではありませんが、 cortex-m-rtによって提供される#[entry]マクロによって生成される完全に異なる関数です。 コードは実際には最適化されていません。 （実際、デバッグモードでビルドしているため、オプティマイザーは実行されていません。）