Rust: 末尾呼び出しを行うようにrustcに教える

グレイドンによれば、これを実装する前に、規約の呼び出しについてもう少し考える必要があります。 LLVMは末尾呼び出しを実装するためにfastcc規則を必要としますが、それは私たちが望むことを完全には行いません：

グレイドン：brson：llvm-landのコメントから判断すると、問題が発生している可能性があります。 fastccが今日行っていることを補うことができるかもしれませんが、明日は考えを変えることができます。
グレイドン：fastcc == x86_fastcallだと思いましたが、間違っていました。
グレイドン：これらは異なる呼び出し規約です。 fastccは「今週のllvmの感じは何でも」です
グレイドン：x86_fastcallに切り替えてから、長期的には独自の呼び出し規約を作成する必要があります。

これは、LLVMが末尾呼び出しを処理する方法にいくつかの複雑さがあるため、現在半分実装されています。 Rustcは、「be」式を解析し、それらをcall + retペアとして変換します。これは、単純でそれほど深くないケースで「作業」するのに十分です。 ブートストラップするには十分かもしれません。

保証された末尾呼び出しをサポートするCC（fastcc）は明らかに1つだけであり、それに適応するには、いくつかの場所でABIの仮定を変更する必要があります（-tailcalloptフラグを有効にするとcallee-restoreに変わります）。 したがって、必要に応じてcall +retペアに「tail」の注釈を付けても、実際にはまだその最適化の実行を開始するようにLLVMに指示することはできません。

セルフホスティングのためにここに示されているよりも多くの実装を必要としないことが判明しました。 次のマイルストーンへのパント。

誰かが私たちが実際にこれをもうやろうとしていると感じますか？

それが起こるようには思われません。

LLVMと末尾呼び出しの状況はどうですか？ 呼び出し先が末尾呼び出しであると宣言するなどの侵襲的なものなしで確実に機能するようにできる場合は、末尾呼び出しに渡すことができるものの限定されたセット（呼び出し元自身の引数、スカラー）、および何かが発生したときのエラーを定義できます。それ以外の場合は渡されます。 ただし、このような末尾呼び出しは実際にはあまり役に立たない場合があります。

HaskellのGHCLLVMバックエンドを見ることが役立つ可能性はありますか？

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM
http://llvm.org/docs/LangRef.html#callingconv
http://llvm.org/docs/CodeGenerator.html#tailcallopt

これらは、末尾呼び出し以外の場合には最適ではない呼び出し先ABIでのみ機能します。 したがって、ある意味では、そうです、彼らは、呼び出し先がテールコールされるように宣言されることを要求します。

これを実装するには、たとえば、クレートを分析し、末尾呼び出しの関数を見つけたら、末尾呼び出しに適したABIで個別にコンパイルするか、エントリ時にABIを切り替えるラッパーをコンパイルします。 または、どこでも_every_関数を末尾呼び出しに適したABIを使用するように切り替えることができます。 現在それを行っているかどうかはわかりません。 しばらくいましたが、やめたかもしれません。 これはLLVMの「fastcall」ABIであり、これはもう使用していないと思います。

いずれにせよ、それは少し混乱です。

現在、兄弟呼び出しの最適化があります。 もっとやろうと思っていますか？

＃2216で対処されている範囲を除いて、発生しません。 ＃2216のソリューションは、一般的なステートマシンコーディングをサポートするのに十分な広さである必要があります。

これは引き続き会話の中で発生し、 beを再度予約しました。 再開。

メーリングリストに対するGraydonのコメントは次のとおりです。

https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html

この棺に釘を入れます。 ここで再現：

2013年10月4日午前5時43分、ArtellaCodingは次のように書いています。

こんにちは、錆は末尾呼び出しの最適化を行いますか？ 私が尋ねている理由は
次の末尾呼び出しの再帰的な実装は、スタックになります
オーバーフロー。 ありがとう。

いいえ、そうはならないでしょう。 これには長年のバグがあります：

https://github.com/mozilla/rust/issues/217

ウィキページといくつかのメーリングリストスレッドと同様に：

https://github.com/mozilla/rust/wiki/Bikeshed-tailcall
https://mail.mozilla.org/pipermail/rust-dev/2011-August/000689.html
https://mail.mozilla.org/pipermail/rust-dev/2012-January/001280.html
..。

このすべての要約は次のとおりです。

• 末尾呼び出しが高潔な言語機能であることは誰もが知っています。
  それらの美徳をさらに詳しく説明する必要はありません。 私たちの多く
  lispとMLのバックグラウンドを持っており、それらを非常に気に入っています。 彼らの
  不在は心痛と悲しみであり、到着していません-軽く。
• 末尾呼び出しは、決定論的破壊で「ひどくプレイする」と呼びます。 含む
  〜ボックスの決定論的ドロップ。 彼らがそうではないということは言うまでもありません
  構成可能ですが、それらを構成するためのオプションはUIが扱いにくいです。
  パフォーマンスの低下、セマンティクスの複雑化、または上記のすべて。
• 末尾呼び出しも、次のようなCツールの仮定で「うまく機能しない」
  プラットフォームABIとダイナミックリンク。
• 末尾呼び出しには、パフォーマンスに影響を与える呼び出し規約が必要です
  C規則に関連します。
• 末尾_recursion_のほとんどのケースは、次のようにかなりうまく変換されます。
  ループ、および非再帰的な末尾呼び出しのほとんどの場合、状態をエンコードします
  ラップアラウンドされたループに適度に変換するマシン
  列挙型。 これらはどちらも、
  末尾呼び出しを使用するバリアントですが、機能し、「同じくらい高速」です*、
  CおよびC++プログラマー（私たちの
  主な聴衆）。

申し訳ありませんが、心が重いですが、
それらに関連するトレードオフを行う方法を試しましたが見つかりませんでした
さびに含めるための議論に要約します。

-グレイドン

• 速度的には、スイッチインループステートマシンは間接ディスパッチであるため、
  からの末尾呼び出しによってエンコードされたステートマシンよりも実行が遅くなる可能性があります
  州から州へ; 一方、このパフォーマンスを得る方法が
  「戻る」とは、どこでも末尾呼び出しをオンにすることです。孤立したものを取引します。
  クロスオールプログラムのsuboptimal-perf税のsuboptimal-perfケース。 私たち
  この取引は受け入れられないと思います。

Haskellは通常、インライン化や融合などのために静的な引数変換を必要とすることに注意してください。http://stackoverflow.com/a/9660027/667457

Rustは、別の関数内で定義された関数は末尾呼び出しの最適化のために除外可能である必要があると言うことで、静的引数変換をサポートできます。 または、別の関数内にネストされた関数間のテールコールが兄弟の最適化に失敗した場合は、単に警告します。 現在の状況がわからない。

末尾再帰が実装されないのは悲しいことです。 それから私は質問があります：関数型の本質的な機能が欠けているのに、なぜ関数型言語構文のように見える言語構文を作成するのですか？

私はさびたニュースで、とても悲しいです。 末尾再帰関数を試してみましたが、オーバーフローを非常に速くスタックしました。 リリースでコンパイルすると、動作が変化します。 彼は私の関数を呼び出さないだけです。 友人から、LLVMは未定義の値に最適化されると言われました（LLVMは、末尾再帰が無限であることを知っていますか？！？）。

fn rec(i: i32) {
  rec(i + 1)
}

fn main() {
  println!("{}", rec(0));
}

私は、末尾呼び出しを実装しない機能機能を備えた言語であるBoiethiosに同意します。

私はCとC++で書いていますが、末尾呼び出しを保証するものではありませんが、実際には非常にうまく処理されます。 さびを学ぶのを止めるつもりはありません、今私はさびがそれを処理しないことを知っています。 せずにコーディングするので、大きな問題ではありません。

しかし、それは現代語にとって非常に優れた機能だと思います。

そのことに注意してください

fn rec(i: i32) {
  println!("Hello");
  rec(i + 1)
}

貨物のリリースモードでもスタックオーバーフロー

可能であれば、最終的に保証付きTCOを実装する予定です。 そのためのキーワード「become」も予約しました。 RFCリポジトリを確認してください。

2016年8月3日、19：46 -0400、 AntoinePLASKOWSKInotifications @github.comは次のように書いています。

私はさびたニュースで、とても悲しいです。 末尾再帰関数を試してみましたが、オーバーフローを非常に速くスタックしました。 リリースでコンパイルすると、動作が変化します。 彼は私の関数を呼び出さないだけです。 友人が私に、LLVMは値を定義しないように最適化すると言いました（LLVMはそれが無限再帰であると知っていますか？！？）。

fn rec（i：i32）{rec（i + 1）} fn main（）{println！（ "{}"、rec（0））; }

私は、末尾呼び出しを実装しない機能機能を備えた言語であるBoiethiosに同意します。

私はCとC++で書いていますが、末尾呼び出しを保証するものではありませんが、実際には非常にうまく処理されます。 さびを学ぶのを止めるつもりはありません。さびはそれを処理しないことがわかったので、それなしでコーディングするので、大きな問題ではありません。

しかし、それは現代語にとって非常に優れた機能だと思います。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHub（https://github.com/rust-lang/rust/issues/217#issuecomment-237409642）で表示するか、スレッドをミュートします（https://github.com/notifications/unsubscribe -auth / AABsipoedHrbnKDekmzCr-dl8M6g-Gojks5qcShKgaJpZM4AC-q_）。

質問：少なくとも単一のクレート内で、コールグラフ分析を実行し、末尾呼び出しをループに変換することは仮想的に可能ですが、コンパイル時に計算コストが高く、コーディングが非常に困難です。 この可能性についての議論はありましたか？ 呼び出し規約の選択に関係なく、それは今でもオプションです。

lbstanzaのアプローチは、関数をTCO（defnではなくdefn +）に適格にするために、関数の注釈を要求することです。 さびた場合、文字通りどこでも末尾呼び出しを使用していない限り、それはtimthelionの提案に対する余分なコンパイル時間のオーバーヘッドを大幅に軽減します（笑）。