Hacker News 의견

• C 표준 제안서에는 "return goto (expression);" 형태로 꼬리 호출을 포함하고 있음

  • [[musttail]]을 표준화하는 것보다 로컬 객체의 수명이 보장되어 광범위한 탈출 분석이 필요하지 않음

• Rust 애호가들을 위해 "become" 키워드를 추가하는 오래된 RFC가 있었음

  • 2018년 에디션 목표에 집중하기 위해 연기되었으나 최근 다시 논의되고 있음
  • 다시 등장할 가능성이 있음

• C++에서 해석기가 속도를 높이는 방법은 주로 계산된 goto를 사용하는 것임

  • 호출 규약 문제를 피할 수 있음
  • 계산된 goto 스타일이나 꼬리 스타일을 사용하면 분기 예측기 압력을 줄일 수 있음

• 꼬리 호출을 사용하여 컨텍스트를 전환하는 문제는 호출 규약을 사용하는 함수가 필요함

  • 함수 종료 시 상태를 복원하기 위해 레지스터를 낭비함
  • luajit 리메이크 블로그에서 대안과 분석을 제공함

• [[musttail]] 속성이 GCC, Visual C++, 다른 인기 있는 컴파일러로 확산되기를 희망함

  • [[musttail]] 속성이 GCC에 추가되는 과정에 있음

• C++ 지원을 언급하며, C++에는 꼬리 호출이 거의 없음을 지적함

  • 예를 들어, 소멸자가 있는 클래스의 객체를 반환하는 경우 꼬리 호출이 아님

• C++ [[musttail]] 함수에서 예외를 던지면 어떻게 되는지 궁금해함

  • 예외 스택이 완전히 분리되는지 질문함

• 단순한 예제는 좋은 코드 생성을 위해 __attribute__((musttail))이 필요하지 않음을 언급함

  • 오류 처리 함수 호출 속도에 크게 신경 쓰지 않을 것임
  • 특정 구조가 신뢰할 수 있는 점프 테이블을 생성함

• 트램폴린을 사용하여 반환하는 함수 포인터를 외부 루프에서 호출하는 방식의 속도를 궁금해함

  • 이 방식은 이식 가능한 C의 장점을 가짐

• [[musttail]]로 래핑된 예외 경로의 예를 명확히 해달라는 요청이 있음

  • [[musttail]]이 스택 프레임 구성과 레지스터 스필링을 방지하는 이유를 설명함
  • 예외 경로가 실제로 호출될 때만 스택 프레임 구성과 레지스터 스필링이 발생함
  • 예외 경로가 드물게 호출되므로 성능에 큰 영향을 미치지 않음
  • 분기 예측 효과로 인해 추가 작업 가능성이 빠른 경로를 느리게 만들 수 있음