Rust: Rustc에게 꼬리 호출을 하도록 가르치십시오.

Graydon에 따르면 이것을 구현하기 전에 호출 규칙에 대해 좀 더 생각해 볼 필요가 있습니다. LLVM은 꼬리 호출을 구현하기 위해 fastcc 규칙이 필요하지만 우리가 원하는 대로는 되지 않습니다:

Graydon: brson: llvm-land의 의견으로 판단하면 문제가 있을 수 있습니다. 우리는 fastcc가 오늘 하는 일을 보상할 수 있을지 모르지만 내일 마음을 바꿀 수 있습니다.
Graydon: fastcc == x86_fastcall이라고 생각했는데 틀렸습니다.
Graydon: 다른 호출 규칙입니다. fastcc는 "이번 주에 llvm이 어떤 느낌이든 간에"입니다.
Graydon: x86_fastcall로 전환한 다음 장기적으로 자체 호출 규칙을 작성해야 합니다.

이것은 LLVM이 꼬리 호출을 처리하는 방식의 몇 가지 복잡한 문제로 인해 현재 절반만 구현되었습니다. Rustc는 'be' 표현을 구문 분석하고 이를 call+ret 쌍으로 변환합니다. 이는 단순하고 아주 깊지 않은 경우에 '작업'하도록 하기에 충분합니다. 부트스트랩에 충분할 수 있습니다.

보장된 꼬리 호출을 지원하는 CC(fastcc)는 분명히 하나뿐이며 이에 적응하려면 여러 위치에서 ABI 가정을 변경해야 합니다(-tailcallopt 플래그를 활성화하면 호출 수신자 복원으로 바뀝니다). 따라서 필요에 따라 call+ret 쌍에 'tail'로 주석을 달더라도 실제로 LLVM에 해당 최적화 수행을 시작하도록 지시할 수 없습니다.

자체 호스팅에 대해 여기에 표시된 것보다 더 많은 구현이 필요하지 않은 것으로 나타났습니다. 다음 이정표를 향한 펀트.

우리가 실제로 더 이상 이것을 할 것이라고 생각하는 사람이 있습니까?

일어날 것 같지 않습니다.

LLVM 및 꼬리 호출의 상황은 무엇입니까? 호출 수신자를 꼬리 호출로 선언하는 것과 같은 침입적인 요소 없이 안정적으로 작동하도록 만들 수 있다면 꼬리 호출(호출자의 자체 인수, 스칼라) 및 오류 발생 시 전달할 수 있는 제한된 집합을 정의할 수 있습니다. 그렇지 않으면 통과됩니다. 그러나 이러한 꼬리 호출은 실제로는 그다지 유용하지 않을 수 있습니다.

Haskell의 GHC LLVM 백엔드를 보는 것이 도움이 될 수 있습니까?

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를 전환하는 래퍼를 컴파일하는 등의 방법으로 이를 구현할 수 있습니다. 또는 꼬리 호출 친화적인 ABI를 사용하도록 모든 곳에서 _every_ 함수를 전환할 수 있습니다. 현재 그렇게 하고 있는지 잘 모르겠습니다. 우리는 잠시 동안 있었지만 멈췄을 수도 있습니다. 우리가 더 이상 사용하지 않는 LLVM "fastcall" ABI입니다.

어쨌든 좀 엉망입니다.

이제 형제 호출 최적화가 있습니다. 우리는 더 많은 것을 시도할 계획입니까?

#2216에서 언급한 범위를 제외하고는 일어나지 않을 것입니다. #2216에 대한 솔루션은 일반 상태 머신 코딩을 지원하기에 충분히 광범위해야 합니다.

이것은 대화에서 계속해서 나오고, 우리는 be 를 다시 예약했습니다. 재개장.

메일링 리스트에 대한 Graydon의 의견은 다음과 같습니다.

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

이 관에 못을 박습니다. 여기에서 재현:

2013년 10월 4일 오전 5시 43분에 Artella Coding은 다음과 같이 썼습니다.

안녕하세요 녹이 꼬리 호출 최적화를합니까? 내가 묻는 이유는
다음 꼬리 호출 재귀 구현 결과 스택
과다. 감사 해요.

아니요, 그렇지 않을 가능성이 큽니다. 이것에 대한 오랜 버그가 있습니다.

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가 어색합니다.
  성능 저하, 의미 복잡화 또는 위의 모든 것.
• 꼬리 호출은 또한
  플랫폼 ABI 및 동적 연결.
• 꼬리 호출에는 성능 저하인 호출 규칙이 필요합니다.
  C 규칙과 관련이 있습니다.
• 우리는 tail _recursion_ 의 대부분의 경우가 합리적으로 잘 변환된다는 것을 발견했습니다.
  루프 및 대부분의 비재귀 꼬리 호출의 경우 상태를 인코딩합니다.
  합리적으로 잘 감싸진 루프로 변환하는 기계
  열거. 둘 다 _꽤_ 예쁘지 않습니다.
  꼬리 호출을 사용하는 변형이지만 작동하고 "빠르게"*,
  뿐만 아니라 C 및 C++ 프로그래머를 위한 관용적 표현(우리의
  주요 청중).

이런 말씀을 드려 죄송하고 마음이 무겁지만 저희는
시도했지만 그들과 관련된 절충안을 만드는 방법을 찾지 못했습니다.
녹에 포함되는 주장을 요약합니다.

-그레이든

• 속도 측면에서 스위치 인 어 루프 상태 머신은 간접 디스패치이므로
  의 꼬리 호출에 의해 인코딩된 상태 머신보다 느리게 실행될 가능성이 높습니다.
  상태에서 상태로; 반면에 이 성능을 얻는 방법은
  "뒤로"는 모든 곳에서 테일 콜을 켜는 것입니다. 우리는 고립된 것을 거래할 것입니다.
  모든 프로그램에 대한 최적의 성능이 아닌 경우 최적의 성능이 아닌 세금. 우리
  이 거래가 허용되지 않습니다.

Haskell은 일반적으로 인라인, 융합 등을 위해 정적 인수 변환이 필요하다는 점에 주목할 가치가 있습니다. http://stackoverflow.com/a/9660027/667457

Rust는 다른 함수 내부에 정의된 함수가 tailcall 최적화에 적합해야 한다고 말함으로써 정적 인수 변환을 지원할 수 있습니다. 또는 다른 함수 내부에 중첩된 함수 간의 꼬리 호출이 형제 최적화에 실패한 경우 단순히 경고합니다. 현재 상황이 확실하지 않습니다.

꼬리 재귀가 구현되지 않는다는 것은 슬픈 일입니다. 그런 다음 질문이 있습니다. 기능의 필수 기능이 없는 경우 기능 언어 구문처럼 보이는 언어 구문을 만드는 이유는 무엇입니까?

나는 녹슬고 매우 슬프다. 나는 꼬리 재귀 함수를 시도하고 오버플로를 너무 빨리 쌓습니다. 릴리스에서 컴파일 할 때 동작 변경이 가장 최악입니다. 그는 내 기능을 호출하지 않습니다. 친구가 나에게 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를 구현할 계획이 있습니다. 우리는 심지어 "becom"이라는 키워드를 예약했습니다. RFC 리포지토리를 확인하십시오.

2016년 8월 3일 19:46 -0400, Antoine PLASKOWSKI [email protected] 이 다음과 같이 썼습니다.

나는 녹슬고 매우 슬프다. 나는 꼬리 재귀 함수를 시도하고 오버플로를 너무 빨리 쌓습니다. 릴리스에서 컴파일 할 때 동작 변경이 가장 최악입니다. 그는 내 기능을 호출하지 않습니다. 친구는 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의 제안에 대한 추가 컴파일 시간 오버 헤드를 크게 완화합니다.